finalement, il y a eu retournement de situation. RETEX: un soft que personne n'avait évoqué : icinga. comme c'est un fork de nagios, ça aide grandement. avec icinga + icingaweb + director on a tout simplement un Nagios avec GUI moderne. (et tout web-based à part les plugins custom) comme on a pu ré encoder à l'identique toute notre hiérarchie nagios dans les fichiers conf vers icingaweb et utiliser tous nos plugins check maison, ça a grandement facilité une migration.
Le sam. 20 août 2022 à 12:51, Mickael MONSIEUR <mickael.monsi...@gmail.com> a écrit : > > 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/
