Outils pour utilisateurs

Outils du site

Piste : • 07-04
fr:rapports:2021:07-04

Table des matières

2021/07/04 (Neutriton) : Monitoring

Présences :

  • HgO
  • Célo
  • Tharyrok
  • Fredux
  • Channel (mais elle est pas là, mais t'es ou, je suis pas la)

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 ?

  • Système de mesure qui dit ce qui fonctionne ou pas, qui donne des indications sur comment ça fonctionne (= mesure du temps pour joindre une machine, latence, etc.)
  • Permet d'optimiser l'infra
  • Quelque chose qui averti si ça ne marche plus, qui averti si quelque chose se casse la gueule ou va se casser la gueule → par exemple un disque du est à 90%, donc il sera bientôt plein).
  • Voir comment l'infrastructure se comporte (test de charge, test de performance, détection des memory leaks)

Il faut distinguer différentes choses :

  • la surveillance, du côté de la supervision, qui ne va faire que surveiller des éléments informatiques (mais sans remédiation). Ex: mesure du temps, espace disque, tests de charge,…
  • la remédiation automatique. Ex: si un service ne répond plus, le redémarrer.
  • l'alerting : la partie qui s'occupe soit d'alerter un humain, soit d'alerter la remédiation.

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.

  • à base de status: un programme ou un script qui renvoie trois états (success, warning, critical). On regarde l'état mais on s'en fiche de la valeur réelle (par ex: temps de 300ms → on s'intéresse juste au status success)

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

  • à base de métrique : on récupère la valeur, et ce n'est pas au moment où on récupère cette métrique qu'on dit si c'est ok ou pas ok. On récupère la métrique dans un premier temps, puis on analyse si ça veut dire qu'on est dans un bon état ou pas.

Monitoring à base de status

Exemples de logiciels:

  • Nagios
  • icinga
  • …

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:

  • grafana, prometheus, node-exporter
  • elasticsearch, logstash, kibana (ELK)

On a des agents sur les serveurs monitorés qui

  • soit envoient les informations vers le serveur central,
  • soit permettent au serveur central de récupérer les informations.

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
  • plus simple à mettre en place
  • chronophage à maintenir
    • choisir un à un ses outils, les valeurs de seuils, etc.
    • si le disque est plein à 80%, on sait ça mais pas dans combien de temps il sera plein. On a un statut mais une logique de sys admin se rajoute.
  • impossible de comparer dans le temps les status, par ex. nombre de visiteurs sur un site… qui varient selon les saisons (heure de visite par exemple). Difficile de voir si on est dans les seuils de la saison actuelle).
  • écosystème plus vaste (plusieurs logiciels existent pour faire le boulot)
  • possible d'afficher des metrics (ex: mémoire actuelle), mais sous forme de hack
  • pas possible d'avoir une vue générale

Si on veut rajouter un nouvel outil à monitorer:

  • on configure le plugin / script
  • on définit un seuil
  • le serveur central va automatiquement créer le bon graphe
Metrics
  • plus à la mode ?
    • parfois des milliers de services à monitoring
    • docker pousse ce type de metrics
  • plus de communautés
  • chronophage à créer des dashboards
    • ça produit beaucoup de métrics… il faut prendre le temps de voir ce qu'elles veulent dire et de les filtrer.
  • Alterer baser sur les saisons (et possibilté de faire des moyennes, des max, etc… sur plusieurs saisons)
  • il y a que 2 écosystème (elk ou prometheus + grafana)

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:

  • de petits binaires sur les machines qui créent immédiatement les dashboard. Pas besoin de les créer soi-même (mais pas adaptable si on veut faire une métric métier).
  • comment faire pour les metrics métiers ? Tu pleures.

Exemples de dashboards:

Prometheus / influxdb + Grafana + Alertmanager
  • Quid du SSO ? Grafana intègre ça.
  • Quid de l'authentification vers les exporters de metrics ? Sachant qu'elles vont voyager sur les internetz
  • Quelle rétention on garde pour Prometheus ? Pour le long terme, voir https://github.com/timescale/Promscale
  • Quel type d'exporter ? telegraf vs node_exporter
  • Quel aggrégateur de metrics ? prometheus vs influxdb

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

Deux types d'exporter :

  • L'école nodeexporter, on a autant de petits binaires qui exportent une métric unique (un pour HTTP, un pour SQL, etc…) qui consomment alors un port d'écoute par nodeexporter.
  • L'autre école, c'est telegraf, qui de base a beaucoup de plugins pour récupérer des métrics, mais peut aussi agréger des métrics d'autres nodes exporters, et ne fourni qu'une seule page web à scrapper pour Prometheus.

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 :

  • le stockage long terme des métrics est prévu de base mais problème de licence → si on veut des fonctions au-delà de la version de base, c'est payant.

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

  • Exporteur : Telegraf
  • Stockage : Prometheus + Promscale
  • Affichage : Grafana (en deux parties pour public et privé)
  • Alerting : Alertmanager
  • Logging : Loki
    • Éviter ELK pour les problèmes dont on a parlé plus haut
    • Gray : licence SSPL, pas opensource: https://opensource.org/node/1099
    • Loki : minimaliste, pas de recherche d'index mais fait le taf, suffisant pour nous.

Notification de nos membres

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

  • statping, cf. https://status.gnuragist.es/
    • Complètement automatique pour les alertes
    • Les notification de mail sont explosées … (cela généré des spam car les mails sont mal formater)
    • Pas toujours de notification en cas de remise en route d'un service
    • Les commande custom pour les notifications
    • On ne sait pas trop si c'est à l'arrêt ou pas
    • Un bot ferme les tickets s'il n'y a pas de réponse….
  • Cachet
  • cstate
    • utilise du markdown pour faire les alertes/maintenance
  • AlertManager + mailing list

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)

  • Mails
  • Mattermost
  • SMS
  • Pigeons
  • Telegram/Matrix/Signal/IRC

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:

  • voir si c'est autorisé
  • quel opérateur ?
  • est-ce qu'on capte bien ?

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 :

  • Matrix + Mail
  • Signal (pas d'ACK apres 15m)
  • SMS (pas d'ack apres 1H) - Facultatif

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

  • Cachet (étudier)
  • Prometheus + Grafana + AlertManager + promscale sur la vm monitoring.htz.neutri.net
  • Pour recevoir les notifs AlertManager
    • Compte Matrix
    • Compte Signal
  • telegraf sur toutes les vm
  • Prometheus federateur sur man.patata.louise.neutri.net (vm de management)
  • Les dashboard dans grafana pleiiin de dashboards
  • Keycloak pour le sso de grafana
    • cluster postgresql
  • Changer le owner de monitoring.htz.neutri.net sur Hetzner (la VM est chez Tharyrok)
  • SMS
    • voir si possible LouiseDC
    • en parler réunion des membres pour les prix

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.

,
fr/rapports/2021/07-04.txt · Dernière modification : 2022/07/22 13:15 de 127.0.0.1