[FRsAG] Syslog et Prometheus

Raphael Mazelier raph at futomaki.net
Mer 10 Juin 22:45:11 CEST 2020


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




-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://www.frsag.org/pipermail/frsag/attachments/20200610/293a62a8/attachment-0001.htm>


Plus d'informations sur la liste de diffusion FRsAG