Dans le cadre personnel, je possède plusieurs Raspberry Pi (RPi) qui font tourner plusieurs services et je souhaitais comprendre ce qu’il se passait dessus. Voici, basiquement, à quoi ils servent :
Au travail, quand on pense monitoring, on pense immédiatement à de grosses solutions comme InfluxDB, ELK…mais est-ce ce dont j’ai besoin ?
Mais qu’est ce que le monitoring ?
Monitorer consiste à surveiller le bon fonctionnement d’un système et à réagir en fonction de critères : alerting, redémarrage de service… Cette surveillance peut se faire à différents niveaux : machine, applications (logs, événements), réseau…
Pour ma part, je souhaite :
Un point sur les différents termes :
La solution que je recherche est un outil de supervision. Je ne souhaite pas pour l’instant être notifié en cas d’échec.
🔺 Dans le cadre d’un usage professionnel, afficher des graphiques n’a aucun intérêt :
le nombre de services est trop important pour demander à un humain de les surveiller.
Il faut prévoir des alertes en définissant sur quels critères pertinents elles seront lancées.
Les graphiques seront utilisés ponctuellement pour comprendre un problème, pourquoi une alerte a été levée.
Voyons les solutions du marché existantes ?
Plusieurs solutions existent pour faire du monitoring ou du stockage timeseries (évolution d’une mesure dans le temps).
Dans toutes ces solutions, il faut installer des agents sur les machines à surveiller afin de collecter les métriques et les envoyer à un serveur central :
Ces outils sont performants, mais dans mon contexte :
Alors que choisir ? Je ne vais quand même pas coder cette solution moi-même…et puis pourquoi pas ?
Avant de coder une solution à la main, étudions le fonctionnement d’une base distribuée qui peut stocker des données temporelles, Cassandra.
Quand on utilise une base de données NoSQL, la seule question que l’on doit se poser est “comment est ce que je veux retrouver mes données ?”. Il ne faut pas s’imaginer stocker des données de manière désordonnée pour espérer plus tard les retrouver.
Dans une base distribuée, le fait d’interroger, lors d’une requête, l’ensemble des nœuds, produira de mauvaises performances :
Si on veut avoir une lecture plus efficace, les données à lire doivent être colocalisées. En ayant les données à rechercher sur la même machine et contigües, on les lira en une seule fois. Cassandra illustre très bien ce mécanisme dans sa conception.
Cassandra est une base de données colonne, c’est-à-dire que pour une clé donnée, on va lire un certain nombre de colonnes.
La clé de partition (PK) permet de définir sur quelle machine se trouve les données
tandis que la clé de cluster (clustering key / CK) est la clé d’unicité sur la machine. Les données sont également regroupées pour une même CK.
Schéma de stockage
Comment Cassandra stocke ses données ? Cela se fait en plusieurs étapes :
Cassandra est rapide en écriture car les nouvelles données sont stockées en mémoire et dans un fichier non structuré de manière séquentielle. Ce qui est intéressant, c’est que pour proposer une écriture efficace, il ne faut pas écrire les données de manière systématique et l’écriture contigüe est plus efficace que l’écriture aléatoire (surtout sur des disques mécaniques).
En fonction de notre besoin et de notre capacité à accepter la perte de données, nous choisirons à quelle fréquence il faut écrire les données.
Pour déterminer la fréquence, il faut calculer ce que l’on va stocker :
Si l’on souhaite sauvegarder les données quand notre buffer atteint 100 valeurs, la perte maximum en cas de crash sera de 8 minutes. Il est possible, comme Cassandra, d’éviter de perdre des données en sauvegardant dans un fichier non structuré, utilisé uniquement pour la récupération, les métriques dès qu’elles arrivent.
Au terme de cet article, nous avons vu ce qu’était le monitoring, défini quel était mon besoin et étudier le fonctionnement d’une base distribuée.
Désormais, nous allons pouvoir passer aux choses en sérieuses en écrivant notre propre solution de monitoring dans la 2ème partie de cet article.
