Je rejoins tout ce qui a été dit. La paradigme est d'utiliser de la métrologie
(donc basé sur la métrique en pull ou push). Le standard de facto de nos jours
est Prometheus (ou Opentelemetry). Je conseille vivement sur des nouvelles
installations de ne pas se prendre la tête et de partir directement sur du
VictoriaMetrics (qui est très efficace).
Meme pour le réseau il y en effet des exporteurs snmp, et pour la partie flow
on peut bricoler rapidement un exporteur aussi (j'avais fait le mien à l’époque
à base de pmacct, kafka, python).
Un point toutefois bien mis en avant dans la littérature google
(https://sre.google/sre-book/monitoring-distributed-systems/) le white-box et
monitoring passif ne suffit pas.
A mon sens il faut toujours garder du monitoring actif black-box externe quand
c'est possible.
Cdt,
--
Raphael Mazelier
On 31/10/2023 10:40, Alexis Lameire wrote:
> Hello,
> J'avais eu l'occasion de parler de monitoring réseau à un FRnOG.
>
> Petit contexte, une boite avec pas mal d'applicatif différent et un peu de
> réseau.
>
> En gros, si on regarde ce qui se fait on a 3 type de supervision qui ce sont
> succèder :
> * Le monitoring basé sur l'alerte, c'est ce qu'on trouve dans les nagios
> like. Un check associé a un host qui te renvois OK ou KO, avec une touche de
> graphing passé au forceps
> * Le monitoring centré sur l'host mais basé sur les métrique : le meilleur
> exemple c'est zabbix, on collecte des métrique qu'on peut grapher sur un
> host, puis ont fait de l'alerting dessus :
> ** En pratique, il y a des soucis de monté a l'échelle, j'ai une boite en
> tête qui a taper le fond
> ** On peut sortir de l'host, mais c'est compliqué
> * le monitoring applicatif centré sur la métrique : prom like/ influxdb
> ** c'est de préférence l'applicatif en elle même qui remonte ses métrique
> ** on peut coréler nimp avec nimp (donc top)
> ** centré sur le graphiing, l'alerting n'est qu'une conséquence des graph
>
> Faire le changement de paradigme est vraiment long mais totalement faisable,
> la plupart des softs libres ont des exporter prometheus, et fournir au dev un
> framwork pour exporter de la métrique métier ça facilite la vie de ouf sur
> l'astreinte.
>
> En 2023 sur une nouvelle infra, il faut clairement partir sur ce paradigme.
> Néanmoins un point important, si il faut faire de la rétention de métrique
> sur une longue durée prometheus n'est pas adapté ça et je suggére de regarder
> du coté de victoriametric ou de thanos.io ou de mimir (soutenue par grafana).
>
> A noté aussi que même pour le réseau il existe des exporteur pour parser du
> SNMP, et pour le ping il y a le blackbox exporter.
> Alexis
>
> Le mar. 31 oct. 2023 à 09:21, Kevin Labécot <ke...@labecot.fr> a écrit :
>
>> Hello,
>> De mon côté ca fait des mois que j’ai CheckMK dans mes favoris mais je ne
>> sais pas ce que ça vaut, je n’ai pas pris le temps encore de le tester :
>> https://checkmk.com/
>>
>> La version « raw » est « free and open source ». J’aimerai l’utiliser pour
>> remplacer un outil saas que j’utilise jusqu’ici (mais payant dont je passe
>> le sujet).
>>
>> —
>> Kevin Labécot
>>
>>> Le 31 oct. 2023 à 09:14, Yoda-BZH <fr...@yoda-bzh.net> a écrit :
>>>
>>> Bonjour,
>>>
>>> Il n'est pas *forcément* nécessaire de séparer ces deux supervisions. La
>>> plupart des outils géreront bien les deux environnements.
>>>
>>> Par contre, j'ai une préférence à séparer supervision (aka "est-ce que mon
>>> service est rendu", notification à l'astreinte) de la métrologie
>>> (métriques, jolis graphs, aka "dans le temps, comment est-ce que ça a
>>> évolué", pas d'astreinte).
>>>
>>> J'ai beaucoup monté des supervision à base d'Icinga2 (avec un mix d'agent
>>> icinga, de nrpe, d'icmp et de SNMP) et des métrologies avec Telegraf +
>>> victoriametrics (en remplacement d'influxdb) et grafana.
>>>
>>> Optionnellement Icinga2 peut aussi pousser des métriques dans
>>> victoriametrics.
>>>
>>> Le fait de séparer supervision et métrologie est d'éviter les "sondes de
>>> supervision juste pour faire des graphs, mais non ça ne sonnera pas en
>>> astreinte" qui sonneront en astreinte, et les "sondes qu'il n'est pas
>>> nécessaire de regarder" qui pollueront la vue.
>>>
>>> J'ai aussi vu des infras avec des LibreNMS branché sur le victoriametrics
>>> pour des métriques très spécifique réseau.
>>>
>>> Yoda-BZH
>>>
>>> October 30, 2023 at 8:38 PM, "Jarod G. via FRsAG" <frsag@frsag.org> wrote:
>>>
>>>> Holà la liste,
>>>>
>>>> on est en train de réfléchir à la question des supervisions pour une
>>>> petite infra qui peut être amenée à évoluer.
>>>>
>>>> Je dit "des" car on remarque vite que un outil tout en un qui fait tout
>>>> correctement, bah ça existe tout simplement pas.
>>>>
>>>> On réfléchissait à monter donc au moins deux sups.
>>>>
>>>> Une sup "infra" qui fait uniquement du SNMP/ICMP pour tout ce qui est
>>>> réseau/serveurs/vm et une sup "applicative" qui elle va gérer le reste
>>>> (état nginx, systemd, etc...).
>>>>
>>>> Du coup on est en recherche d'idées, sur la partie "infra" on est plutôt
>>>> familier avec Observium et LibreNMS même si on est pas fermé à autre chose.
>>>> Quand à la partie "applicative" c'est un peu le flou (mix grafana+influx
>>>> ?), surtout sur la partie alertes.
>>>>
>>>> Avez vous des retex sur des solutions que vous utilisez déjà ?
>>>> (ou des noms de solutions "entendues" mais jamais testées)
>>>>
>>>> Notre seule et unique contrainte dans les solutions est que ça a besoin
>>>> d'être gratuit (bonus si c'est libre).
>>>>
>>>> Jarod G.
>>>>
>>>> _______________________________________________
>>>> 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/
