Loki

Fiche express
Type	Agrégation et indexation de logs « à la Prometheus » (labels, pas de texte intégral)
Éditeur	Grafana Labs
Licence	Open source (AGPLv3 à partir de la v2.x, à vérifier)
Langage de requête	LogQL
Agent de collecte	Promtail (agent historique) · Grafana Alloy (agent unifié plus récent, à vérifier selon la version)
Voir aussi	Grafana · Prometheus · Syslog · Rsyslog

Loki est un système d'agrégation de logs édité par Grafana Labs, conçu explicitement sur le modèle de Prometheus : plutôt que d'indexer le texte intégral de chaque ligne de log comme le fait une pile de type Elasticsearch, Loki n'indexe que les métadonnées — un petit ensemble de labels à faible cardinalité (par exemple job, namespace, host) — et stocke le contenu brut des lignes de log compressé, sans index inversé sur leur contenu.

Différence clé avec l'indexation full-text (Elasticsearch)

Une pile de journalisation classique de type ELK indexe chaque mot de chaque ligne de log dans un index inversé, ce qui permet des recherches libres très rapides sur le contenu, mais avec un coût de stockage et d'indexation proportionnel au volume de texte ingéré — souvent plusieurs fois la taille des données brutes. Loki fait un choix différent : l'index reste petit (labels uniquement), et une requête qui filtre sur le contenu (une expression régulière, par exemple) est exécutée à la lecture, en parcourant les blocs de logs compressés correspondant aux labels ciblés, plutôt qu'en interrogeant un index préconstruit sur le texte.

	Loki	Pile de type Elasticsearch/ELK
Ce qui est indexé	Labels (métadonnées) uniquement	Contenu texte intégral de chaque ligne
Coût de stockage	Faible (proche des données brutes compressées)	Élevé (index souvent plus volumineux que les données)
Recherche texte libre	Grep exécuté à la lecture, sur les blocs concernés	Immédiate via l'index inversé
Point fort typique	Corrélation avec des métriques Prometheus, coût réduit à grande échelle	Recherche ad hoc riche sur du texte non structuré

Ce compromis reflète un usage ciblé : Loki est pensé pour des logs déjà relativement structurés ou filtrables par un petit nombre de labels connus à l'avance (l'équivalent des labels Prometheus : service, environnement, instance...), avec la conviction que l'essentiel du tri se fait par ces métadonnées avant d'avoir besoin de fouiller le texte lui-même.

LogQL

LogQL est le langage de requête de Loki, délibérément proche de PromQL dans sa syntaxe et sa logique de sélection par labels :

# Sélection par labels : toutes les lignes du job "nginx" en environnement "prod"
{job="nginx", env="prod"}

# Filtrage texte sur la sélection ci-dessus (exécuté à la lecture)
{job="nginx", env="prod"} |= "500"

# Filtrage par expression régulière, en excluant un motif
{job="nginx"} |~ "error|fatal" != "healthcheck"

# Extraction de champs structurés à la volée (ex. logs JSON) puis filtre sur un champ extrait
{job="app"} | json | status_code >= 500

# Métrique dérivée du flux de logs : taux de lignes d'erreur par seconde
sum(rate({job="app"} |= "error" [5m]))

Cette dernière possibilité — dériver une métrique numérique (un taux, un compte) directement d'un flux de logs — est une spécificité notable de LogQL : elle permet de générer des alertes ou des graphiques à partir de logs sans avoir dû, en amont, exposer une métrique Prometheus dédiée pour le même événement.

Promtail (agent de collecte)

Promtail est l'agent chargé de découvrir les sources de logs, d'y attacher les labels appropriés, puis de pousser les lignes vers Loki. Son fonctionnement rappelle volontairement celui de Prometheus côté métriques :

• lecture de fichiers de logs sur disque (avec suivi de position, comme tail -f),

 du journal systemd, ou réception directe au format syslog ;

• découverte de service pour attacher automatiquement des labels pertinents — notamment

 kubernetes_sd_configs, qui reprend le même mécanisme que Prometheus pour étiqueter
 chaque ligne de log avec le pod, le namespace et les labels Kubernetes d'origine ;

• règles de relabeling similaires en syntaxe à celles utilisées côté scrape Prometheus.

server:
  http_listen_port: 9080

positions:
  filename: /var/lib/promtail/positions.yaml

clients:
  - url: http://loki:3100/loki/api/v1/push

scrape_configs:
  - job_name: syslog
    syslog:
      listen_address: 0.0.0.0:1514
      labels:
        job: syslog
    relabel_configs:
      - source_labels: ['__syslog_message_hostname']
        target_label: 'host'

  - job_name: journal
    journal:
      max_age: 12h
      labels:
        job: systemd-journal
    relabel_configs:
      - source_labels: ['__journal__systemd_unit']
        target_label: 'unit'

Un projet plus récent, Grafana Alloy, vise à unifier la collecte de métriques, logs et traces en un agent unique destiné à terme à remplacer Promtail et les agents Grafana antérieurs (à vérifier selon l'état d'avancement de cette convergence au moment de la lecture).

Intégration avec Grafana

Loki est développé par Grafana Labs et s'intègre nativement à Grafana comme source de données au même titre que Prometheus : l'écran Explore permet d'interroger un flux de logs en LogQL, de corréler dans un même tableau de bord une métrique Prometheus (par exemple un taux d'erreurs) et les lignes de logs correspondant à la même fenêtre de temps et aux mêmes labels, ce qui est l'un des principaux arguments d'adoption de la paire Loki/Prometheus derrière un même Grafana.

Positionnement face à une chaîne syslog classique

Loki n'est pas un remplacement direct du protocole Syslog ni de démons comme Rsyslog ou Syslog-ng : ceux-ci restent pertinents comme mécanisme de transport et de collecte première des messages (facility/sévérité, relais entre machines). Promtail sait d'ailleurs recevoir directement des messages au format syslog (voir l'exemple de configuration ci-dessus) et s'insérer en aval d'une chaîne syslog existante, plutôt que de s'y substituer. La différence se situe surtout en aval : là où une chaîne syslog classique est souvent couplée à un backend d'indexation full-text (à la Elasticsearch) pour la recherche, Loki propose un backend de stockage/requêtage alternatif, plus économique à grande échelle et pensé pour s'intégrer étroitement à un existant déjà construit autour de Prometheus et Grafana.

Voir aussi

• Grafana — frontal de visualisation natif, corrélation logs/métriques
• Prometheus — modèle d'indexation par labels et langage de requête dont LogQL s'inspire
• Syslog · Rsyslog · Syslog-ng — mécanismes de transport/collecte de logs en amont, complémentaires plutôt que concurrents