Loki, centralisation de logs à la sauce Prometheus

Posté par (page perso) . Édité par ZeroHeure, BAud, palm123, Davy Defaud, Nils Ratusznik, tisaac, Ysabeau et Benoît Sibaud. Modéré par Xavier Claude. Licence CC by-sa.
27
30
nov.
2019
Supervision

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

Logo de Loki
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

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!

Méthode de résolution d’incidents

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 :

Architecture de LokiUn 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 :

Exemple de définition de la source de données vers Loki

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

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

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

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

  • # on s'y perd

    Posté par . Évalué à 9 (+8/-0).

    Elastic, prometheus, grafana kibana
    J'ai du mal à vraiment tout différencier, si quelqu'un pouvait m'aider

    Et loki, c'est pas le même nom que le defunt éditeur de jeu (nottamment de railroad tycoon 2) sous linux ?

    https://fr.wikipedia.org/wiki/Loki_Entertainment_Software

    • [^] # Re: on s'y perd

      Posté par (page perso) . Évalué à 10 (+8/-0). Dernière modification le 01/12/19 à 10:49.

      Elastic c'est une pile de divers logiciels, donc Elasticsearch (moteur de recherche), Kibana (visualisation de données), Logstash (analyse de logs) - ces trois là formant la pile ELK -, mais aussi Beats (remontée de métriques variées), et d'autres. Le tout est géré par la société Elastic, sous double licence libre+propriétaire.
      Prometheus collecte des métriques (transmises par des PrometheusExporters) et alerte dessus (composant AlertManager), site, licence Apache 2, fait partie de la Cloud Native Computing Foundation.
      Grafana est une autre solution de visualisation de données, société Grafana Labs
      Loki est notamment un dieu de la mythologie nordique, popularisé notamment par les comics Marvel, dont le nom a été réutilisé de nombreuses fois pour des choses très différentes. Rien que pour le domaine informatique c'est une bibliothèque C++, un ordinateur inabouti Sinclair Research et une société de port de jeux Windows sous GNU/Linux.

      Pour le reste, les habituels « ouais mais c'est qui le plus fort ? » :
      - Prometheus vs ElasticSearch. Which is better for container and server monitoring?
      - Elasticsearch vs Prometheus
      - Kibana vs Grafana vs Prometheus vs LogDNA
      - Prometheus vs Graphite/InfluxDD/OpenTSDB/Nagios/Sensu
      - Grafana vs Kibana vs Prometheus
      - Logstash vs Prometheus

      • [^] # Re: on s'y perd

        Posté par (page perso) . Évalué à 5 (+2/-0).

        Après, il y a aussi la comparaison entre ce qu'il est possible de faire avec du libre. Elastic a une partie des fonctionnalités en libre, certaines en proprio gratuit et d'autres qui nécessite un payement. Prometheus peut avoir un stockage en cluster redondant via influx DB qui demande la version propriétaire payante.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: on s'y perd

          Posté par (page perso) . Évalué à 1 (+0/-0).

          Pour préciser, la partie authentification qui était payante est devenue opensource il y a quelques temps (https://www.elastic.co/fr/what-is/open-x-pack). Après, pour être honnête, je ne me suis pas plus renseigné que ça sur les implications.

          A noter qu'il est également possible de protéger les accès à un cluster Elasticsearch sans utiliser X-pack en intercalant un reverse proxy (nginx, apache etc.) qui se chargera de la partie authentification + sécurisation SSL.

          • [^] # Re: on s'y perd

            Posté par (page perso) . Évalué à 4 (+1/-0).

            Après, pour être honnête, je ne me suis pas plus renseigné que ça sur les implications.

            Alors, "opensource" dans le sens, on peut voir le code, mais la licence n'est pas libre.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: on s'y perd

        Posté par (page perso) . Évalué à 5 (+3/-0).

        Pour compléter : une supervision est souvent constituée de trois types d'indicateurs : les métriques (valeurs numériques quelconques qui varient avec le temps, pour faire de jolies courbes), les checks (on/off, OK/KO, etc.) qui disent uniquement si c'est bon ou pas et les logs. Pour chacun de ces types d'indicateur, il faut au moins savoir les collecter, les stocker et les présenter à l'utilisateur (tu peux ajouter de la mise en forme, générer des alertes, et plein d'autres choses).

        Pour les logs, la chaîne est souvent constituée de syslog qui envoie à logstash (pour mise en forme) qui les stocke dans ElasticSearch. Kibana est une interface de visualisation et de recherche d'ElasticSearch.
        Dans le même genre et toujours pour les logs, il y a Graylog qui peut remplacer (en moins puissant mais plus simple) Logstash et Kibana.

        Prometheus (je connais mal) fait la collecte des métriques et des checks et de la visualisation simple.
        Grafana est à la base une visualisation de métriques qui demande un stockage (comme influxdb, mais il sait en utiliser d'autres). On parle ici du plugin Loki pour reprendre Grafana pour la visualisation des logs en plus des métriques (sachant qu'un plugin permet également d'utiliser Grafana pour la visualisation de checks).

      • [^] # Re: on s'y perd

        Posté par . Évalué à 1 (+0/-0). Dernière modification le 01/12/19 à 15:42.

        Logstash est un adaptateur principalement pour les logs, un équivalent log de Telegraf. En entrée, ça prend plein de formats différents de logs, que ça permet ensuite de parser, reformater et d'enrichir suivant des règles sur mesure. En sortie, on peut les balancer vers ce qu'on veut, entre autres une base Elastic Search, un syslog, une base Postgresql.
        A noter qu'il semble qu'ils ont pas mal ajouté de trucs pour la métrologie, même si j'ai tendance à être sceptique là dessus vu que c'était vraiment orienté logs à l'origine.

      • [^] # Re: on s'y perd

        Posté par (page perso) . Évalué à 1 (+1/-2).

        Elastic c’est aussi une compagnie qui utilise des méthodes mafieuses pour faire fermer les dépôts d’un concurrent et faire peur à ceux qui utilisent leurs outils.

    • [^] # Re: on s'y perd

      Posté par (page perso) . Évalué à 4 (+3/-0).

      Bonjour,

      Effectivement, y'a pas mal de changements en ce moment 😃

      Elasticsearch historiquement est là pour offrir un mécanisme de stockage de document non structuré. Très tôt dans son histoire il a été utilisé pour centraliser des logs de serveurs notamment avec logstash. Globalement, il s'agit d'un produit bénéficiant de nombreuses qualités. En revanche sa mise en œuvre réclame un certain savoir faire qui peut représenter un frein à son utilisation.

      Elasticsearch peut éventuellement être étendu avec la suite Beats pour avoir de l'acquisition de données sur la consommation cpu ou mémoire.

      Ces données peuvent ensuite être interrogé à l'aide de kibana ou grafana.

      Prometheus quant à lui est un outils de surveillance basé sur l'acquisition de métriques (nombre de visites, consommation cpu, mémoire, etc.). C'est un outil très à la mode dans le monde du container et qui offre des très grandes capacités d'acquisition et d'adaptation. Son point fort étant sa légèreté et sa maintenance simple. Il remplace en quelque sorte la partie Beats d'elasticsearch à un moindre coût.

      Loki - outre qu'il s'agissait d'une ancienne société spécialisée dans le portage de jeux vidéos sous Linux - est un produit qui est pensé pour centraliser des journaux d'activités avec un coût le plus faible possible. En quelque sorte, son but est de s'inspirer de ce qui a fait le succès de Prometheus et de l'appliquer aux logs.

  • # Grafana et Elastic

    Posté par (page perso) . Évalué à 3 (+0/-0).

    Tu dis que l'intérêt de Loki par rapport à Elastic, c'est de pouvoir tout faire depuis Grafana, mais il me semblait qu'il était possible de faire des requêtes sur Elastic depuis Grafana.

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Grafana et Elastic

      Posté par (page perso) . Évalué à 2 (+1/-0).

      Tout à fait. Après, je pense que si tu veux exploiter pleinement le potentiel d'Elasticsearch, Kibana reste tout de même plus indiqué.

      Après, c'est une question de goût et de couleur. Dans mon contexte, le couple Prometheus et Loki est plus adapté à ma manière de travailler.

      En effet, je ne peux pas consacrer le temps qu'il faudrait à faire fonctionner Elastic correctement (structure de l'index, volumétrie des journaux, suivi des consommations etc.).

      Mon guide principal se trouve dans Prometheus. Loki n'est là que pour confirmer un diagnostic. Dans ce cadre Elastic représentait trop de travail de maintenance.

      Mais si tu disposes d'un cluster bien configuré par quelqu'un qui s'y connait, il faut évidemment s'en servir.

  • # Logs?

    Posté par (page perso) . Évalué à 3 (+0/-0).

    Pourquoi ne pas envoyer directement les logs sur [insérer ici votre base préférée] dans son format natif ? Par exemple tout balancer en json sur un ES.

    Incubez l'excellence sur https://linuxfr.org/board/

    • [^] # Re: Logs?

      Posté par (page perso) . Évalué à 3 (+1/-0).

      1) Les logs sont rarement en JSON de base, il faut donc un outil pour les mettre en forme (logstash, graylog, …) — et même s'ils étaient en JSON, ça ne voudrait pas dire qu'ils aient tous le même format.
      2) quand on a un ES bien rempli, il faut dans tous les cas avoir une interface d'exploitation (Kibana, ou ici Grafana)
      3) si j'ai bien compris, Loki permet d'avoir les logs correspondant à des métriques directement, au lieu d'avoir à faire la corrélation temporelle manuellement.

      Bref, quelle que soit la base préférée, les outils de transformation et de visualisation restent nécessaire. Par contre, c'est intéressant d'avoir un seul outil de transformation, un seul outil de stockage et un seul outil de visualisation au lieu d'en avoir deux ou trois à chaque fois.

    • [^] # Re: Logs?

      Posté par (page perso) . Évalué à 1 (+0/-0).

      Les librairies de log (log4j ou équivalent) permettent de faire ce genre de chose. Par contre, l'envoi par le réseau de message peut logiquement aboutir à des pertes.

      Une solution pouvant consister à passer par un stockage temporaire sur disque avant d'envoyer. Du coup, on retombe un peu sur le problème initial : autant consommer le contenu de fichier avec un agent qui se chargera de centraliser tout ça.

      D'autre part côté du serveur, dans tous les cas, il faudra tout de même procéder à une lecture de l'entrée de log.

      Au final, dans Loki, ce dernier ne fait que réceptionner le message pour le stocker avec les labels qui lui sont associés. Aucune analyse n'est faîte sur le contenu ce qui réduit la consommation CPU/mémoire au moment du stockage.

      En revanche, la consultation ne pourra pas se faire au hasard et passera forcément par l'utilisation des labels.

    • [^] # Re: Logs?

      Posté par (page perso) . Évalué à 1 (+0/-0).

      Loki ne va pas parser tes logs à la Logstash/Fluentd/…; il prend tes logs bruts, mets les tags définis (ou extrait de Kubernetes) sur ces logs.

      Tu peux ensuite visualiser de manière centralisée sans prendre 3 semaines tes logs.

      En complément
      * Promtail de permettra d'envoyer tes fichiers de logs dans Loki
      * Le driver Docker log, te permettra d'envoyer tes logs directement dans Loki "nativement".

      A titre d'exemple pour configurer Prometheus/Grafana/Loki j'ai du passer 3 jours à tout casser (Dashboard compris), sur une petite infra d'une 30ene de serveur (Apache/CouchDB/PostgreSQL/Flask-et-son-endpoint-prometheus/Gitlab/vmware vcenter & ESXi/Equipement réseau en Snmp/…)

      Is it a Bird? Is it a Plane?? No, it's Super Poil !!!

      • [^] # Re: Logs?

        Posté par (page perso) . Évalué à 2 (+0/-0).

        Loki ne va pas parser tes logs à la Logstash/Fluentd/…;

        Tu peux utiliser fluentd/fluent-bit pour envoyer vers Loki, donc tu peux aussi parser les logs avant des les envoyer.

    • [^] # Re: Logs?

      Posté par . Évalué à 1 (+0/-0).

      C'est plus lent. Envoyer les logs directement sur le réseau impose à l'application d'avoir la responsabilité de la bonne réception des logs. L'utilisation d'un fichier de tampon permet de ne pas ralentir ton application à cause des logs voir de continuer à fonctionner même si la base est en vrac.

      Il est possible d'envoyer ses logs dans un broker de messages aussi.

    • [^] # Re: Logs?

      Posté par (page perso) . Évalué à 3 (+1/-0).

      Entre autre parce que tu veux découpler les responsabilités.
      Ton service est là pour réaliser des actions, et balance tout dans les sorties standard.
      Se connecter à des systèmes de logs n'est pas de sa responsabilité.
      Un autre service lui a pour responsabilité de prendre des logs et des les envoyer quelque part.
      Ce qui fait donc que ton premier service n'a pas à s'occuper de la dispo, réussite ou non de l'envoi, de gérer les timeouts, latences, etc. Il publie du log c'est tout. Et le jour où tu veux changer de système de log, ben c'est vachement plus simple aussi.

      Voir par exemple la section sur les logs des 12 factor: https://12factor.net/fr/logs

  • # Merci pour cette présentation

    Posté par (page perso) . Évalué à 3 (+1/-0). Dernière modification le 03/12/19 à 19:46.

    Tout est dans le titre : je vais me pencher sérieusement sur cette solution, dans l'optique de supprimer sensu/uchiwa/elasticsearch/graylog/rabbitmq par Prometheus et Grafana (couplé à quelques plugins dont Loki).
    Rien n'est fait pour l'instant, mais j'aimerais bien que ça soit faisable :)

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.