Monitorer son infra avec Warp 10 – partie 1

Introduction

Sous ce titre pompeux et aguicheur, je vais vous expliquer avec une série de posts comment je monitore mon infrastructure IT domestique (comprenez 3 Raspberry Pi).

Ok, ça fait un peu tromperie sur la marchandise, mais le principe est le même sur une infra plus classique (sauf pour la partie alerting, mais on y reviendra).

Comme beaucoup de geek, j’ai quelques Raspberry Pi à la maison et celui qui gère la domotique est un tantinet important. Il y a quelques années, j’utilisais Nodequery, mais leur blog et leur Github sont sans vie depuis 2014… bref rien de bien encourageant quant à la pérennité du service. De plus, je souhaitais avoir la main sur les données et remonter bien plus que ce que ne fait Nodequery.

Alors oui, plein de gens vous expliqueront que c’est trop cool de le faire avec Influx+Grafana ou Prometheus mais c’est surtout trop limité.

Mon choix s’est porté sur Warp 10 qui, en plus de gérer bien plus efficacement que Influx ou Prometheus les séries temporelles (oui, les données de monitoring sont des séries temporelles), il offre un langage puissant de manipulation de cette typologie de données (nous y reviendrons dans un prochain post) que ne proposent pas les autres (non, le select * n’est pas un langage de manipulation évolué).

Warp 10 est assez versatile et non limité au monitoring (contrairement aux autres que j’ai cité), on peut bâtir bien des choses avec. Cependant, dans le domaine du monitoring, il vient avec un petit agent qui s’appelle Sensision. Cet agent n’est pas super documenté, mais l’éditeur de Warp 10 (SenX) ne mets pas forcément l’accent sur le use case du monitoring. Et puis je peux me sortir les doigts du slip et creuser un peu quand même.

Dans ce premier post je vais vous expliquer l’architecture et l’installation de Warp 10 et de Sensision.

Architecture générale

L’idée est de déployer un agent Sensision sur chacun de mes Raspberry. Chacun de ces agents va remonter des métriques sur une instance centrale de Warp 10. Enfin, on va pouvoir se construire un dashboard et du monitoring (niveau CM1) pour surveiller tout ça.

Warp 10

Installer Warp 10, c’est simple. C’est plus rapide avec Docker :

$ docker run -d \
  -p 8080:8080 -p 8081:8081 \
  --volume=/opt/warp10:/data \
  --name=warp10 warp10io/warp10:latest

Je ne vais pas rentrer dans le détail de l’utilisation ou du paramétrage de Warp 10, leur blog couvre beaucoup de choses. Et si vous préférez l’installer hors Docker, c’est à peine plus compliqué.

Warp 10 fonctionne parfaitement sur Raspberry et à fortiori également sur un vrai serveur. J’ai choisi de l’installer sur un Raspberry via Docker (crade mais fonctionnel).

Une fois installé, il va nous falloir des jetons (tokens):

$ docker exec -u warp10 -it warp10 warp10-standalone.sh worf monitor 315360000000

Ici je crée une paire de jetons (read/write) valable 10 ans pour une application nommée « monitor ».

Conservez bien ces jetons présents dans les champs read et write de la structure JSON.

Et hop Warp 10 est opérationnel.

Sensision

Il n’y a pas d’image Docker pour Sensision, mais vous pouvez en créer une, c’est pas très complexe.

Allez zou! Je me logue sur mon Raspberry en ssh, puis:

$ cd /opt
$ sudo su
$ wget https://github.com/senx/sensision/releases/download/1.0.24/sensision-service-1.0.24.tar.gz
$ tar xf sensision-service-1.0.24.tar.gz
$ useradd sensision
$ chown -R sensision:sensision sensision-1.0.24
$ cd sensision-1.0.24
$ ./bin/sensision.init start

Arrivé ici Sensision va créer les fichiers de conf qui vont bien.

Avant d’aller plus loin, on va modifier /etc/fstab et créer des RAMDisk pour éviter de matraquer la carte SD (et la bousiller trop vite). Ici je présume que le user sensision a comme id 1001 (idem pour son groupe)

$ vi /etc/fstab

tmpfs /var/tmp tmpfs defaults,noatime,nosuid,size=10m 0 0
tmpfs /var/log tmpfs defaults,noatime,nosuid,mode=0755,size=10m 0 0
tmpfs /opt/sensision-1.0.24/logs tmpfs defaults,noatime,nosuid,nodev,noexec,mode=0777 0 0
tmpfs /opt/sensision-1.0.24/targets tmpfs defaults,noatime,nosuid,nodev,noexec,mode=0777 0 0
tmpfs /tmp tmpfs defaults,noatime,nosuid,nodev,noexec,mode=0755,size=10M 0 0

Bon, on peut faire mieux (je suis ouvert aux propositions).

L’étape suivante consiste à paramétrer Sensision, ça se fait dans /opt/sensision-1.0.23/etc/sensision.conf (le fichier créer avec le premier start).

D’abord, des labels dédiés à votre serveur, ici j’ai host qui contient l’adresse IP et hname qui contient son petit nom. Vous pouvez en ajouter d’autres.

[...]
sensision.default.labels=host=192.168.60.xxx,hname=monPi
[...]

Puis il faut configurer le endpoint de Warp 10:

[...]
#
# Default queue
#
#
sensision.qf.url.default=http://ip.de.warp10/api/v0/update
sensision.qf.token.default=C0[xxxxxx]CV
sensision.qf.topn.default=250
sensision.qf.period.default=1000
sensision.qf.batchsize.default=10000
[...]

• sensision.qf.url.default doit contenir le chemin vers votre instance de Warp 10.
• sensision.qf.token.default doit contenir votre token d’écriture (write) défini plus haut.

Le reste on ne touche pas.

Démarrons Sensision sous forme de service. Il faut créer le fichier /opt/sensision-1.0.23/bin/sensision.service :

[Unit]
Description=Sensision

[Service]
Type=forking
User=root
ExecStart=/opt/sensision-1.0.24/bin/sensision.init start
ExecStop=/opt/sensision-1.0.24/bin/sensision.init stop
SuccessExitStatus=143
RestartSec=10s
TimeoutStartSec=60s
#If you do not want systemd to monitor and restart Warp 10 automatically, comment the restart always option:
Restart=always
ConditionPathIsMountPoint=/opt/sensision-1.0.24/targets
#You can customize system limits here: see https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Process%20Properties
#LimitNOFILE=1000000
#LimitCORE=infinity
#LimitNPROC=32000
#LimitMEMLOCK=500000

[Install]
WantedBy=multi-user.target

Puis en tant que root :

$ ln -s /opt/sensision-1.0.24/bin/sensision.service /etc/systemd/system/sensision.service
$ systemctl daemon-reload
$ systemctl enable sensision
$ systemctl start sensision
$ journalctl -f -u sensision // Pour vérifier que c'est bien démarré

Il n’y a plus qu’à rebooter le Pi (à cause du FSTab) et il est monitoré.

Dans un prochain chapitre, nous explorerons les métriques de Sensisions et nous construirons notre premier dashboard.