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/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/