URL: https://linuxfr.org/news/loki-centralisation-de-logs-a-la-sauce-prometheus Title: Loki, centralisation de logs Ă  la sauce Prometheus Authors: yannig ZeroHeure, BAud, palm123, Davy Defaud, Nils Ratusznik, tisaac, Ysabeau đŸ§¶ et BenoĂźt Sibaud Date: 2019ćčŽ08月06æ—„T12:09:16+02:00 License: CC By-SA Tags: elasticsearch, supervision, kubernetes, loki, grafana et prometheus Score: 31 Cet article est une rapide introduction Ă  Loki. Ce projet est [soutenu par Grafana](https://grafana.com/oss/loki/) et a pour but de centraliser des journaux d’activitĂ©s (serveurs ou conteneurs). ![Logo de Loki](https://grafana.com/static/img/docs/logos/icon_loki.svg) 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. ---- [DĂ©couverte de l’outil de supervision Prometheus](https://linuxfr.org/news/decouverte-de-l-outil-de-supervision-prometheus) [Loki: Prometheus‐inspired logging for cloud natives](https://grafana.com/oss/loki) [Loki: Prometheus‐inspired, open source logging for cloud natives](https://grafana.com/blog/2018/12/12/loki-prometheus-inspired-open-source-logging-for-cloud-natives/) [FOSDEM 2019 — Loki: Prometheus for logs](https://archive.fosdem.org/2019/schedule/event/loki_prometheus_for_logs/) ---- 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](https://linuxfr.org/news/decouverte-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_](https://en.wikipedia.org/wiki/Time_series_database) 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!_ ![MĂ©thode de rĂ©solution d’incidents](https://grafana.com/static/assets/img/blog/image9.png) 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 : ```sh git clone https://github.com/grafana/loki.git ``` Reste ensuite Ă  se rendre dans le rĂ©pertoire production : ```sh cd production ``` De lĂ , il est possible de rĂ©cupĂ©rer la derniĂšre version des images Docker : ```sh docker-compose pull ``` Enfin, la pile de Loki se lance Ă  l’aide de la commande suivante : ```sh 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 : ![Architecture de Loki](https://grafana.com/static/assets/img/blog/image1.png) _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 : ```sh 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](https://github.com/helm/helm/releases/tag/v2.16.1) 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 : ![Exemple de dĂ©finition de la source de donnĂ©es vers Loki](https://1.bp.blogspot.com/-fhWhxBbgEhQ/Xd1EWPqHTGI/AAAAAAAAQfo/sYfgNOMAd3wzdY1BQN5YZlLArzCnjIGyQCLcBGAsYHQ/s1410/datasource-loki.png) 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 : ![RĂ©sultat requĂȘte dans Grafana](https://1.bp.blogspot.com/-WY2ACR_ok7Y/Xd13EABDlvI/AAAAAAAAQf0/abjmBFPtl882T5GHvEVdQQ9UbAYU_0FsgCLcBGAsYHQ/s1600/requ%25C3%25AAte-loki-grafana.png) 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 : ![Exemple de tableau de bord avec des mĂ©triques Prometheus et des journaux en provenance de Loki](https://1.bp.blogspot.com/-eb5_K1m4Wo8/Xd2C0IPpy9I/AAAAAAAAQgA/2caijspE510VyAVvnvGKbs55OhdWwdaYQCLcBGAsYHQ/s1600/dashboard-grafana-prometheus-loki.png) 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 : ![Utilisation du nouvel affichage des lignes de Loki dans Grafana](https://grafana.com/docs/img/docs/v65/explore_log_details.gif) 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.

AltStyle ă«ă‚ˆăŁăŠć€‰æ›ă•ă‚ŒăŸăƒšăƒŒă‚ž (->ă‚ȘăƒȘă‚žăƒŠăƒ«) /