• Réunion précédente
• Pad de la réunion

Heure de début : 14h

Présences :

• HgO
• Célo
• Tharyrok

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

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é.

Fin: 17h grand grand marx

• Tester le plugin Mattermost pour Alertmanager
• Dupliquer l’envoi des alertes de Neutrinet sur Mattermost
• Désactiver la vue de l’alerting dans le grafana publique
  • https://github.com/grafana/grafana/issues/67300
• Faire le dashboard de monitoring interne des clients VPN, VM, …

On a déjà eu des discussions dans Neutrinet à propos de l'Altering. Donc on voit tous·ŧes de quoi il s'agit et on ne va pas se redire à ce niveau là.

Petit retour vers 2021 : https://wiki.neutrinet.be/fr/rapports/2021/07-04#notification_aux_admin_alerting

Les dernières discussions à ce sujet : https://wiki.neutrinet.be/fr/rapports/2023/06-11#status_page

En résumé, on aimerait pouvoir monitorer ainsi que mettre en place des alertes en plus de l'infra de Neutrinet pour:

• les briques
• les VPS
• les antennes dans les occupations de sans papiers

La question, c'est comment on ferait ça ? Comment proposer un service d'alerting à nos membres pour leurs briques et leurs VPS ?

Pour chaque service, cela va différer.

Par exemple, sur les briques, actuellement, on n'a pas la main sur les ressources, càd qu'il n'y a pas d'agent installé sur les briques pour nous envoyer des metrics. Mais cela serait faisable au moyen d'une app Yunohost, mais est-ce qu'on veut faire ça ? Donc, pour le moment, on peut monitorer avec une probe externe sur les urls ou les IPs.

Pour les VPS, on a les metriques de proxmox a notre disposition.

Pour les antenne des sans papier on pourrait installer une probe sur l'antenne. Mais actuellement il n'y a rien. Il n'est donc pour le moment pas possible de savoir si une antenne est tombée.

Pour les connexions internet on pourrait tester si l'IP répond. Plus tard quand freeradius sera utiliser on aura l'information via le protocole radius.

Enfin, l'infra de Neutrinet : on reçoit des alertes sur Matrix, via le petit matrix-alertbot : https://git.domainepublic.net/Neutrinet/matrix-alertbot Par contre, comment faire pour notifier nos chers membres lorsque l'infra est par terre ?

Il y a beaucoup de service de l'infra de Neutrinet que nous ne monitorons pas, parfois on a déjà les metriques dans victoria mais sans aucune alerte. Il faudrait faire un inventaire des alertes et dashboards manquants, avec des priorités, parce que malheureusement mettre en place tout ceci prendra du temps. Il faut aussi penser aux innhibitions entre les alertes, par ex. ne pas déclencher les alertes liées aux VMs si le serveur Proxmox est par terre.

Il y avait aussi une envie de proposer du monitoring et de l'alerting pour les gens de la FFDN.

On peut suivre : https://samber.github.io/awesome-prometheus-alerts/rules.html

On va faire un tour des canaux actuels pour les alertes à destination de nos membres.

• Salon Matrix, commun à tout le monde, pour les alertes des disponibilité des briques
• Salon Mattermost, pareil que salon Matrix ci-dessus
• Status page, qui informe sur la disponibilité du VPN et des briques monitoré par nos soin : https://uptime.neutrinet.be
• Mail pour l'expiration du certificat du VPN

Pour Mattermost, un des soucis est qu'il ne permet pas de recevoir des notifications sur mobile dégooglisé.

Gotify est un client qu'on peut installer sur notre smartphone et qui permet de pousser des notifications.

Une alternative ce serait de basculer RocketChat : https://www.rocket.chat/

Pour le monitoring de brique le besoin est de recevoir une alerte en privé lier a la brique du membre. Cela évite le bruit et en temres de vie privée, c'est mieux qu'un canal commun.

Cela signifie d'avoir un bot qui va inscrire la brique de la personne dans le monitoring. Cela peut se faire par les admins du bot au début, mais idéalement ce serait les gens qui s'inscrivent tout seul.

Actuellement, le bot que nous avons sur matrix peut faire des discussions privées et relayer les alertes du membre. Il faut rajouter du code pour qu'il gère les invitations, les envois d'alertes en privé et la création des alertes, etc.

Pour Mattermost, il faudrait créer un bot qui va ouvrir des discussions privées, etc. C'est plus optimal parce qu'on a la main sur notre infra, et donc on peut générer des tokens.

Pour RocketChat, ce serait comme pour Mattermost.

Les questions, c'est est-ce un service que l'on gere ou un service qu'on ne gere pas ? Et est-ce qu'on veut réutiliser un bot existant ou est-ce qu'on part sur un nouveau truc ? Et est-ce qu'on part du principe qu'on monitore tout le monde par défaut ou que cela se fait sur demande du ou de la membre ?

Si on essaie de résumer le workflow :

L'utilisateur ferait une demande d'alerting de sa brique. Il envoie un message au bot “coucou je voudrais que tu monitores ce nom de domaine”.

Pour cela, il faut que les metrics liées à son nom de domaines soient présentes dans VictoriaMetrics. Ensuite, il faut rajouter l'alerte dans AlertManager. Et il faut ajouter un label pour indiquer pour quel utilisateur le bot doit relayer l'information.

De là, le bot reçoit une alerte. Si il voit le label correspondant à utilisateur, il crée un message dans le canal privé.

Au début on peut généré un token que l'utilisateur envoie au bot pour lier le cannal privé vers ces propres alerte/label.

Idéalement, on aimerait améliorer le matrix-alertbot pour prendre en charge les salons privés dans Matrix, et aussi avoir la possibilité d'envoyer les alertes sur un Mattermost. Il n'y a que 24h dans une journée, donc on va d'abord améliorer la partie Matrix.

Pour le hub cube, on pourrait avoir un monitoring des IPs du VPN qui sont allouées et avoir un dashboard dans Grafana. Mais il faut voir comment procéder. On peut monitorer les IP, mais les protocoles icmp et http peuvent être bloqués, donc le plus fiable est de le faire via openvpn.

Pour le moment, on a déjà un exporter qui nous donne l'info du nombre de clients VPN connectés. Il faudrait juste récupérer l'info pour chaque IP si elle est connectée ou non, et aggréger les données pour le dashboard public d'OpenVPN.

Ici aussi, on part de quelque chose qui existe. Ce n'est pas beaucoup de travail car c'est adapter des scripts, en tous cas pour les IPv4. Si on voulait aussi monitorer les IPv6, c'est plus compliqué. On pourrait filtrer pour n'avoir que les IPv6 /128 de lien (celles qui sont là par défaut).

Il faudrait faire un sondage pour savoir qui serait intéressé pour avoir un système d'alertes pour leur brique. TODO pour le hub comm

Le bot pourrait aussi être utilisé par le hub infra pour communiquer individuellement lorsque l'infra est down.

Il y a un tradeoff entre l'utilisation d'un outil qui est pas forcément utilisé par les membres et le fait d'utiliser un outil où ils sont confortables. Mais dans ce cas on entre aussi dans une sorte de relation client, ce qui est pas très sain…

Pour ce qui est du lien compte Matrix et compte VPN, au début ce sera fait à la main. Il faut pouvoir lancer un playbook ansible pour configurer blackbox-exporter et Alertmanager (ce dernier pourrait être fait de manière dynamique à terme).

Actuellement, on a un VictoriaMetrics qui récupère toutes les metrics. Il est protégé derrière un login / mot de passe en basic auth. Celui-ci est commun à toutes nos probes.

• Est-ce qu'il faut avoir plusieurs VictoriaMetrics ?
  • un des problèmes c'est si les identifiants sont sur des antennes wifi accessible à tout le monde quid si quelqu'un recupère les identifiants pour acceder à VictoriaMetrics ?
  • si le VictoriaMetrics de Neutrinet plante on ne recupère plus aucune metrics ?
  • est-ce qu'il faut une instance par niveau de rétention ? Ou une instance pour tout Neutrinet et une instance pour les sans-papiers ?
• Quelle rétention des infos faut-il ?

  1. Cela prend de la place, c'est une retention par instance de VictoriaMetrics
  2. Actuellement, on garde les metrics pendant 3 ans, est-ce qu'il faut la même rétention pour les antennes des sans papiers ?
• Quid de l'accès au grafana ?
• Quid de l'historique dans matrix ?
  • Le bot doit-il effacer les message au bout d'un certain temps ? Vu que c'est “juste” de l'alerting, cela ferait sens car ça n'a pas d'utilité de garder l'historique, ce sont des alertes…

On peut avoir plusieurs VictoriaMetrics en fonction de la rétention et créer un utilisateur uniquement en écriture seule pour garentire une certaine vie privé, seul grafana/alertmanager a besoin de lire dans VictoriaMetrics.

Il faut adapter le playbook Ansible pour permettre de déployer plusieurs VictoriaMetrics sur le même serveur.

Qu'est-ce qu'on monitorerait pour chaque VictoriaMetrics:

• Sans papiers (3 ans) : nombre de clients connectés à l'antenne, bande passante, uptime, qualité du signal
• VPN (Briques, Parpaings)/FFDN (6 mois): url, ping, tls
• Ketupa (VPS, Backups borg) : CPU, RAM, bande passante, backup, snapshot - nb : il y aura de toute façon besoin d'un VictoriaMetrics pour Ketupa.
• Infra : metrics actuelles

On va avoir 2 AlertManager:

• un pour Neutrinet publique
• un pour le reste privé qui ne sera pas dans grafana

Il faut en priorité configurer les antennes qui vont être placées chez les sans papiers pour envoyer les metrics vers le bon victoriametrics.

TODOux (dans l'ordre) :

• Config haproxy pour le domaine metrics-100pap.neutrinet.be avec un user basic auth uniquement sur l'uri insert/prometheus. Dans un premier temps sur le victoriametric de Neutrinet, si on a le temps dans son propre victoriametric.
• Config telegraf + anonymisation des mac address + refaire les images openwrt.
• Faire le dashboard pour les antennes des sans papiers
• Casser l'aggrégation des IPs du VPN et faire le dashboard a destination du hub-cube. Adapter le dashboard public OpenVPN.
• Adapter le playbook VictoriaMetrics pour créer plusieurs instances
• Refactorer le bot matrix pour envoyer les alertes en privé. Et casser les salons publics.
• Créer le playbook pour config le probe et les alerte pour les VPN/FFDN à la main. Dépend du bot et inversement.

Prochaine réunion : Neutriton Authority DNS 10/03 à 14:00

Lieu : Jitsi & Caldarium

Garde-Pad : Tharyrok

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.