# 2021/07/04 (Neutriton) : Monitoring * [Réunion précédente](https://wiki.neutrinet.be/fr/rapports/2021/12-06) * [Pad de la réunion](https://pad.libre.brussels/neutrinet-neutriton-2021-07-04) 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](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. - https://github.com/statping/statping - https://github.com/CachetHQ/Cachet mais https://github.com/CachetHQ/Cachet/issues/4271 du coup https://github.com/fiveai/Cachet - https://github.com/cstate/cstate - https://www.solarwinds.com/pingdom - https://pagerduty.com - https://www.atlassian.com/software/statuspage ### 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 - Quid du SSO ? OpenDistro corrige ça (https://opendistro.github.io/for-elasticsearch/) - La licence ... https://www.elastic.co/fr/pricing/faq/licensing - ElasticSearch énergivore en ressources (humaines, techniques), gestion des indexes est accrobatique. (Mais outil très puissant.) 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: - https://www.elastic.co/fr/blog/elasticon-kibana-canvas-story-elasticoffee - https://www.elastic.co/fr/blog/getting-started-with-canvas-in-kibana ##### 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 node_exporter, 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 node_exporter. - L'autre école, c'est telegraf, qui de base a [beaucoup de plugins](https://docs.influxdata.com/telegraf/v1.19/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](https://www.librenms.org/) (utilise de vieilles technologies (snmp, rrd) mais fonctionne bien et est fait pour ça) Soit on utilise [promscale](https://github.com/timescale/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 :ghost: 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 : - Stack ELK - [GrayLog](https://www.graylog.org/) se base sur syslog et on peut rajouter du [fluentd](https://www.fluentd.org) - [Loki](https://grafana.com/oss/loki/) de Grafana 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](https://github.com/statping/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](https://github.com/CachetHQ/Cachet) - Manuel, automatisable avec une API (grace a alertmanager) - Possibilité de s'abonner (envoi de mails) - Il a des graph publique - À l'arret : https://github.com/CachetHQ/Cachet/issues/4271 mais il existe un fork : https://github.com/fiveai/Cachet qui n'est pas très actif - [cstate](https://github.com/cstate/cstate) - utilise du markdown pour faire les alertes/maintenance - AlertManager + mailing list Chez les propriétaires (oui c'est un peux du troll): - https://www.solarwinds.com/pingdom - https://pagerduty.com - https://www.atlassian.com/software/statuspage 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 : - https://www.ovhtelecom.fr/sms/ - https://www.ringring.be/ 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.* {{tag>infra neutriton}}