Table des matières

2021/07/04 (Neutriton) : Monitoring

Présences :

Jitsi : https://jitsi.belnet.be/neutriton Caldarium : https://caldarium.be/fr:contact

Météo

Moment informel durant lequel on exprime en peu de mots comment on se sent et si on a une attente forte pour la réunion.

Ce n'est pas un moment de discussion mais d'expression individuelle et ce n'est pas obligatoire 🙂

Attente(s) forte(s)

Si l'une ou l'autre personne exprime une attente forte, merci de vous en occuper en priorité ou de la noter dans le hub ou dans un point approprié.

Ordre du jour

Qu'est-ce qu'un monitoring selon nous ?

Il faut distinguer différentes choses :

Et tout ces machins combinés forment la supervision™ (alerting, monitoring, remédiation).

Rappel des types de monitoring

Aujourd'hui on a deux grands mouvements pour le monitoring.

On préfère ce type de monitoring par rapport à celui à base de métrique.

Monitoring à base de status

Exemples de logiciels:

On a un serveur central qui va récupérer les différents status sur les serveurs monitorés.

Ca a pour conséquence que les seuils d'alerting sont configurés sur les serveurs monitorés.

Ici, il faut produire les métrics une à une et bien réfléchir qu'on n'en oublie pas.

Monitoring à base de metrics

Par exemple:

On a des agents sur les serveurs monitorés qui

Ici, on va fournir beaucoup de métrics et les sélectionner par la suite.

Notification aux admin (Alerting)

Alerting : on définit des seuils qui soient humainement lisibles (warning, critical). On peut aussi envoyer des alertes pour dire que ça fonctionne, pour vérifier que le système d'alerting fonctionne ou quand le système revient dans son état standart. On peut notifier par mail, sms, mattermost, etc.

En fonction du type de monitoring, c'est ou non le même problème. Nagios a par exemple des outils déjà prévus.

Dans Prometheus, Alert manager, on a aussi des systèmes qui s'occupent d'alerter quand l'alerte manager n'alerte plus. (En règle générale, qui monitore le monitoring ?)

Notification aux ~~moldus~~ utilisateurs (Status Page)

Il fait voir ce qui est pertinent pour un·e moldu·e. Est-ce pertinent d'alerter un utilisateur·ice quand le disque du serveur est presque plein ?

Comment évoquer le technique pour des gens qui ne parlent pas technique ? Si par exemple le VPN n'est plus disponible chez Hetzner, tous les membres doivent le savoir ? Si le site est hors ligne 15 min, faut-il le notifier aux membres ?

On a deux types, automatiques et manuels. Pour maintenance e et incidents, manuel → lorsque cest prévu, on prévient que ça va être indisponible. Automatique : c'est l'outil qui envoit un mail à l'utilisateur. A ce moment-là, la personne s'abonne. Ca n'envoit pas à tout le monde sur la mailing list… sinon ça spam.

Voir aussi après combien de temps on est averti qu'un service est down. Spammer tout le monde si down après 5min, pas forcément pertinent, mais il ne faut pas forcément attendre qu'un service soit down 30 min pour prévenir les admins.

Des choix à faire

Monitoring à base de status vs metrics

Status

Si on veut rajouter un nouvel outil à monitorer:

Metrics

Si on veut rajouter un nouvel outil: - on configure l'agent sur le serveur - on configure l'alerting - on crée le dashboard

Ex: https://grafana.neutrinet.be/d/Kd8Y8yCMz/openvpn?orgId=1

Grafana : on peut avoir une partie privée, par exemple pour monitorer chaque IP individuelle.

Conclusion

Décision : On est plus metrics que status. Néanmoins, crainte d'avoir un nouvel outil à apprendre, et d'être que deux à le gérer.

Quelle stack choisissons-nous ?

ELK

Dashboards:

Exemples de dashboards:

Prometheus / influxdb + Grafana + Alertmanager

Prometheus va scrapper une page HTTP et mets au format PromQL (prometheus query language) les métrics.

Deux types d'exporter :

Prometheus n'est pas prévu pour avoir une longue période de rétention (15 jours par défaut), on peut monter plus haut mais ça prend de la place. Mais dans la doc, les concepteurs expliquent bien que ce n'est pas un outil de rétention long terme. Pour les metrics réseaux, il nous faut du long terme.

Soit on considère que Prometheus ne fait pas de long terme et qu'il faut un autre outil pour le réseau : librenms (utilise de vieilles technologies (snmp, rrd) mais fonctionne bien et est fait pour ça)

Soit on utilise promscale (pgsql avec timescaledb ⇒ plugin prévu pour du stockage de metrics) pour du stockage long terme de metrics prometheus. On peut lui dire de stocker 2 ans de metrics, et le plugin va faire son nettoyage en fonction de ça.

Le fait d'utiliser le couple influxdb / telegraf permet de réutiliser les dashboards Grafana de la communauté. Pareil pour prometheus / node_exporter. Par contre, prometheus / telegraf possède moins de dashboards communautaires. La liste des dashboards communautaires : https://grafana.com/grafana/dashboards

Influxdb :

Question : comment exporter les données qui sont en clair sur le réseau ? Mais ça se pose dans tous les cas et Tharyrok a une astuce 👻

node_exporter : une liste de beaucoup de petits plugins difficile à trouver. telegraf : plus simple, on a un repo central avec la liste des plugins, et on passe par port unique.

On peut aussi avoir Telegraf et aller scrapper des petites metrics dans des nodes exporters.

Comment ne pas perdre de metrics en cas de coupure réseau ? On peut avoir un prometheus local par cluster qui est fédéré a un prometheus central (externe au cluster). Ce qui simplifie les flux reseaux et leur securisation.

Logging

Centraliser les logs sur un même serveur peut permettre de voir certaines choses et d'avoir un autre type d'alerting (gérer les cron job, voir une attaque brute force).

Il y a 3 écoles :

Quels canaux de notifications pour l'alerting ?

C'est l'heure des d-d-d-décisions !!!

Notification de nos membres

Des outils pour prévenir l'utilisateur des maintenances ou des incidents :

Chez les propriétaires (oui c'est un peux du troll):

Quid des données personnelles des utilisateurs quand ils s'abonnent ?

Problème de réputation des emails : ils seront envoyés depuis Hetzner, donc haut risque d'être dans les spams.

On postpose ce point pour une prochaine fois

Notification des administrateurs

On passe par alertmanager, qui envoie ses notifications vers (propositions)

Pour les SMS, on peut souscrire à un service :

Mais vu que ça coûte du pognon, mieux vaut le mettre sur les services critiques (la collecte). On peut aussi faire un système de 2ème ou 3ème ligne : on n'a pas fait d'ACK pour Mattermost / mail, du coup un sms se déclenche.

On pourrait aussi avoir un module sur Bour pour envoyer des SMS depuis LouiseDC, mais du coup:

Qui reçoit les SMS ? Pose la question de la disponibilité des admins

Exemple pour gérer les ACK dans Alertmanager : https://github.com/prymitive/kthxbye

Pour les Pigeons, on se demande si c'est vraiment libre (possibilité d'étudier le pigeon ?).

Le flow :

Est-ce qu'on met AlertManager en HA ? On pourrait mettre la deuxième instance chez OVH. Cela dit, AlertManager est stable, donc à part un downtime pour cause de mise à jour…

Décision: On commence avec une seule instance de AlertManager.

A faire

Prochaine réunion

Prochain Neutriton : 22/08 à 14h00

Sujet : Backups ? Backuuuups !!

Lieu : Jitsi et Caldarium.

Météo de fin

Moment informel durant lequel on exprime en peu de mots comment, à titre personnel, la réunion a été vécue que ce soit positif ou négatif. Si une ou plusieurs tension est née durant la réunion, il est peut-être nécessaire d'envisager l'une ou l'autre réunion pour y remédier.

,