Dans mes expériences avec Grafana et Prometheus je me contentais jusque là de reproduire avec des outils plus dans l’air du temps des fonctions remplies par Munin. Cela revient à mettre sous forme graphique des métriques numériques en montrant leurs évolutions au cours du temps. Le billet précédent clôt ce chapitre avec la mise en place d’une surveillance de l’état de mes services HTTP.
Loki un concentrateur de log
Grafana Labs la compagnie dernière Grafana (et Prometheus en employant les mainteneurs du projet) a developpé en 2018 un équivalent de Prometheus pour les journnaux ie les logs: Loki. Il s’agit de concentrer les logs en provenances de divers composants d’une application afin de pouvoir les corréler entre elles et avec les métriques d’autres sources comme Prometheus au sein de Grafana.
Promtail pour exposer les log …
Pour alimenter Prometheus il faut des métriques qui sont fournies par les applications elles-même ou part des outils intermédiaires qui exposent les valeurs pour Prometheus. Comme par exemple blackbox vu dans un billet précédent. De même pour les log, il y a l’outil intermédiaire Promtail qui va lire les logs dont la spécification est bien-sûr paramétrable pour ensuite les rendre disponibles dans Loki.
… en mode push
La différence avec Prometheus est que l’alimentation des log se fait en mode push. En effet contrairement aux métriques qui sont en générale intégrées dans Prométheus sur l’initiative de Prometheus (mode pull), l’alimentation de Loki par Promtail se fait sur initiative de Promtail (mode push).
Le schéma suivant montre en vert les composants que je mets en œuvre pour la concentration des logs de mon infra. Au conteneur Loki, j’ajoute un conteneur Promtail sur chacun des noeud pour avoir les log du système hôte via un montage du répertoire /var/log.
Cette architecture est valable dans le cadre de mon infra composée d’une seule machine physique. On voit bien que les logs sont envoyées à Loki sans confidentialité (sans passer par une brique HTTPS) ni authentification de celui qui pousse (sans un BASIC AUTH au moins). Voilà une exercice pour le prochain billet !
Mais avant de mettre en place des mécanismes de sécurités je vais tâcher d’extraire des logs plus pertinentes au regard de mes besoins de supervision: comme la log du frontal apache ou celles des services même.
Source de mes fichiers relatifs à docker:
- docker-compose pour les neouds à superviser: ajout de promtail
- docker-compose pour le monitoring: ajout de Loki