J'ai l'impression de lire un thread de 2005.
Excusez-moi de cette approche trollesque, mais je vais y venir.
Aujourd'hui on a 3 grands modes de monitoring : * Le legacy : un check écrit par service, éventuellement paramétrable. C'est lier a un host et dès qu'on sort du ping ou du check http alacon c'est du travail d'artisans. ** Dans cette catégorie je met tout les nagios like tel que nagios ou centreon mais plein plein d'autres rentrer * Les check centré sur la métrique : ** ici on séparer 2 composents : la collecte d'une métrique et la définition de l'alerting ** C'est mieux, on peut faire du graph facilement, mais dès qu'on veut sortir de l'approche host centric c'est la misère * Les TSDB ** ici la notion d'host n'existe plus vraiment, ** c'est les graph qui priment sur les alertes (dans la vie réel, je me rend compte que je veux plus souvent des graphs et une fois que c'est mure mettre des alertes) ** les méthodes de collecte sont le plus souvent central.
Ce qui rend complexe la migration, c'est inertie de littéralement perdre toute l'expérience acquise sur sa solution de monitoring.
En 2022, sur une base seine, je partirais sur du monitoring centré sur une tsdb que ca soit prometheus, influxdb, victoriametric ou autre.
Il faut aussi comprendre un truc, c'est que le monitoring c'est comme les slip sale, ça ne se partage pas d'une organisation à une autre. et que oui c'est un projet de moyens terme. Mais avoir une vraie observabilité et des capacité de corréler les infos de différent système c'est un vrai gain opérationnel.
Surtout qu'à l'usage, quand on a l'entrepôt de timeseries. il y a de quoi s'amuser !
Alexis
Le jeu. 28 juil. 2022 à 17:18, David Durieux david@durieux.family a écrit :
Bonjour,
Pour les stats dans Grafana, on a des centaines de Go de Zabbix dans une base MariaDB, qui est partitionnée par jour et aucun problème de performances pour l'affichage.
Cordialement, David
On Thu, 28 Jul 2022 16:32:33 +0200 Wallace wallace@morkitu.org wrote:
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 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/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/