J'ai testé durant près de 1 mois Zabbix et voici mon retour: Les + - son GUI est pas mal - la courbe d’apprentissage est pas trop longue
Les - - Vraiment trop peu de possibilités sans agent - Pas pensé IPv4/IPv6 dual stack au niveau du monitoring (si j'encode une IPv4 il la monitore forcément, si j'encode un host il monitorera via l'IP du A ou AAAA selon la config du kernel de ma machine Zabbix, mais pas les deux adresses possibles, à moins d'encoder l'hôte 2 fois comme je fais avec nagios...) Je crois que je suis reparti pour quelques années avec nagios :) Le jeu. 28 juil. 2022 à 18:04, Alexis Lameire <alexis.lame...@gmail.com> a écrit : > > 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 <wall...@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 <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/ > > _______________________________________________ > Liste de diffusion du %(real_name)s > http://www.frsag.org/ _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
