Logs centralisés — de la ligne au signal

Page concept

Cette page explique les grands principes de la centralisation des logs — de quoi parler avant d’écrire une requête LogQL. La mise en œuvre pas à pas est dans le TP3 — Loki Integration. Les ressources en fin de page sont votre point de départ pour aller plus loin par vous-même.

Le concept en une phrase

Centraliser les logs, c’est transformer des fichiers dispersés en une source unique interrogeable — dans TAAF, Alloy collecte, Loki stocke, LogQL interroge.

Chaque service, chaque machine, chaque pare-feu écrit ses propres lignes de log dans son coin. Prises séparément, elles ne racontent rien. Centralisées, elles deviennent une chronologie qu’on peut interroger : qui a fait quoi, quand, sur quelle machine — la question qu’on se pose systématiquement le jour d’un incident.

---

Les grands principes

1. Le pipeline — collecte, transport, stockage, requête

flowchart LR
    A[Fichiers de log\nsur chaque machine] -->|collecte| B[Alloy]
    B -->|transport| C[Loki]
    C -->|stockage| C
    C -->|requête LogQL| D[Grafana]

Quatre étapes distinctes, chacune avec son rôle :

• Collecte — un agent lit les logs à la source (fichier, journal système, sortie de conteneur). Dans TAAF, c’est Alloy.
• Transport — les lignes collectées voyagent vers un point central, avec les métadonnées qui permettront de les retrouver (labels).
• Stockage — les logs sont écrits dans une base optimisée pour ce volume. Dans TAAF, c’est Loki.
• Requête — on interroge cette base pour répondre à une question précise. Dans TAAF, c’est LogQL, affiché dans Grafana.

Séparer ces étapes permet de changer un maillon (par exemple l’agent de collecte) sans toucher au reste de la chaîne.

2. L’approche Loki — indexer les labels, pas le texte

C’est la différence structurante avec un moteur comme Elasticsearch, qui indexe le contenu de chaque ligne pour permettre une recherche plein texte instantanée — au prix d’un espace disque et d’une charge d’indexation importants.

Loki fait le choix inverse : il n’indexe que les labels (des métadonnées peu nombreuses comme job, host, namespace) et laisse le texte du log non indexé, compressé en blocs. Une requête commence toujours par filtrer sur les labels — ce qui réduit immédiatement le volume de données à parcourir — puis scanne le texte brut seulement dans ce sous-ensemble déjà restreint.

Conséquence directe : Loki est beaucoup plus léger à faire tourner qu’un moteur à indexation plein texte — un vrai avantage quand l’infrastructure tourne sur du matériel contraint, sur une base australe, au bout d’un lien satellite. Le compromis : mal choisir ses labels (trop peu, ou pas les bons) rend les recherches lentes.

3. LogQL en deux temps — sélectionner, puis filtrer

Une requête LogQL se lit toujours en deux temps, qui reflètent directement l’architecture de Loki :

1. Sélection par labels — {job="firewall", host="opnsense-01"} — on choisit d’abord quel flux de logs on regarde. C’est rapide : ça s’appuie sur l’index.
2. Filtrage et parsing — |= "DENY" ou | json | status="403" — on affine ensuite à l’intérieur de ce flux, sur le contenu texte ou sur des champs extraits (JSON, logfmt…).

{job="firewall"} |= "DENY" | json | line_format "{{.src_ip}} -> {{.dst_ip}}"

Retenez l’ordre : d’abord réduire avec les labels, ensuite chercher dans le texte. Une requête qui ne filtre pas assez tôt sur les labels scanne inutilement de gros volumes.

4. Logs structurés vs texte libre

Un log en texte libre ("Connexion refusée depuis 10.0.0.5") est lisible par un humain mais coûteux à interroger : il faut du texte à rechercher, sans champ exploitable directement. Un log structuré (JSON, logfmt : {"event":"conn_denied","src_ip":"10.0.0.5"}) expose des champs nommés, que LogQL peut extraire et filtrer directement (| json | src_ip="10.0.0.5").

Dès que possible, préférer des logs structurés en sortie de service : ils transforment une recherche approximative en filtre précis, et c’est ce qui rend une règle de détection (Sigma → LogQL, à l’Acte 2) fiable plutôt qu’à base de texte deviné.

5. Les logs sont des preuves

Un log n’est pas qu’un outil de diagnostic : c’est une preuve. Trois propriétés en font une preuve exploitable :

• Horodatage — sans heure fiable et synchronisée (NTP) sur toutes les machines, impossible de reconstituer une chronologie d’incident.
• Intégrité — un log qui reste sur la machine compromise peut être modifié ou effacé par l’attaquant qui y a mis les pieds.
• Rétention — une preuve qui n’existe plus au moment de l’enquête n’en est plus une.

C’est tout l’intérêt de la centralisation vue sous cet angle : en envoyant les logs vers Loki, hors de la machine source, on les met hors de portée de qui voudrait effacer ses traces localement. C’est un teaser direct vers l’Acte 3 (forensic) : la centralisation faite dès l’Acte 1 est ce qui rend l’investigation possible plus tard.

---

Où ça sert dans TAAF

• TP3 — Loki Integration — déployer Alloy et Loki, écrire les premières requêtes LogQL.
• Acte 2 — SIEM — les règles Sigma traduites en LogQL interrogent ce même Loki : c’est la colonne vertébrale de la détection.
• Acte 3 — Audit & forensic — les logs centralisés à l’Acte 1 deviennent les preuves de l’enquête.

C’est la page la plus transversale du wiki : ce même pipeline de logs sert du premier TP jusqu’à l’investigation finale.

---

Ressources associées

Ces liens sont des points de départ pour vos propres recherches — voir la bibliothèque complète sur la page Ressources, section Observabilité et Détection & SIEM.

• Grafana Loki — documentation officielle : l’agrégation de logs et LogQL en détail, la référence pour ce module.
• SigmaHQ : la détection-as-code qui, à l’Acte 2, se traduit en requêtes LogQL sur ce même Loki.

À chercher par vous-même : « Loki vs Elasticsearch », « LogQL query syntax », « structured logging JSON vs plaintext », « log integrity chain of custody ».