Bonjour à tous,
On arrive pas à se décider sur le choix de stockage de logs et de métrique dans le cadre de la centralisation de logs syslog et des métriques récupérée par Prometheus.
Le contexte est plusieurs centaines de systèmes (99% Debian, 1% autre (BSD, appliance).
Jusqu'à présent on avait un serveur syslog qui enregistrait pour l'archivage légal et décentralisé les logs des serveurs avec rotation et tout ce qui va bien.
Dans le cadre de la mise en place de Prometheus comme nouvelle supervision, on voit clairement l'intérêt de venir chercher des éléments dans les logs pour faire de la remontée de métrique additionnel en plus des exporters.
L'idée est d'aller vers un Prometheus, Grafana et Loki mais en ayant testé différentes bases de stockage métrique et logs on se rend compte que la place occupée et les ressources pour gérer tout cela sont plus que conséquentes.
On s'oriente vers un découpage pour les logs et métrique long terme et ceux à exploiter sur une période < 1 semaine mais ça parait lourd comme organisation et loin du KISS avec les risques de perte de donnée.
Ce que j'aimerais dans l'idéal :
- partie log exploitation non compressée sur une période de quelques jours pour corréler avec les métriques, par la suite c'est compressé et archivé avec éventuellement la possibilité d'aller revoir un évènement en arrière
- partie métrique avoir toutes les métriques sur quelques heures, 24h max, puis façon rrdtool supprimer les métriques en faisant une moyenne et/ou min/max sur des périodes de 5 min puis 15 ... Là pas de retour arrière ce qui est supprimé est définitif.
En mode métrologie si on détecte à postériori un changement de tendance même sur une moyenne, pouvoir réouvrir les logs associés à cet espace de temps nous parait important.
Et vous vous utilisez quoi comme base de donnée de stockage pour les métriques Prometheus et pour l'exploitation des logs sans faire exploser les serveurs avec des To de données?
Bonne fin de journée
Re,
- partie log exploitation non compressée sur une période de quelques
jours pour corréler avec les métriques, par la suite c'est compressé et archivé avec éventuellement la possibilité d'aller revoir un évènement en arrière
Un rsyslog centralisé en front avant ta stack EL(K)... comme ca tu fais ton archivage/compression à l'ancienne avec des vrais fichiers logs et du logrotate... K.I.S.S.
- partie métrique avoir toutes les métriques sur quelques heures, 24h
max, puis façon rrdtool supprimer les métriques en faisant une moyenne et/ou min/max sur des périodes de 5 min puis 15 ... Là pas de retour arrière ce qui est supprimé est définitif.
Ca c'est possible avec graphite (avec graphite, comme avec RRD, la taille de DB est fixe et prédéfinie à la création)... Du coup en cherchant prometheus+adapter+graphite, tu trouveras ton bonheur. Et graphite sur une bécane moderne ca encaissera largement tout ce que tu peux mettre de compteurs de monitoring pour 100 machines, IMHO.
Cordialement, -- Philippe Bourcier web : http://syscRCPT ..org/ blog : https://www.linkedin.com/today/author/philippebourcier
Bonjour;
Gros sujet.
Coté métriques le couple prometheus/grafana semble avoir gagné temporairement la partie. Ceci étant cela ne vient pas sans challenge.
Prometheus est très efficace mais il ne gère pas le downsampling et le stockage long terme out of the box.
Il existe plein de solutions pour palier ces défauts : voir coté cortex, victoriaMetrics, etc... Il est donc maintenant possible d'avoir une rétention longue (voir par exemple l'article d'un ex collègue sur la question : https://medium.com/@IG1.com/sismology-iguana-solutions-monitoring-system-f46... .
L'alerting basé sur Prometheus est aussi assez tricky à mettre en place (long sujet aussi).
Coté log je partirais sur une approche mixte. Loki semble très intéressant pour corréler les logs avec prometheus. Je choisirais donc un shipper générique (fluentbit, rsyslog) qui enverrait vers un plateforme centrale d'ingestion de logs (avec buffering, kafka ou autre), et un processeur de log qui pourrait envoyer vers diverses destinations : loki, E(L)K (ou graylog) et une plateforme d'archivage flat.
En revanche il ne faut pas se leurrer une architecture de métriques et de logs coûte cher, mais ce n'est pas la dessus que je ferais des économies.
--
Raphael Mazelier
On 09/06/2020 18:49, Wallace wrote:
Bonjour à tous,
On arrive pas à se décider sur le choix de stockage de logs et de métrique dans le cadre de la centralisation de logs syslog et des métriques récupérée par Prometheus.
Le contexte est plusieurs centaines de systèmes (99% Debian, 1% autre (BSD, appliance).
Jusqu'à présent on avait un serveur syslog qui enregistrait pour l'archivage légal et décentralisé les logs des serveurs avec rotation et tout ce qui va bien.
Dans le cadre de la mise en place de Prometheus comme nouvelle supervision, on voit clairement l'intérêt de venir chercher des éléments dans les logs pour faire de la remontée de métrique additionnel en plus des exporters.
L'idée est d'aller vers un Prometheus, Grafana et Loki mais en ayant testé différentes bases de stockage métrique et logs on se rend compte que la place occupée et les ressources pour gérer tout cela sont plus que conséquentes.
On s'oriente vers un découpage pour les logs et métrique long terme et ceux à exploiter sur une période < 1 semaine mais ça parait lourd comme organisation et loin du KISS avec les risques de perte de donnée.
Ce que j'aimerais dans l'idéal :
- partie log exploitation non compressée sur une période de quelques
jours pour corréler avec les métriques, par la suite c'est compressé et archivé avec éventuellement la possibilité d'aller revoir un évènement en arrière
- partie métrique avoir toutes les métriques sur quelques heures, 24h
max, puis façon rrdtool supprimer les métriques en faisant une moyenne et/ou min/max sur des périodes de 5 min puis 15 ... Là pas de retour arrière ce qui est supprimé est définitif.
En mode métrologie si on détecte à postériori un changement de tendance même sur une moyenne, pouvoir réouvrir les logs associés à cet espace de temps nous parait important.
Et vous vous utilisez quoi comme base de donnée de stockage pour les métriques Prometheus et pour l'exploitation des logs sans faire exploser les serveurs avec des To de données?
Bonne fin de journée
Liste de diffusion du FRsAG http://www.frsag.org/
Merci Philippe et Raphael, je pense en effet que le KISS du syslog à l'ancienne me parait une bonne solution notamment pour l'archivage légal, j'avais pas pensé à renvoyé une autre fois vers un autre composant, ça me parait évident maintenant.
Le stockage de prometheus clairement non, au delà de 24h pour 25 machines de test c'est déjà des centaines de gigas, aucun mécanisme de compression et réduction disponible, c'est pas envisageable.
On a essayé Victoria et on part pour le moment dessus car ils promettent la réduction sous peu mais ça ne tiendra pas la prod en l'état c'est évident.
A mon avis on va simplifier la première version de la nouvelle supervision, se limiter à 48h max, garder les logs syslog centralisés et tester en second palier toutes les bases de stockage et leurs évolutions.
Dernières questions car du coup si je reste sur du syslog faut que je redescende une problématique que devait régler la nouvelle supervision.
Comment vous rendez vos syslog hautement disponible pour parer à une coupure réseau d'un cloud par exemple? Vous envoyez chaque source sur deux syslogs sur deux réseaux différents (donc double stockage) ou y a des astuces pour faire une sorte de cluster actif actif?
Et n'ayant pas regarder on peut scaler horizontalement derrière des LB des syslogs en tcp tout en écrivant dans les mêmes fichiers (peut être avec du sticky)?
Encore merci
Bonjour.
Je suis un peu étonné de vos différentes conclusions sur Prometheus. Je gère actuellement un architecture Prometheus de 10 serveurs prometheus (2 par DC + 2 Fédération). Cette stack collecte plus de 500k métriques chaque minutes et garde un historique de 90 jours. Les métriques proviennent de environs 230 instances AWS EC2, 2 cluster K8S, Cloudwatch et un certains nombre de service (Mysql, Mongo, Redis, etc..)
[image: Capture d’écran 2020-06-10 à 12.27.30.jpg]
- Chaque API / APP fournit des métriques - A chaque déploiement les dev peuvent mettre à jour leurs métriques métier - L'alerting est aux petits oignons avec un CI/CD dédié permettant au dev de créer leur propre alerte sûr leur métrique métier. - L'alerting comporte des règles sur le business (drop de vente, nb de panier abandonnés, baisse de recherche dans le moteur etc) - Chaque squad reçois les alertes sur son channel slack - L'infra et le business ont en plus des alerts pager duty
Pour l'archivage ou la rétention longue duré il existe différente solution que nous n'utilisons pas. La solution qui monte est https://thanos.io Nous pensons créé un service d'extraction de quelques métriques via l'API prometheus afin d'archivage sous forme de fichier csv (github est pleins de piste pour cela)
Bref pour l'aspect monitoring Prometheus me semble un outil adapté.
Karles https://twitter.com/Karlesnine
Le mer. 10 juin 2020 à 11:27, Wallace wallace@morkitu.org a écrit :
Merci Philippe et Raphael, je pense en effet que le KISS du syslog à l'ancienne me parait une bonne solution notamment pour l'archivage légal, j'avais pas pensé à renvoyé une autre fois vers un autre composant, ça me parait évident maintenant.
Le stockage de prometheus clairement non, au delà de 24h pour 25 machines de test c'est déjà des centaines de gigas, aucun mécanisme de compression et réduction disponible, c'est pas envisageable.
On a essayé Victoria et on part pour le moment dessus car ils promettent la réduction sous peu mais ça ne tiendra pas la prod en l'état c'est évident.
A mon avis on va simplifier la première version de la nouvelle supervision, se limiter à 48h max, garder les logs syslog centralisés et tester en second palier toutes les bases de stockage et leurs évolutions.
Dernières questions car du coup si je reste sur du syslog faut que je redescende une problématique que devait régler la nouvelle supervision.
Comment vous rendez vos syslog hautement disponible pour parer à une coupure réseau d'un cloud par exemple? Vous envoyez chaque source sur deux syslogs sur deux réseaux différents (donc double stockage) ou y a des astuces pour faire une sorte de cluster actif actif?
Et n'ayant pas regarder on peut scaler horizontalement derrière des LB des syslogs en tcp tout en écrivant dans les mêmes fichiers (peut être avec du sticky)?
Encore merci
Liste de diffusion du FRsAG http://www.frsag.org/
Hello,
Je suis un peu étonné de vos différentes conclusions sur Prometheus.
(...)
Pour l'archivage ou la rétention longue duré il existe différente solution que nous n'utilisons pas. La solution qui monte est [ https://thanos.io/ | https://thanos.io ] Nous pensons créé un service d'extraction de quelques métriques via l'API prometheus afin d'archivage sous forme de fichier csv (github est pleins de piste pour cela)
L'UI de Prometheus est pas mal, même si d'un point de vue perso je n'adhère pas, mais c'est une question de gouts évidement. Par contre chose que j'ai effectivement remarqué comme tout infra grafana like, c'est que la taille des machines et du stockage sont loin d’être anodin. Loin de moi de dire que c'est pas bien, mais je trouve que pour les même métriques la surface et le nombre de cœurs/mémoire par rapport a des choses "legacy" (legacy = rrd), on est loin de la même efficacité. Encore plus pour les logs, ou un FS ZFS avec dedup + compression avec un grep -r pour retrouver les informations sera toujours aussi efficace qu'un SQL ou un autre backend de "haut niveau".
Donc je reste vieux con, et je garde sur un frontend web que les data chaudes du jour / semaine / max 1 mois, le reste fichier plats + zfs + compression + dedup -> priceless (et grep -r est mon ami).
Xavier
Le mercredi 10 juin 2020 à 13:56 +0200, Xavier Beaudouin a écrit :
Hello,
L'UI de Prometheus est pas mal, même si d'un point de vue perso je n'adhère pas, mais c'est une question de gouts évidement. Par contre chose que j'ai effectivement remarqué comme tout infra grafana like, c'est que la taille des machines et du stockage sont loin d’être anodin. Loin de moi de dire que c'est pas bien, mais je trouve que pour les même métriques la surface et le nombre de cœurs/mémoire par rapport a des choses "legacy" (legacy = rrd), on est loin de la même efficacité. Encore plus pour les logs, ou un FS ZFS avec dedup + compression avec un grep -r pour retrouver les informations sera toujours aussi efficace qu'un SQL ou un autre backend de "haut niveau".
Donc je reste vieux con, et je garde sur un frontend web que les data chaudes du jour / semaine / max 1 mois, le reste fichier plats + zfs
- compression + dedup -> priceless (et grep -r est mon ami).
Xavier _______________________________________________
Hello,
pour la partie logs, le plus "pratique" pour mon usage aujourd'hui c'est du fichier plat, sur une partition Btrfs + Zstd, le tout avec du LVM cache. Et oui, je pense que j'aurais pû monter la même chose des années plus tôt avec ZFS.
Maintenant, les équipes techs de nos clients n'aiment pas ça. Elles veulent une interface HTTP, notamment pour pouvoir faire des rapports plus facilement.
Du coup ça fait quelques mois qu'on prévoit de mettre du Loki en place, justement pour satisfaire tout le monde. Le ratio de compression me semble similaire à mon Zstd actuel (c'est à dire x10), et derrière ça reste un "grep", avec une notion de tags en plus... donc au final, ça permet surtout de s'interfacer avec Grafana, comme ça tout le monde est content, non ? :)
En tous cas, on va tester ça.
Olivier
Bonjour,
Retour intéressant, quel poids pèse tes métriques stockées sur Prometheus?
Tu les stockes localement sur les edges ou sur ceux fédérant?
Merci
Le 10/06/2020 à 12:39, Charles-Christian Croix a écrit :
Bonjour.
Je suis un peu étonné de vos différentes conclusions sur Prometheus. Je gère actuellement un architecture Prometheus de 10 serveurs prometheus (2 par DC + 2 Fédération). Cette stack collecte plus de 500k métriques chaque minutes et garde un historique de 90 jours. Les métriques proviennent de environs 230 instances AWS EC2, 2 cluster K8S, Cloudwatch et un certains nombre de service (Mysql, Mongo, Redis, etc..)
Capture d’écran 2020-06-10 à 12.27.30.jpg
- Chaque API / APP fournit des métriques
- A chaque déploiement les dev peuvent mettre à jour leurs métriques métier
- L'alerting est aux petits oignons avec un CI/CD dédié permettant au dev de créer leur propre alerte sûr leur métrique métier.
- L'alerting comporte des règles sur le business (drop de vente, nb de panier abandonnés, baisse de recherche dans le moteur etc)
- Chaque squad reçois les alertes sur son channel slack
- L'infra et le business ont en plus des alerts pager duty
Pour l'archivage ou la rétention longue duré il existe différente solution que nous n'utilisons pas. La solution qui monte est https://thanos.io Nous pensons créé un service d'extraction de quelques métriques via l'API prometheus afin d'archivage sous forme de fichier csv (github est pleins de piste pour cela)
Bref pour l'aspect monitoring Prometheus me semble un outil adapté.
Karles https://twitter.com/Karlesnine
Le mer. 10 juin 2020 à 11:27, Wallace <wallace@morkitu.org mailto:wallace@morkitu.org> a écrit :
Merci Philippe et Raphael, je pense en effet que le KISS du syslog à l'ancienne me parait une bonne solution notamment pour l'archivage légal, j'avais pas pensé à renvoyé une autre fois vers un autre composant, ça me parait évident maintenant. Le stockage de prometheus clairement non, au delà de 24h pour 25 machines de test c'est déjà des centaines de gigas, aucun mécanisme de compression et réduction disponible, c'est pas envisageable. On a essayé Victoria et on part pour le moment dessus car ils promettent la réduction sous peu mais ça ne tiendra pas la prod en l'état c'est évident. A mon avis on va simplifier la première version de la nouvelle supervision, se limiter à 48h max, garder les logs syslog centralisés et tester en second palier toutes les bases de stockage et leurs évolutions. Dernières questions car du coup si je reste sur du syslog faut que je redescende une problématique que devait régler la nouvelle supervision. Comment vous rendez vos syslog hautement disponible pour parer à une coupure réseau d'un cloud par exemple? Vous envoyez chaque source sur deux syslogs sur deux réseaux différents (donc double stockage) ou y a des astuces pour faire une sorte de cluster actif actif? Et n'ayant pas regarder on peut scaler horizontalement derrière des LB des syslogs en tcp tout en écrivant dans les mêmes fichiers (peut être avec du sticky)? Encore merci _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/--
Charles-Christian Croix
Liste de diffusion du FRsAG http://www.frsag.org/
Je ne pense pas qu'on puisse extrapoler, mais chez nous (on utilise Netdata en exporteur), avec en tout 25 millions de métriques pour ~600 serveurs, raffraichis toutes les 10 secondes et conservées 6 mois, ça représente un peu moins de 6To.
Mais... on stocke beaucoup (trop ?) de choses. (à vrai dire je trouve cette moyenne de 40k métriques par serveur bien trop élevée).
Je précise qu'il s'agit uniquement des métriques, uniquement Prometheus. Nous n'avons pas encore de Loki dans la boucle.
Le mercredi 10 juin 2020 à 15:01 +0200, Wallace a écrit :
Bonjour,
Retour intéressant, quel poids pèse tes métriques stockées sur Prometheus?
Tu les stockes localement sur les edges ou sur ceux fédérant?
Merci
Le 10/06/2020 à 12:39, Charles-Christian Croix a écrit :
Bonjour.
Je suis un peu étonné de vos différentes conclusions sur Prometheus. Je gère actuellement un architecture Prometheus de 10 serveurs prometheus (2 par DC + 2 Fédération). Cette stack collecte plus de 500k métriques chaque minutes et garde un historique de 90 jours. Les métriques proviennent de environs 230 instances AWS EC2, 2 cluster K8S, Cloudwatch et un certains nombre de service (Mysql, Mongo, Redis, etc..)
Chaque API / APP fournit des métriques A chaque déploiement les dev peuvent mettre à jour leurs métriques métier L'alerting est aux petits oignons avec un CI/CD dédié permettant au dev de créer leur propre alerte sûr leur métrique métier. L'alerting comporte des règles sur le business (drop de vente, nb de panier abandonnés, baisse de recherche dans le moteur etc) Chaque squad reçois les alertes sur son channel slack L'infra et le business ont en plus des alerts pager duty Pour l'archivage ou la rétention longue duré il existe différente solution que nous n'utilisons pas. La solution qui monte est https://thanos.io Nous pensons créé un service d'extraction de quelques métriques via l'API prometheus afin d'archivage sous forme de fichier csv (github est pleins de piste pour cela)
Bref pour l'aspect monitoring Prometheus me semble un outil adapté.
Karles https://twitter.com/Karlesnine
Le mer. 10 juin 2020 à 11:27, Wallace wallace@morkitu.org a écrit :
Merci Philippe et Raphael, je pense en effet que le KISS du syslog à l'ancienne me parait une bonne solution notamment pour l'archivage légal, j'avais pas pensé à renvoyé une autre fois vers un autre composant, ça me parait évident maintenant.
Le stockage de prometheus clairement non, au delà de 24h pour 25 machines de test c'est déjà des centaines de gigas, aucun mécanisme de compression et réduction disponible, c'est pas envisageable.
On a essayé Victoria et on part pour le moment dessus car ils promettent la réduction sous peu mais ça ne tiendra pas la prod en l'état c'est évident.
A mon avis on va simplifier la première version de la nouvelle supervision, se limiter à 48h max, garder les logs syslog centralisés et tester en second palier toutes les bases de stockage et leurs évolutions.
Dernières questions car du coup si je reste sur du syslog faut que je redescende une problématique que devait régler la nouvelle supervision.
Comment vous rendez vos syslog hautement disponible pour parer à une coupure réseau d'un cloud par exemple? Vous envoyez chaque source sur deux syslogs sur deux réseaux différents (donc double stockage) ou y a des astuces pour faire une sorte de cluster actif actif?
Et n'ayant pas regarder on peut scaler horizontalement derrière des LB des syslogs en tcp tout en écrivant dans les mêmes fichiers (peut être avec du sticky)?
Encore merci
Liste de diffusion du FRsAG http://www.frsag.org/
--
Charles-Christian Croix
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Jolies stats, stocké avec Prometheus du coup?
Et les IO disques sur les 6To c'est pas trop lourd?
Le 10/06/2020 à 16:13, Olivier Bonvalet a écrit :
Je ne pense pas qu'on puisse extrapoler, mais chez nous (on utilise Netdata en exporteur), avec en tout 25 millions de métriques pour ~600 serveurs, raffraichis toutes les 10 secondes et conservées 6 mois, ça représente un peu moins de 6To.
Mais... on stocke beaucoup (trop ?) de choses. (à vrai dire je trouve cette moyenne de 40k métriques par serveur bien trop élevée).
Je précise qu'il s'agit uniquement des métriques, uniquement Prometheus. Nous n'avons pas encore de Loki dans la boucle.
Le mercredi 10 juin 2020 à 15:01 +0200, Wallace a écrit :
Bonjour,
Retour intéressant, quel poids pèse tes métriques stockées sur Prometheus?
Tu les stockes localement sur les edges ou sur ceux fédérant?
Merci
Le 10/06/2020 à 12:39, Charles-Christian Croix a écrit :
Bonjour.
Je suis un peu étonné de vos différentes conclusions sur Prometheus. Je gère actuellement un architecture Prometheus de 10 serveurs prometheus (2 par DC + 2 Fédération). Cette stack collecte plus de 500k métriques chaque minutes et garde un historique de 90 jours. Les métriques proviennent de environs 230 instances AWS EC2, 2 cluster K8S, Cloudwatch et un certains nombre de service (Mysql, Mongo, Redis, etc..)
Chaque API / APP fournit des métriques A chaque déploiement les dev peuvent mettre à jour leurs métriques métier L'alerting est aux petits oignons avec un CI/CD dédié permettant au dev de créer leur propre alerte sûr leur métrique métier. L'alerting comporte des règles sur le business (drop de vente, nb de panier abandonnés, baisse de recherche dans le moteur etc) Chaque squad reçois les alertes sur son channel slack L'infra et le business ont en plus des alerts pager duty Pour l'archivage ou la rétention longue duré il existe différente solution que nous n'utilisons pas. La solution qui monte est https://thanos.io Nous pensons créé un service d'extraction de quelques métriques via l'API prometheus afin d'archivage sous forme de fichier csv (github est pleins de piste pour cela)
Bref pour l'aspect monitoring Prometheus me semble un outil adapté.
Karles https://twitter.com/Karlesnine
Le mer. 10 juin 2020 à 11:27, Wallace wallace@morkitu.org a écrit :
Merci Philippe et Raphael, je pense en effet que le KISS du syslog à l'ancienne me parait une bonne solution notamment pour l'archivage légal, j'avais pas pensé à renvoyé une autre fois vers un autre composant, ça me parait évident maintenant.
Le stockage de prometheus clairement non, au delà de 24h pour 25 machines de test c'est déjà des centaines de gigas, aucun mécanisme de compression et réduction disponible, c'est pas envisageable.
On a essayé Victoria et on part pour le moment dessus car ils promettent la réduction sous peu mais ça ne tiendra pas la prod en l'état c'est évident.
A mon avis on va simplifier la première version de la nouvelle supervision, se limiter à 48h max, garder les logs syslog centralisés et tester en second palier toutes les bases de stockage et leurs évolutions.
Dernières questions car du coup si je reste sur du syslog faut que je redescende une problématique que devait régler la nouvelle supervision.
Comment vous rendez vos syslog hautement disponible pour parer à une coupure réseau d'un cloud par exemple? Vous envoyez chaque source sur deux syslogs sur deux réseaux différents (donc double stockage) ou y a des astuces pour faire une sorte de cluster actif actif?
Et n'ayant pas regarder on peut scaler horizontalement derrière des LB des syslogs en tcp tout en écrivant dans les mêmes fichiers (peut être avec du sticky)?
Encore merci
Liste de diffusion du FRsAG http://www.frsag.org/
--
Charles-Christian Croix
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Oui c'est du Prometheus (sous Docker, pour le multi-tenant).
En terme d'IO c'est étonnament calme, mais c'est stocké sur du LVM- cache, avec 10% sur NVMe. Généralement les clients consultent surtout les datas fraiches, qui sont donc très probablement sur les NVMe. Les accès aux données plus anciennes sont un peu moins rapides, mais ça se passe bien.
Le mercredi 10 juin 2020 à 19:01 +0200, Wallace a écrit :
Jolies stats, stocké avec Prometheus du coup?
Et les IO disques sur les 6To c'est pas trop lourd?
Le 10/06/2020 à 16:13, Olivier Bonvalet a écrit :
Je ne pense pas qu'on puisse extrapoler, mais chez nous (on utilise Netdata en exporteur), avec en tout 25 millions de métriques pour ~600 serveurs, raffraichis toutes les 10 secondes et conservées 6 mois, ça représente un peu moins de 6To.
Mais... on stocke beaucoup (trop ?) de choses. (à vrai dire je trouve cette moyenne de 40k métriques par serveur bien trop élevée).
Je précise qu'il s'agit uniquement des métriques, uniquement Prometheus. Nous n'avons pas encore de Loki dans la boucle.
On 10/06/2020 16:13, Olivier Bonvalet wrote:
Je ne pense pas qu'on puisse extrapoler, mais chez nous (on utilise Netdata en exporteur), avec en tout 25 millions de métriques pour ~600 serveurs, raffraichis toutes les 10 secondes et conservées 6 mois, ça représente un peu moins de 6To.
Mais... on stocke beaucoup (trop ?) de choses. (à vrai dire je trouve cette moyenne de 40k métriques par serveur bien trop élevée).
40K métriques par serveur ? cela me parait très très élevé. Une de clé pour bien sizer ton infra prometheus est justement de bien filtrer les métriques à scrapper, et aussi d'éviter si possible les labels avec high cardinality.
Dans job-2 on tenait sur un seul serveur (ok costaud, blindé de ssd et de ram) le scrapping des 800vm(s)/serveurs/micro-services sur K8S sur une seul instance prom.
--
Raphael Mazelier
On 10/06/2020 12:39, Charles-Christian Croix wrote:
Bonjour.
Je suis un peu étonné de vos différentes conclusions sur Prometheus. Je gère actuellement un architecture Prometheus de 10 serveurs prometheus (2 par DC + 2 Fédération). Cette stack collecte plus de 500k métriques chaque minutes et garde un historique de 90 jours. Les métriques proviennent de environs 230 instances AWS EC2, 2 cluster K8S, Cloudwatch et un certains nombre de service (Mysql, Mongo, Redis, etc..)
Il s'agit déjà d'une infrastructure conséquente. (je ne dis pas que cela ne vaut l'investissement).
- Chaque API / APP fournit des métriques
- A chaque déploiement les dev peuvent mettre à jour leurs métriques métier
- L'alerting est aux petits oignons avec un CI/CD dédié permettant au dev de créer leur propre alerte sûr leur métrique métier.
- L'alerting comporte des règles sur le business (drop de vente, nb de panier abandonnés, baisse de recherche dans le moteur etc)
Chez nous aussi au niveau métriques chaque service fourni aussi ses métriques (techniques et business) ; en revanche la définition de l'alerting reste malheureusement un pain point. Toutes les définitions restent centralisé dans un seul repo, et il n'y a pas de template pour créer les alertes. D'une manière générale je trouve la gestion des alertes avec Prometheus difficile. Cf ce post que je trouve intéressant : https://www.metricfire.com/blog/top-5-prometheus-alertmanager-gotchas
- Chaque squad reçois les alertes sur son channel slack
- L'infra et le business ont en plus des alerts pager duty
Oui on a fait ça aussi mais c'est loin d’être parfait. Le principal problème à mon sens reste la dualité alerte(alerte active) et sonde(définition d'une alerte), et la désynchro entre Prometheus, AlertManager et PagerDuty.
Pour le moment on a fini avec un dashboard PagerDuty homemade, et un bot home-made aussi. Mais cela reste artisanal.
Pour l'archivage ou la rétention longue duré il existe différente solution que nous n'utilisons pas. La solution qui monte est https://thanos.io
Thanos, Cortex, M3 et Victoria Metrics. Des approches différentes mais qui visent en effet à résoudre la rétention long terme, avec down sampling (ou pas).
Nous pensons créé un service d'extraction de quelques métriques via l'API prometheus afin d'archivage sous forme de fichier csv (github est pleins de piste pour cela)
Bref pour l'aspect monitoring Prometheus me semble un outil adapté.
C'est adapté, mais ce n'est pas non plus le silver bullet à mon avis.
Il faut aussi le coupler à un monitoring externe type blackbox (blackbox-exporter ou pas, on aussi refait le notre).
Lire l'excellente partie monitoring dans le bouquin SRE google, ou je cite de souvenir un bon système de monitoring est un savant équilibre entre whitebox et blackbox monitoring. D'ailleurs pour du Pager la nuit j'aurais plutôt tendance à ne déclencher que sur du blackbox mais c'est complètement discutable.
-- Raphael Mazelier
-
Charles-Christian Croix -
Olivier Bonvalet -
Philippe Bourcier -
Raphael Mazelier -
Wallace -
Xavier Beaudouin