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/
