Les arguments de Raphel peuvent être repris en inconvénients.
Le principal problème je trouve c'est la quantité de données. Car quand on passe sur du prom, on a tendance à ne pas se contenter de toutes les 5 min ou 1 min à l'ancienne, on descend souvent à toutes les 15 secondes voir moins dans certains cas.
Et quand bien même on resterait sur 1min ou 5min, ce n'est pas juste un état ok, warning, error, non c'est toutes les métriques internes d'un logiciel en brut. Et ça entre un nagios et un prom pour une infra de plusieurs centaines de serveurs on passe de tout tient sur un seul serveur nagios qui mange dans les 200Go de datas sur 1 an de rétention pour 4 cpu, 8Go ram à un prom qui mange 4To de datas 32 cpu, 64Go ram pour garder 3 à 4 semaines de datas...
Et après il faut avoir des ressources pour être capable d'interroger toutes ces données rapidement pour faire les alertes, les graphs et là les 32cpu en vm ne suffisent plus ... ça rame sous grafana.
Bref on considère plus prom comme du temps réel à garder 24h / 48h max mais on perd l'investigation à posteriori d'évènements léger ou alors d'un gros pic qu'on a pas pu analyser dans le gap de temps imparti.
On a regardé aussi quelles bases de time series utilisées pour pouvoir notamment réduire les données au bout de certaines périodes : 1 mois, 6 mois, ... pour réduire la fréquence, mais on a rien trouvé qui marchait vraiment bien l'année dernière.
Je suis mitigé.Ok pour la metrologie l’observabilité mais pour l’alerting le reporting ça reste un peu pénible.
Avis purement personnel.
Nicolas Girardi.
Le 28 juil. 2022 à 12:35, Raphael Mazelier <raph@futomaki.net> a écrit :
Bonjour,
Je suis tout de même étonné que peu de monde à part Wallace ait cité écosystème Prometheus.
Dans mes x précédentes aventures professionnelles c'était ce qu'il y avait ou que j'ai mis en place, et c'est ce qui parait le standard de facto de nos jours pour "observer" une infrastructure dynamique (cloud ou autre).
En effet il s'agit d'une approche assez différente (finalement assez proche de zabbix dans son fonctionnement nominal) qui est de récupérer un maximum de métriques et d'évaluer des règles d'alerting dessus.
En effet ce n'est pas agentless, mais si on y réfléchit peu de solution le sont. Il y a nécessairement quelque chose sur le host/équipement qui répond des métriques (possiblement des gauges) dans toutes les solutions (snmp, check_mk, agent-zabbix).
Les bénéfices de l'approche prometheus (ou alternatives) sont nombreux, mais les plus gros que je vois :
- nombres de métriques systèmes et applicatives possiblement énormes
- alertes crées de manières programmatiques
- auto-discovery
- découplage forcés de l'alerting/routing des alertes (on peut voir ça comme un inconvénient)
En revanche cela ne remplace pas tout, on est bien d'accord. Les alertes prom sont du whitebox, et alertes passives.
Il faut en // maintenir des alertes blackbox actives (soit via un outil externes type pingdom), ou même des alertes actives via un tool internes (on en avait écrit certain) qui re-exposaient leurs résultat en métriques prom.
Je ne peux m'empecher de relinker les excellents papier de google SRE sur le monitoring :
- https://sre.google/workbook/monitoring/
- https://sre.google/sre-book/practical-alerting/- https://sre.google/sre-book/monitoring-distributed-systems/
On 26/07/2022 17:32, Mickael MONSIEUR wrote:
_______________________________________________Bonjour, Suite à une mise à jour des systèmes, on a décidé de remplacer par la même occasion notre Nagios par quelque chose d'un peu plus "user-friendly". (et pourtant c'est un demi barbu qui parle..) Vous me demanderez ce qu'on a contre Nagios? En 15 ans, ça n'a pas vraiment évolué, et on aimerait bien quelque chose avec un minimum de GUI pour l'encodage, voir une API. Et mettre 2k/an dans la version XI pour un soft qui n'évolue presque pas... bof. Notre besoin est plutôt simple, on a déjà Observium qui fait 90% de nos besoins au sein de notre réseau, mais Observium ne permet pas "facilement" de monitorer "juste" des ports TCP, du SMTP/POP/IMAP, des réponses DNS, des réponses HTML dans une page HTTPS, l'expiration d'un certificat TLS. Au début on pensait à Zabbix, mais quand on voit que ça passe d'office par un agent, on en voit pas l'utilité. Observium fait déjà tout ça en SNMP, et certaines machines ne sont pas gérées par nous on doit juste les monitorer de l'extérieur, donc installation impossible. Les seules conditions qu'on a c'est : open source, sans agent, et pas dans un langage RAM killer comme Java. Mickael _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Liste de diffusion du %(real_name)s
http://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/