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.
Le 28/07/2022 à 13:14, Nicolas GIRARDI a écrit :
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 <r...@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/
_______________________________________________
Liste de diffusion du %(real_name)s
http://www.frsag.org/
