Utilisation

TL;DR : ça se passe sur https://grafana.grenode.net avec des identifiants précisés dans le password store.

Principe et besoin

Grenode dispose déjà de LibreNMS pour le monitoring réseau, qui permet de visualiser la quantité de trafic sur les différents liens du réseau. Cet outil est très satisfaisant de manière générale.

Cependant, LibreNMS n'est pas adapté pour certains usages, notamment en cas d'attaque volumétrique (DDoS) :

• la résolution des données est de quelques minutes (typiquement 5 minutes), ce qui ne permet pas d'identifier précisément des attaques de courte durée ;

• si le réseau est saturé, LibreNMS ne va pas pouvoir interroger les routeurs, provoquant des trous dans les données de traffic, précisément au moment où elles seraient le plus intéressantes.

Il est donc nécessaire de mettre en place une solution complémentaire pour faciliter l'analyse a posteriori des niveaux de traffic sur le réseau en cas d'incident. Cette solution doit être :

• robuste (collecte des données même si le réseau est en panne ou saturé)

• haute fréquence (résolution de l'ordre de la seconde)

A noter qu'il s'agit ici simplement de mesurer des quantités de traffic sur des interfaces réseau (débit instantané), et non de faire de l'analyse poussée de flux réseau ou de la capture de paquet.

Architecture

Pour assurer que la collecte de données soit robuste, les données de traffic sont stockées localement sur chaque routeur, au moins de manière temporaire, puis exportées vers un serveur central. Ainsi, même si tous les liens réseau du routeur sont complètement saturés, les données de traffic sur ses interfaces peuvent être collectées et stockées localement. Dès que l'incident est terminé, les métriques peuvent être exportées vers le serveur central.

Le serveur central stocke l'ensemble des données remontées par les routeurs de façon pérenne, et fournit une interface pour visualiser les données.

Il faut noter que cette architecture est possible parce que nos routeurs sont des simples machines sous Linux. Ce serait plus complexe avec des routeurs "hardware" de type Cisco ou Juniper si une telle fonctionnalité n'est pas prévue par le constructeur.

Sur les routeurs

Deux services sont installés sur chaque routeur :

• prometheus-node-exporter qui expose les métriques du système. Il est configuré pour écouter uniquement sur localhost, et pour ne renvoyer que les métriques liées aux interfaces réseau.
• prometheus qui vient interroger le prometheus-node-exporter à une fréquence élevée (3 secondes d'intervalle). Il est configuré pour recopier les données via un "remote write" vers le serveur central de monitoring. Mais par ailleurs, toutes les données sont conservées en local pendant plusieurs jours voire semaines via la politique de rétention de Prometheus. En cas d'incident, c'est le "remote write" qui s'assure que toutes les données sont, à terme, bien transmises au serveur central.

Sur le serveur de monitoring

Deux services sont installées sur le serveur central de monitoring :

• victoria-metrics, une TSDB, qui vient aggréger les données des routeurs et les stocker de façon pérenne. Le service est en écoute sur le réseau pour recevoir les métriques. Les routeurs s'authentifient via une simple authentification basique HTTP sur une connexion sécurisée HTTPS.

• grafana qui permet de visualiser les données. Il est configuré avec une "data source" de type Prometheus, puisque victoria-metrics implémente la même API que Prometheus.

Ces deux services sont exposés derrière un reverse proxy Nginx qui gère HTTPS ainsi que l'authentification basique HTTP.

Dashboard de visualisation

Pour l'instant nous utilisons simplement le dashboard Grafana standard pour la partie réseau du node-exporter. A terme, il sera intéressant de mettre en place un dashboard plus adapté et plus personnalisé.

Mise en place chez Grenode

Sur les routeurs

L'installation et la configuration des services est faite par Ansible pour s'assurer que c'est cohérent entre tous les routeurs.

node-exporter

prometheus-node-exporter est installé via les paquets Debian standard, disponible depuis stretch : https://packages.debian.org/bullseye/prometheus-node-exporter

La configuratin est faite dans /etc/default/prometheus-node-exporter. D'abord on bind uniquement sur localhost :

ARGS="--web.listen-address=localhost:9100"

Ensuite, on veut désactiver tous les plugins sauf les métrique réseau. En effet, collecter toutes les métriques à haute fréquence serait trop coûteux en CPU et en stockage. A partir de Debian bullseye, c'est facile à faire :

ARGS="--web.listen-address=localhost:9100 --collector.disable-defaults --web.disable-exporter-metrics --collector.netdev"

Cependant, sur les versions plus anciennes du node-exporter, il n'est pas possible de désactiver tous les plugins d'un seul coup... Voir https://github.com/prometheus/node_exporter/issues/735. Avec Debian buster et antérieur, il faut donc désactiver individuellement chaque plugin :

ARGS="--web.listen-address=localhost:9100 --web.disable-exporter-metrics --collector.netdev \ --no-collector.arp \ --no-collector.bcache \ --no-collector.bonding \ --no-collector.buddyinfo \ --no-collector.conntrack \ --no-collector.cpu \ --no-collector.diskstats \ --no-collector.drbd \ --no-collector.edac \ --no-collector.entropy \ --no-collector.filefd \ --no-collector.filesystem \ --no-collector.hwmon \ --no-collector.infiniband \ --no-collector.interrupts \ --no-collector.ipvs \ --no-collector.ksmd \ --no-collector.loadavg \ --no-collector.logind \ --no-collector.mdadm \ --no-collector.meminfo \ --no-collector.meminfo_numa \ --no-collector.mountstats \ --no-collector.netclass \ --no-collector.netstat \ --no-collector.nfs \ --no-collector.nfsd \ --no-collector.ntp \ --no-collector.processes \ --no-collector.qdisc \ --no-collector.runit \ --no-collector.sockstat \ --no-collector.stat \ --no-collector.supervisord \ --no-collector.systemd \ --no-collector.tcpstat \ --no-collector.textfile \ --no-collector.time \ --no-collector.timex \ --no-collector.uname \ --no-collector.vmstat \ --no-collector.wifi \ --no-collector.xfs \ --no-collector.zfs\ "

Prometheus en cache

Côté Prometheus, on utilise également le paquet dans les dépôts Debian. On commence par binder sur localhost, et on garde les données en cache pendant 30 jours :

# /etc/default/prometheus
ARGS="--storage.tsdb.retention.time=30d --web.listen-address=127.0.0.1:9090"

Ensuite, on configure le scraping à haute fréquence du node-exporter local ainsi que le "remote write" vers le serveur de monitoring :

```

/etc/prometheus/prometheus.yml

global: scrape_interval: 3s evaluation_interval: 3s

scrape_configs: - job_name: node scrape_interval: 3s scrape_timeout: 2s static_configs: - targets: ['localhost:9100'] relabel_configs: - source_labels: [address] regex: '.*' target_label: instance replacement: 'myroutername.grenode.net'

remote_write: - url: https://mymonitoringserver.grenode.net/api/v1/write basic_auth: username: myrouterusername password: myrouterpassword ```

Sur le serveur de monitoring

Victoria Metrics

victoria-metrics est également installé via les paquets Debian standard, disponibles à partir de Debian bullseye. C'est l'une des raisons du choix de cette TSDB plutôt qu'une des nombreuses autres options.

Le service est configuré pour écouter uniquement sur localhost, puisque c'est Nginx qui se chargera d'écouter sur le réseau (reverse proxy). Par ailleurs, on définit la durée de rétention des données à 5 ans. La configuration se fait dans /etc/default/victoria-metrics :

```

/etc/default/victoria-metrics

ARGS="-storageDataPath=/var/lib/victoria-metrics -httpListenAddr localhost:8428 -retentionPeriod 5y" ```

Victoria n'a pas besoin de base de données, il stocke ses données sous forme de fichiers avec son propre format. Il faut évidemment s'assurer d'avoir assez de place disque et surveiller le remplissage du disque, ce que nous faisons par ailleurs avec ?Supervision-checkmk. Nous estimons que nous aurons besoin de moins de 1 GB d'espace disque par an, avec 2 routeurs et une vingtaine d'interfaces réseau chacun.

Grafana

Grafana n'est malheureusement pas packagé dans Debian. En revanche, le projet fournit des dépôts Debian extérieurs : https://grafana.com/docs/grafana/latest/installation/debian/

La seule configuration nécessaire est de limiter l'écoute à localhost, ce qui se fait dans une section du fichier /etc/grafana/grafana.ini :

``` [server]

Protocol (http, https, h2, socket)

protocol = http

The ip address to bind to, empty will bind to all interfaces

http_addr = localhost

The http port to use

http_port = 3000

The public facing domain name used to access grafana from a browser

domain = grafana.grenode.net ```

Nous partons du principe que le reste de la configuration (datasources, dashboards) sera faite via l'interface web. Cette configuration est stockée par défaut dans une base sqlite (/var/lib/grafana/grafana.db), ce qui nous va très bien.

Nginx

Il s'agit de deux reverse proxy tout à fait standard avec certificat HTTPS obtenu via Let's Encrypt :

• tsdb.grenode.net pour recevoir les métriques des routeurs, qui fait un reverse proxy vers le victoria-metrics local. On ajoute également une authentification HTTP :

  sudo apt install apache2-utils sudo htpasswd -c /etc/nginx/htpasswd.tsdb myrouterusername

location / { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_pass http://localhost:8428; auth_basic "Private"; auth_basic_user_file /etc/nginx/htpasswd.tsdb; }

• grafana.grenode.net pour l'interface web utilisateur, qui fait un reverse proxy vers le Grafana local.