Loki - collecte de journaux utilisant l'approche Prometheus

Salut, habitants de Khabrovsk ! A la veille du début d'une nouvelle inscription au cours "Pratiques et outils DevOps" Nous avons préparé pour vous une traduction de documents intéressants.

Cet article est une brève introduction à Loki. Projet Loki soutenu par Grafana et vise la collecte centralisée des journaux (à partir de serveurs ou de conteneurs).

La principale inspiration de Loki était Prométhée avec l'idée d'appliquer ses approches à la gestion des logs :

• utiliser des étiquettes pour stocker des données
• consommation de peu de ressources

Nous reviendrons sur le fonctionnement de Prometheus et donnerons quelques exemples de son utilisation dans le cadre de Kubernetes.

Quelques mots sur Prométhée

Pour bien comprendre le fonctionnement de Loki, il est important de prendre du recul et de se souvenir un peu de Prométhée.

L'une des particularités de Prometheus est l'extraction de métriques à partir des points de collecte (via des exportateurs) et leur stockage dans TSDB (Time Series Data Base), avec l'ajout de métadonnées sous forme d'étiquettes.

Pourquoi cela est nécessaire

Récemment, Prometheus est devenu le standard de facto dans le monde des conteneurs et de Kubernetes : son installation est très simple, et le cluster Kubernetes est livré avec un point de terminaison natif pour Prometheus. Prometheus peut également extraire des métriques d'applications déployées dans un conteneur tout en stockant des étiquettes spécifiques. La surveillance des applications est donc très simple à mettre en œuvre.

Malheureusement, il n’existe toujours pas de solution clé en main pour la gestion des logs, et vous devez trouver une solution par vous-même :

• service cloud géré pour centraliser les logs (AWS, Azure ou Google)
• service de surveillance « surveillance en tant que service » (par exemple, Datadog)
• créer votre propre service de collecte de journaux.

Pour la troisième option, j'utilisais traditionnellement Elasticsearch, même si je n'en étais pas toujours satisfait (notamment sa lourdeur et sa complexité de configuration).

Loki a été conçu pour simplifier la mise en œuvre selon les principes suivants :

• être simple pour commencer
• consomme peu de ressources
• travailler de manière autonome sans entretien particulier
• servir de complément à Prometheus pour faciliter les enquêtes sur les bogues

Toutefois, cette simplicité se fait au prix de certains compromis. L'un d'eux est de ne pas indexer le contenu. La recherche de texte n’est donc pas très efficace ni riche et ne permet pas de statistiques sur le contenu du texte. Mais puisque Loki veut être l’équivalent de grep et un complément de Prométhée, ce n’est pas un inconvénient.

Enquête d'incident

Pour mieux comprendre pourquoi Loki n'a pas besoin d'indexation, revenons à la méthode d'enquête sur les incidents utilisée par les développeurs de Loki :

1 Alerte → 2 Tableau de bord → 3 Requête ad hoc → 4 Agrégation de journaux → 5 Traçage distribué → 6 Correctif !
(1 Avertissement → 2 Tableau de bord → 3 Requête ad hoc → 4 Agrégation de journaux → 5 Traçage distribué → 6 Correction !)

L'idée est que nous recevons une sorte d'alerte (notification Slack, SMS, etc.) et après cela :

• regardez les tableaux de bord Grafana
• regardez les métriques de service (par exemple, dans Prometheus)
• regardez les entrées du journal (par exemple, dans Elasticsearch)
• jetez peut-être un œil aux traces distribuées (Jaeger, Zipkin, etc.)
• et enfin résoudre le problème d'origine.

Ici, dans le cas de la stack Grafana + Prometheus + Elasticsearch + Zipkin, vous devrez utiliser quatre outils différents. Pour gagner du temps, il serait bien de pouvoir réaliser toutes ces étapes à l'aide d'un seul outil : Grafana. Il est à noter que cette approche de recherche est implémentée dans Grafana depuis la version 6. Ainsi, il devient possible d'accéder aux données Prometheus directement depuis Grafana.

Écran de l'explorateur partagé entre Prométhée et Loki

À partir de cet écran, vous pouvez afficher les journaux Loki liés aux métriques Prometheus en utilisant le concept d'écran partagé. Depuis la version 6.5, Grafana vous permet d'analyser l'identifiant de trace dans les entrées du journal Loki pour suivre les liens vers vos outils de traçage distribués préférés (Jaeger).

Test Loki local

Le moyen le plus simple de tester Loki localement est d'utiliser docker-compose. Le fichier docker-compose se trouve dans le référentiel Loki. Vous pouvez obtenir le référentiel en utilisant la commande suivante git:

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

Ensuite, vous devez vous rendre dans le répertoire de production :

$ cd production

Après cela, vous pouvez obtenir la dernière version des images Docker :

$ docker-compose pull

Enfin, la stack Loki se lance avec la commande suivante :

$ docker-compose up

L'architecture de Loki

Voici un petit schéma avec l'architecture Loki :

Principes d'architecture de Loki

Le client Web exécute des applications sur le serveur, Promtail collecte les journaux et les envoie à Loki, le client Web envoie également des métadonnées à Loki. Loki regroupe tout et le transmet à Grafana.
Loki est lancé. Pour afficher les composants disponibles, exécutez la commande suivante :

$ docker ps

Dans le cas d'un Docker fraîchement installé, la commande doit renvoyer le résultat suivant :

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... production_loki_1

Nous voyons les composants suivants :

• Promtail : agent chargé de centraliser les logs
• Grafana : un célèbre outil de tableau de bord
• Loki : Démon de centralisation des données

Dans le cadre d'une infrastructure classique (basée par exemple sur des machines virtuelles), l'agent Promtail doit être déployé sur chaque machine. Grafana et Loki peuvent être installés sur la même machine.

Déploiement sur Kubernetes

L'installation des composants Loki sur Kubernetes sera la suivante :

• daemonSet pour déployer l'agent Promtail sur chacune des machines du cluster de serveurs
• Déploiement Loki
• et le dernier est le déploiement de Grafana.

Heureusement, Loki est disponible sous forme de package Helm, ce qui facilite son déploiement.

Installation via Heml

Heml devrait déjà être installé. Il peut être téléchargé depuis le référentiel GitHub du projet. Il s'installe en décompressant l'archive correspondant à votre architecture et en ajoutant helm à $PATH.

Note: la version 3.0.0 de Helm a été publiée récemment. Étant donné les nombreuses modifications apportées, il est conseillé au lecteur d'attendre un peu avant de l'utiliser..

Ajout d'une source pour Helm

La première étape consiste à ajouter le référentiel « loki » à l'aide de la commande suivante :

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

Après cela, vous pouvez rechercher des packages nommés « loki » :

$ helm search loki

Résultat:

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...
loki/promtail   0.13.1 v0.4.0 Responsible for gathering logs and...

Ces packages ont les fonctionnalités suivantes :

• paquet loki/loki correspond uniquement au serveur Loki
• paquet loki/bit courant vous permet de déployer un DaemonSet en utilisant fluent-bin pour collecter les journaux au lieu de Promtail
• paquet loki/promtail contient un agent de collecte de fichiers journaux
• paquet loki/loki-pile, vous permet de déployer immédiatement Loki avec Promtail.

Installer Loki

Pour déployer Loki sur Kubernetes, exécutez la commande suivante dans l'espace de noms « surveillance » :

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

Pour enregistrer sur le disque, ajoutez le paramètre --set loki.persistence.enabled = true:

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

Note: si vous souhaitez déployer Grafana en même temps, alors ajoutez le paramètre --set grafana.enabled = true

Lorsque vous exécutez cette commande, vous devriez obtenir le résultat suivant :

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 <a href="http://docs.grafana.org/features/datasources/loki/">http://docs.grafana.org/features/datasources/loki/</a> for more details.

En regardant l’état des pods dans l’espace de noms « monitoring », on constate que tout est déployé :

$ kubectl -n monitoring get pods -l release=loki

Résultat:

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 fonctionnent. Il est maintenant temps de faire quelques tests !

Connexion à Grafana

Pour vous connecter à Grafana sous Kubernetes, vous devez ouvrir un tunnel vers son pod. Ci-dessous la commande pour ouvrir le port 3000 pour le pod Grafana :

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

Un autre point important est la nécessité de récupérer le mot de passe administrateur Grafana. Le mot de passe est gardé secret loki-grafana dans le champ .data.admin-user au format base64.

Pour le restaurer, vous devez exécuter la commande suivante :

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

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

Définir une source de données Loki dans Grafana

Tout d'abord, assurez-vous que la source de données Loki a été créée (Configuration/Datasource).
Voici un exemple:

Exemple de mise en place d'une source de données pour Loki

En cliquant sur « Test » vous pouvez vérifier la connexion avec Loki.

Faire des demandes à Loki

Allez maintenant sur Grafana dans la section « Explorer ». Lors de la réception des journaux des conteneurs, Loki ajoute des métadonnées de Kubernetes. Ainsi, il devient possible de visualiser les logs d'un conteneur spécifique.

Par exemple, pour sélectionner les journaux du conteneur Promtail, vous pouvez utiliser la requête suivante : {container_name = "promtail"}.
Ici également, n'oubliez pas de sélectionner la source de données Loki.

Cette requête renverra l'activité du conteneur comme suit :

Résultat de la requête dans Grafana

Ajouter au tableau de bord

À partir de Grafana 6.4, vous pouvez placer les informations du journal directement sur le tableau de bord. Après cela, l'utilisateur pourra basculer rapidement entre le nombre de requêtes sur son site et les traces applicatives.

Vous trouverez ci-dessous un exemple de tableau de bord qui implémente cette interaction :

Exemple de tableau de bord avec les métriques Prometheus et les journaux Loki

L'avenir de Loki

J'ai commencé à utiliser Loki en mai/juin avec la version 0.1. Aujourd'hui, la version 1, voire 1.1 et 1.2, sont déjà sorties.

Il faut admettre que la version 0.1 n'était pas assez stable. Mais la 0.3 montrait déjà de réels signes de maturité, et les versions suivantes (0.4, puis 1.0) n'ont fait que renforcer cette impression.

Après la version 1.0.0, personne ne peut avoir d'excuse pour ne pas utiliser ce merveilleux outil.

Les améliorations supplémentaires ne devraient pas concerner Loki, mais plutôt son intégration avec l'excellent Grafana. En fait, Grafana 6.4 a déjà une bonne intégration avec les tableaux de bord.

Grafana 6.5, sorti récemment, améliore encore cette intégration en reconnaissant automatiquement le contenu des journaux au format JSON.

La vidéo ci-dessous montre un petit exemple de ce mécanisme :

Utilisation des chaînes Loki exposées dans Grafana

Il devient possible d'utiliser l'un des champs JSON, par exemple, pour :

• liens vers un outil externe
• filtrage du contenu du journal

Par exemple, vous pouvez cliquer sur traceId pour accéder à Zipkin ou Jaeger.

Comme d'habitude, nous attendons vos commentaires avec impatience et vous invitons à webinaire ouvert, où nous parlerons de la façon dont l'industrie DevOps s'est développée en 2019 et discuterons des voies de développement possibles pour 2020.

Source: habr.com