Loki, centralisation de logs à la sauce Prometheus

Cet article est une rapide introduction à Loki. Ce projet est soutenu par Grafana et a pour but de centraliser des journaux d’activités (serveurs ou conteneurs).

La source principale d’inspiration de Loki vient de Prometheus, avec l’idée de l’appliquer à la gestion des logs, le but étant de disposer du même mécanisme :

• utilisation d’étiquettes (labels) pour le stockage des données ;
• réclamer très peu de ressources pour son exécution.

Dans ce qui va suivre, nous allons revenir sur le principe de fonctionnement de Prometheus et donner quelques exemples d’utilisation dans le cadre d’un déploiement sous Kubernetes.

Sommaire

• Un mot sur Prometheus
• Origine du besoin
• Méthode de résolution d’incidents
• Test de Loki en local
• Architecture de Loki
• Déploiement dans Kubernetes
  • Installation de Helm
  • Ajout de la source Helm
  • Déploiement de Loki
• Connexion à Grafana
• Définition de la source de données Loki depuis Grafana
• Interrogation du moteur Loki
• Inclusion dans un tableau de bord
• Futur de Loki

Un mot sur Prometheus

Afin de bien comprendre le fonctionnement de Loki, il est important de comprendre celui de Prometheus. Le lecteur est invité à lire une publication précédente dans ces colonnes : « Découverte de l’outil de supervision Prometheus ». Même si le produit a évolué entretemps (la version 2.0.0 venait de sortir), ce qui est écrit reste tout à fait valable avec la dernière version (2.14).

La caractéristique de ce produit est de récupérer des métriques en provenance de points de collecte (on parle d’exportateur) et de les stocker dans une base de données de type Time Series en y ajoutant des métadonnées sous forme d’étiquettes (labels).

Origine du besoin

Ces derniers temps, Prometheus est devenu un standard de fait dans le monde de Kubernetes : son installation est très simple à réaliser et l’ensemble des briques d’une grappe de serveurs Kube dispose nativement d’un end‑point Prometheus. Le moteur Prometheus est également en mesure de récupérer des métriques en provenance des applications déployées dans ce type de grappe de serveurs tout en reprenant les étiquettes définies. La surveillance des consommations applicatives est donc très simple à mettre en œuvre.

Malheureusement, du côté des journaux, il n’y a pas encore de méthode clé en main et l’utilisateur doit trouver sa propre solution :

• un service géré de centralisation des journaux dans le cloud (AWS, Azure ou Google) ;
• un service de supervision « monitoring as a service » (type Datadog) ;
• la mise en place d’un service de centralisation.

Au niveau de la troisième solution, votre serviteur avait traditionnellement l’habitude de mettre en place Elasticsearch, avec de nombreuses réserves à propos de ce produit, notamment sur sa lourdeur et la difficulté de sa mise en place.

Loki a justement été conçu dans le but de simplifier cette mise en place en répondant aux critères suivants :

• être un produit simple à démarrer ;
• consommer peu de ressources ;
• fonctionner tout seul sans intervention de maintenance particulière ;
• servir de support à l’investigation en complément de Prometheus en cas de pépin.

En revanche, cette légèreté se fait au prix de certains compromis. L’un d’eux est de ne faire aucune indexation du contenu. La recherche de texte n’est donc de ce point de vue pas très performante ni très riche et ne permet pas de faire des statistiques sur le contenu du texte. Mais comme Loki se veut être un équivalent de grep et doit servir de complément à Prometheus, ce défaut n’en est pas un.

Méthode de résolution d’incidents

Pour mieux comprendre en quoi Loki n’a pas besoin d’indexation, nous allons revenir sur la méthode utilisée par les concepteurs de Loki avec le schéma suivant :
1 Alert → 2 Dashboard → 3 Adhoc Query → 4 Log Aggregation → 5 Distributed Tracing → 6 Fix!

L’idée est de partir d’une source d’alerte (notification Slack, SMS, etc.). La personne en charge du suivi fait alors la démarche suivante :

• consultation des tableaux de bord Grafana ;
• consultation des métriques brutes (dans Prometheus, par exemple) ;
• consultation des journaux (Elasticsearch, par exemple) ;
• éventuellement, consultation des traces distribuées (Jaeger, Zipkin, etc.) ;
• enfin, correction du dysfonctionnement.

Ici, dans le cas d’un empilement (stack) Grafana + Prometheus + Elasticsearch + Zipkin, l’utilisateur devra changer quatre fois d’outils. Afin de réduire les temps d’intervention, l’idée est de tout faire avec un seul outil : Grafana. À noter que Grafana propose cette notion d’exploration depuis la version 6. Il devient ainsi possible de consulter les données brutes de Prometheus directement depuis Grafana.

Depuis cet écran, il est possible de consulter les journaux de Loki associés aux métriques de Prometheus, notamment en faisant appel à la notion de découpage de l’écran. On imagine très bien qu’une fois que Loki aura été correctement intégré dans Grafana, la suite des travaux se fera sûrement sur l’intégration de Grafana et des outils de traçage distribués.

Test de Loki en local

Le plus simple pour tester Loki en local est de passer par Docker et l’outil docker-compose. Le fichier docker-compose se trouve sur le dépôt de Loki. La récupération du contenu de ce dépôt se fait à l’aide de la commande git suivante :

git clone https://github.com/grafana/loki.git

Reste ensuite à se rendre dans le répertoire production :

cd production

De là, il est possible de récupérer la dernière version des images Docker :

docker-compose pull

Enfin, la pile de Loki se lance à l’aide de la commande suivante :

docker-compose up

Architecture de Loki

Un petit dessin valant toujours mieux qu’un long discours, ci‑dessous un petit schéma de principe de Loki :

 Un client Web fait tourner des applications sur le serveur, Promtail en collecte les journaux qu’il envoie à Loki, le client Web envoie aussi des métadonnées à Loki. Loki agrège le tout et transmet à Grafana.

Loki est démarré. Afin de consulter les composants présents, lancez la commande suivante :

docker ps

Dans le cas d’un démon Docker fraîchement installé, la commande doit alors renvoyer la sortie suivante :

... IMAGE            ... PORTS                           NAMES
... grafana/promtail:...                                 production_promtail_1
... grafana/grafana:m... 0.0.0.0:3000->3000/tcp          production_grafana_1
... grafana/loki:late... 80/tcp, 0.0.0.0:3100->3100/tcp  production_loki_1

On retrouve les briques suivantes :

• Promtail : un agent qui prend en charge la centralisation des journaux (Promtail, pour Tailing logs in Prometheus format) ;
• Grafana : le célèbre outil de mise en page des données ;
• Loki : le démon de centralisation des données.

Dans le cadre d’une installation sur infrastructure classique (à base de machines virtuelles par exemple), l’agent Promtail devra être déployé sur chaque machine. Grafana et Loki pourront être éventuellement installés sur la même machine.

Déploiement dans Kubernetes

L’installation des briques de Loki dans Kubernetes va s’appuyer sur les éléments suivants :

• un gestionnaire de démons (DaemonSet) pour déployer l’agent Promtail sur chacune des machines de la grappe de serveurs ;
• un déploiement (Deployment) pour déployer la partie Loki ;
• et un dernier déploiement pour Grafana.

Par chance, Loki est disponible sous forme de paquet Helm afin de simplifier son déploiement.

Installation de Helm

Pour la suite, l’utilisateur devra disposer de la commande helm. Cette dernière se récupère sur le dépôt GitHub du projet. Charge à l’utilisateur de décompresser l’archive correspondant à l’architecture du poste de l’utilisateur et de placer la commande helm dans $PATH.

N. B. : La version 3.0.0 de Helm vient juste de sortir. Étant donné qu’elle change beaucoup de choses, il est conseillé au lecteur d’attendre un peu avant de s’y mettre.

Ajout de la source Helm

La première étape va consister à ajouter le dépôt « loki » à l’aide de la commande suivante :

helm repo add loki https://grafana.github.io/loki/charts

Une fois cette commande lancée, il devient possible de chercher les paquets portant le nom « loki » :

helm search loki

Ci‑dessous un exemple de résultat renvoyé :

loki/loki          0.17.2          v0.4.0          Loki: like Prometheus, but for logs.                        
loki/loki-stack    0.19.1          v0.4.0          Loki: like Prometheus, but for logs.                        
loki/fluent-bit    0.0.2           v0.0.1          Uses fluent-bit Loki go plugin for gathering logs and sen...
loki/promtail      0.13.1          v0.4.0          Responsible for gathering logs and sending them to Loki

Ces paquets ont différentes fonctions :

• le paquet loki/loki correspond au serveur Loki seul ;
• le paquet loki/fluent-bit permet de déployer un DaemonSet s’appuyant sur fluent‑bin pour centraliser les journaux à la place de Promtail ;
• le paquet loki/promtail contenant l’agent de centralisation des journaux d’activités ;
• le paquet loki/loki-stack permettant de déployer Loki et Promtail en une seule fois.

Déploiement de Loki

Afin de déployer Loki dans Kubernetes, dans l’espace de noms « monitoring », lancez la commande suivante :

helm upgrade --install loki loki/loki-stack --namespace monitoring

Pour disposer d’un espace disque persistant, ajoutez l’option --set loki.persistence.enabled=true :

helm upgrade --install loki loki/loki-stack --namespace monitoring --set loki.persistence.enabled=true

Remarque : dans le cas où vous souhaiteriez déployer Grafana en même temps, ajouter l’option --set grafana.enabled=true.

Au lancement de cette commande, l’utilisateur devrait obtenir la sortie suivante :

LAST DEPLOYED: Tue Nov 19 15:56:54 2019
NAMESPACE: monitoring
STATUS: DEPLOYED

RESOURCES:
==> v1/ClusterRole
NAME                       AGE
loki-promtail-clusterrole  189d

...

NOTES:
The Loki stack has been deployed to your cluster. Loki can now be added as a datasource in Grafana.

See http://docs.grafana.org/features/datasources/loki/ for more detail.

Un coup d’œil sur l’état des pods de l’espace de noms « monitoring » achèvera de nous indiquer que tout est déployé :

kubectl -n monitoring get pods -l release=loki

Ci‑dessous un exemple de résultat renvoyé :

NAME                  READY   STATUS    RESTARTS   AGE
loki-0                1/1     Running   0          147m
loki-promtail-9zjvc   1/1     Running   0          3h25m
loki-promtail-f6brf   1/1     Running   0          11h
loki-promtail-hdcj7   1/1     Running   0          3h23m
loki-promtail-jbqhc   1/1     Running   0          11h
loki-promtail-mj642   1/1     Running   0          62m
loki-promtail-nm64g   1/1     Running   0          24m

Tous les pods sont démarrés. Il est maintenant temps de faire quelques tests !

Connexion à Grafana

Sous Kubernetes, afin de pouvoir se connecter à Grafana, il est nécessaire d’ouvrir un tunnel vers son pod. Ci‑dessous la commande permettant d’ouvrir le port 3 000 vers le pod de Grafana :

kubectl -n monitoring port-forward svc/loki-grafana 3000:80

Autre point important, la nécessité de récupérer le mot de passe de l’administrateur de Grafana. Ce dernier est stocké dans le secret loki-grafana dans le champ .data.admin-user au format base64.

Afin de le récupérer, lancez la commande suivante :

kubectl -n monitoring get secret loki-grafana --template '{{index .data "admin-password"|base64decode}}' ; echo

Utilisez ce mot de passe conjointement avec le compte d’administration par défaut (admin).

Définition de la source de données Loki depuis Grafana

Première chose à faire, s’assurer que la source de données (datasource) de Loki est bien présente (se rendre à l’emplacement suivant : Configuration / Datasource).

Voici un exemple de définition valide :

Un clic sur le bouton Test permettra de s’assurer que la communication avec Loki se passe bien.

Interrogation du moteur Loki

Rendez‑vous maintenant dans le champ « Explorer » de Grafana. Au moment de l’ingestion des journaux des conteneurs, Loki se charge d’ajouter les annotations en provenance de Kubernetes. Il devient ainsi possible de s’en servir pour récupérer les journaux d’un conteneur spécifique.

Ainsi, pour sélectionner les journaux des conteneurs promtail, la requête à rentrer sera la suivante : {container_name="promtail"}. Pensez également à bien sélectionner la source de données de Loki.

Cette requête renverra alors l’activité de ces conteneurs sous la forme suivante :

Inclusion dans un tableau de bord

Depuis la version 6.4 de Grafana, il est possible d’inclure un extrait des journaux dans un tableau de bord Grafana. L’utilisateur peut alors rapidement mettre en parallèle les courbes de fréquentation de son site avec les traces renvoyées par son application.

Ci‑dessous un exemple de tableau de bord réalisant ce mélange :

Futur de Loki

Lorsque j’ai commencé à écrire cet article en août, la version 0.3 de Loki venait à peine de sortir. La sortie de la version 1.0 est en quelque sorte la raison qui m’a poussé à finir mon travail. :)

J’ai commencé à l’utiliser à partir de la version 0.1 et il faut bien avouer qu’à l’époque la stabilité n’était pas encore au rendez‑vous. Globalement, la version 0.3 a apporté de vrais signes de maturité et les versions suivantes (0.4, puis 1.0) n’ont fait que conforter cette impression.

Dorénavant, avec la version 1.0.0, plus personne ne devrait avoir d’excuse pour ne pas utiliser cet excellent outil.

Les travaux les plus intéressants ne devraient plus avoir lieu sur Loki mais plus sur l’intégration avec l’excellent Grafana. En effet, la version 6.4 de Grafana a apporté une bonne intégration avec les tableaux de bord.

La version 6.5 qui vient juste de sortir améliore encore cette intégration en permettant de convertir automatiquement le contenu de la ligne de journal lorsqu’elle est au format JSON.

Ci‑dessous une petite vidéo présentant ce mécanisme :

Il devient aussi possible d’utiliser un des champs de la structure JSON pour par exemple :

• pointer vers un outil externe ;
• filtrer le contenu des journaux.

On peut alors cliquer sur le champ traceId afin de pointer vers un tableau de bord de Zipkin ou Jaeger.

Aller plus loin

• Découverte de l’outil de supervision Prometheus (392 clics)
• Loki: Prometheus‐inspired logging for cloud natives (181 clics)
• Loki: Prometheus‐inspired, open source logging for cloud natives (136 clics)
• FOSDEM 2019 — Loki: Prometheus for logs (106 clics)