Loki — collecte de logs utilisant l'approche Prometheus

Salut, chers Hubrovians ! À l'approche du nouveau cycle de cours, « Pratiques et outils DevOps » nous avons préparé pour vous la traduction d'un matériel intéressant.

Cet article est une brève introduction à Loki. Le projet Loki est soutenu par Grafana et vise à centraliser la collecte de logs (depuis des serveurs ou des conteneurs).

La principale source d'inspiration pour Loki était Prometheus l'idée d'appliquer ses approches à la gestion des logs :

• utiliser des étiquettes (labels) pour stocker des données,
• consommer peu de ressources.

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

Quelques mots sur Prometheus.

Pour comprendre pleinement comment fonctionne Loki, il est important de faire un pas en arrière et de se souvenir un peu de Prometheus.

Une des caractéristiques distinctives de Prometheus est l'extraction des métriques à partir des points de collecte (via les exportateurs) et leur stockage dans TSDB (Time Series Data Base, base de données des séries temporelles) avec ajout de métadonnées sous forme d'étiquettes.

Pourquoi est-ce nécessaire

Dernièrement, Prometheus est devenu le standard de facto dans le monde des conteneurs et de Kubernetes : son installation est très simple, et un point d'extrémité pour Prometheus est présent par défaut dans un cluster Kubernetes. Prometheus peut également extraire des métriques à partir d'applications déployées dans des conteneurs, tout en préservant certaines étiquettes. Par conséquent, le suivi des applications est 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 pour vous :

• un service cloud géré pour la centralisation des logs (AWS, Azure ou Google),
• un service de surveillance « monitoring as a service » (par exemple, Datadog),
• ou créer votre propre service de collecte des logs.

Pour la troisième option, j'ai traditionnellement utilisé Elasticsearch, bien que je ne l'aie pas toujours apprécié (surtout en raison de son poids et de la complexité de sa configuration).

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

• être simple à démarrer,
• consommer peu de ressources,
• fonctionner de manière autonome sans aucun entretien spécial,
• servir de complément à Prometheus pour aider à l'investigation des bugs.

Cependant, cette simplicité se fait au prix de certains compromis. L'un d'eux est de ne pas indexer le contenu. Ainsi, la recherche textuelle n'est pas très efficace ou riche, et ne permet pas de tenir des statistiques sur le contenu textuel. Mais comme Loki souhaite être l'équivalent de grep et un complément à Prometheus, ce n'est pas un inconvénient.

Enquête sur les incidents

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 adhoc → 4 Agrégation des journaux → 5 Traçage distribué → 6 Correction !
(1 Alerte → 2 Tableau de bord → 3 Requête adhoc → 4 Agrégation des journaux → 5 Traçage distribué → 6 Correction !)

L'idée est que nous recevons une alerte (notification Slack, SMS, etc.) et ensuite :

• nous regardons les tableaux de bord Grafana
• nous consultons les métriques des services (par exemple, dans Prometheus)
• nous vérifions les enregistrements des journaux (par exemple, dans Elasticsearch)
• nous jetons peut-être un œil aux tracés distribués (Jaeger, Zipkin, etc.)
• et enfin, nous corrigeons le problème initial.

Ici, dans le cas de la pile Grafana + Prometheus + Elasticsearch + Zipkin, il faudra utiliser quatre outils différents. Pour gagner du temps, il serait intéressant de pouvoir effectuer toutes ces étapes avec un seul outil : Grafana. Il convient de noter que cette approche d'enquête est mise en œuvre dans Grafana à partir de la version 6. Ainsi, il devient possible d'accéder aux données de Prometheus directement depuis Grafana.

L'écran Explorer est divisé entre Prometheus et Loki

Sur cet écran, il est possible de consulter les journaux dans Loki liés aux métriques de Prometheus en utilisant le concept de partage d'écran. À partir de la version 6.5, Grafana permet de traiter l'identifiant de trace (trace id) dans les enregistrements des journaux Loki pour passer des liens à vos outils de traçage distribué préférés (Jaeger).

Test local de Loki

Le moyen le plus simple de tester Loki localement est d'utiliser docker-compose. Le fichier docker-compose se trouve dans le dépôt de Loki. Vous pouvez obtenir le dépôt avec 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 pile Loki se lance avec la commande suivante :

$ docker-compose up

Architecture de Loki

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

Principes de l'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 agrège tout cela et le transmet à Grafana.
Loki est en cours d'exécution. Pour voir les composants existants, exécutez la commande suivante :

$ docker ps

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

IMAGE               PORTS                  NOMS
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 responsable de la centralisation des journaux
• Grafana : outil réputé pour les tableaux de bord
• Loki : démon de centralisation des données

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

Déploiement dans Kubernetes

L'installation des composants Loki dans Kubernetes consistera en ce qui suit :

• daemonSet pour déployer l'agent Promtail sur chacune des machines du cluster de serveurs
• déploiement (Deployment) de Loki
• et enfin — déploiement de Grafana.

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

Installation via Helm

Helm doit déjà être installé. Il peut être téléchargé depuis le dépôt GitHub du projet. Il s'installe par décompression de l'archive correspondant à votre architecture, et en ajoutant helm à $PATH.

Remarque : la version 3.0.0 de Helm a été récemment publiée. Comme il y a eu beaucoup de changements, il est recommandé aux lecteurs d'attendre un peu avant de commencer à l'utiliser..

Ajout d'une source pour Helm

La première étape consiste à ajouter le dépôt 'loki' à l'aide de la commande suivante :

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

Après cela, vous pouvez rechercher des packages portant le nom 'loki' :

$ helm search loki

Résultat :

loki/loki       0.17.2 v0.4.0 Loki : comme Prometheus, mais pour les journaux.
loki/loki-stack 0.19.1 v0.4.0 Loki : comme Prometheus, mais pour les journaux.
loki/fluent-bit 0.0.2  v0.0.1 Utilise le plugin Loki go de fluent-bit pour...
loki/promtail   0.13.1 v0.4.0 Responsable de la collecte des journaux et...

Ces packages ont les fonctions suivantes :

• via le gestionnaire de packages standard de leur distribution. Sur Arch Linux, loki/loki correspond uniquement au serveur Loki
• via le gestionnaire de packages standard de leur distribution. Sur Arch Linux, loki/fluent-bit vous permet de déployer DaemonSet en utilisant fluent-bit pour la collecte des journaux au lieu de Promtail
• via le gestionnaire de packages standard de leur distribution. Sur Arch Linux, loki/promtail contient l'agent de collecte des fichiers journaux
• via le gestionnaire de packages standard de leur distribution. Sur Arch Linux, loki/loki-stack, permet de déployer Loki en même temps que Promtail.

Installation de Loki

Pour déployer Loki dans Kubernetes, exécutez la commande suivante dans l'espace de noms 'monitoring' :

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

Pour sauvegarder 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

Remarque : Si vous souhaitez déployer Grafana simultanément, ajoutez le paramètre --set grafana.enabled = true

Lorsque vous exécutez cette commande, vous devriez obtenir la sortie suivante :

DERNIÈRE DÉPLOIEMENT : Mar Nov 19 15:56:54 2019
NAMESPACE : monitoring
ÉTAT : DÉPLOYÉ
RESSOURCES :
==> v1/ClusterRole
NOM ÂGE
loki-promtail-clusterrole 189j
…
REMARQUES :
La pile Loki a été déployée dans votre cluster. Loki peut maintenant être ajouté en tant que source de données dans Grafana.
Voir <a href="http://docs.grafana.org/features/datasources/loki/">http://docs.grafana.org/features/datasources/loki/</a> pour plus de détails.

En regardant l'état des pods dans l'espace de noms « monitoring », nous verrons que tout est déployé :

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

Résultat :

NOM                 PRÊT  ÉTAT      RESTARTS  ÂGE
loki-0               1/1    En cours d'exécution  0         147m
loki-promtail-9zjvc  1/1    En cours d'exécution  0         3h25m
loki-promtail-f6brf  1/1    En cours d'exécution  0         11h
loki-promtail-hdcj7  1/1    En cours d'exécution  0         3h23m
loki-promtail-jbqhc  1/1    En cours d'exécution  0         11h
loki-promtail-mj642  1/1    En cours d'exécution  0         62m
loki-promtail-nm64g  1/1    En cours d'exécution  0         24m

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

Connexion à Grafana

Pour se connecter à Grafana sous Kubernetes, il est nécessaire d'ouvrir un tunnel vers son pod. Voici 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 de Grafana. Le mot de passe est stocké dans le secret loki-grafana dans le champ .data.admin-user au format base64.

Pour le récupérer, 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éfinition de la source de données Loki dans Grafana

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

Exemple de configuration de la source de données pour Loki

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

Effectuer des requêtes à Loki

Accédez maintenant à 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 journaux 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"}.
N'oubliez pas également de choisir la source de données Loki.

Cette requête retournera l'activité des conteneurs sous la forme suivante :

Résultat de la requête dans Grafana

Ajout au tableau de bord

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

Voici un exemple de tableau de bord implémentant cette interaction :

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

L'avenir de Loki

J'ai commencé à utiliser Loki en mai/juin avec la version 0.1. Aujourd'hui, la version 1 est déjà sortie, et même les versions 1.1 et 1.2.

Il faut reconnaître que la version 0.1 n'était pas suffisamment stable. Mais la 0.3 a déjà montré 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 1.0.0, personne ne peut plus avoir d'excuses pour ne pas utiliser cet excellent outil.

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

Grafana 6.5, qui a été récemment publiée, améliore encore cette intégration, en reconnaissant automatiquement le contenu des journaux au format JSON.

Dans la vidéo ci-dessous, un petit exemple de ce mécanisme est présenté :

Utilisation des chaînes Loki affichées dans Grafana

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

• lien vers un outil externe
• filtration du contenu des journaux

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

Traditionnellement, nous attendons vos commentaires et vous invitons à un webinaire ouvert, où nous discuterons de l'évolution de l'industrie DevOps en 2019 et aborderons les chemins possibles pour 2020.

Source : habr.com