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