Loki pour la gestion centralisée des journaux dans l'hébergement

Séparer clairement Loki, Alloy et Grafana

La gestion centralisée des journaux commence au niveau des systèmes qui génèrent des événements : hôtes Linux, serveurs virtuels, conteneurs et applications. C'est là que sont créées, par exemple, les entrées de journal de systemd, les journaux d'accès et d'erreurs de Nginx ou les sorties standard des conteneurs Docker. Grafana Alloy Il lit ces sources, peut les traiter avant leur envoi et les transmet à Loki. Alloy fait donc office de collecteur de données, et non de stockage central des journaux.

Grafana Loki reçoit les données de journalisation, les regroupe et les stocke en vue de consultations ultérieures. Un système de stockage d'objets peut alors accueillir les données persistées. Grafana, quant à lui, fournit souvent l'interface pour l'exploration, les tableaux de bord et les alertes, mais ne fait techniquement pas partie de Loki lui-même. Cette séparation facilite la répartition claire des responsabilités en cas de modifications, de pannes et de droits d'accès.

Dans un petit exemple d'hébergement, Alloy lit, sur un VPS, le journal systemd ainsi que les fichiers Nginx et les journaux des conteneurs. Il envoie les lignes sélectionnées à Loki ; un administrateur les examine ensuite dans Grafana, au lieu de devoir se connecter individuellement à chaque hôte pour effectuer une première analyse des erreurs. En amont de Loki, un proxy inverse ou une couche d'identité doit gérer les authentifications, le protocole TLS, le routage et, le cas échéant, l'attribution des clients.

L'agrégation centralisée raccourcit les chemins de recherche, mais ne remplace ni l'analyse des causes ni les processus opérationnels. Protection de l'accès Il faut déterminer qui est autorisé à consulter quelles données ; le principe de minimisation des données permet de décider, avant même l'envoi, quels champs doivent être supprimés. La mise en place d'un dispositif de sauvegarde et de restauration reste également une tâche distincte : Loki permet de localiser les journaux existants, mais ne garantit pas à lui seul leur protection, leur intégrité ou leur conservation conforme à la législation.

Dans la pratique, Loki n'est donc utile qu'après un inventaire des sources : quels fichiers journaux sont utiles pour l'exploitation et la gestion des incidents, lesquels contiennent des informations confidentielles ou des données à caractère personnel, et qui a besoin d'y accéder ? Ce sont ces réponses qui déterminent les filtres, la durée de conservation et les autorisations. Centraliser tous les fichiers journaux Linux sans les vérifier ne fait que déplacer les informations sensibles vers un espace de stockage plus facilement consultable.

Comprendre les flux, les étiquettes et LogQL

Loki n'organise pas les lignes entrantes principalement sous forme d'index de texte intégral. Il les regroupe en fonction de l'ID du client et de leur ensemble d'étiquettes pour former un Flux ensemble. Les données de journalisation proprement dites sont stockées sous forme compressée dans des « chunks » ; l'index associe des ensembles d'étiquettes à ces « chunks ». Lors d'une recherche, Loki délimite donc d'abord les flux correspondants à l'aide des étiquettes, puis charge les données concernées afin de les filtrer ou de les analyser plus en détail.

Les étiquettes doivent exprimer un contexte clair et durable : par exemple env, service et avec des serveurs stables host. Dans les environnements de conteneurs, les clusters, les espaces de noms ou les applications peuvent également s'avérer utiles. Cependant, chaque combinaison unique forme un flux. Les identifiants de requête, d'utilisateur et de trace, ainsi que les identifiants de conteneur ou les adresses IP client changeants génèrent un très grand nombre de valeurs et n'ont donc généralement pas leur place dans les étiquettes.

Pour les analyses détaillées ponctuelles, ces informations dynamiques sont conservées dans la ligne de journal et ne sont exploitées qu’au moment de la requête, par exemple via un analyseur JSON ou Logfmt. Les données contextuelles fréquemment utilisées et à cardinalité élevée peuvent se prêter davantage à une représentation sous forme de métadonnées structurées. Il est essentiel de tester le modèle de données sur des sources réelles avant son déploiement, plutôt que d'étiqueter sans filtrage tous les champs disponibles.

Une requête LogQL en lecture seule pour les erreurs Nginx peut se présenter comme suit. Elle s'utilise notamment dans Grafana Explore ou LogCLI et suppose que les étiquettes sélectionnées aient bien été attribuées lors de la collecte.

{env="prod", service="nginx"} |= " 500 "

Le sélecteur situé en amont du pipeline réduit d'abord le flux aux flux de production du service Nginx ; ce n'est qu'ensuite |= " 500 " recherche le texte. La qualité d'une requête dépend toutefois de la période, du volume des logs, des latences de stockage et de la conception des étiquettes. Loki ne garantit donc pas de temps de réponse fixe. Des plages horaires restreintes et des sélecteurs précis et stables constituent un bon point de départ pour une analyse progressive.

Quelle architecture Loki convient à l'hébergement ?

Pour un seul VPS, un laboratoire ou de faibles volumes de journaux, le fonctionnement monolithique C'est souvent le point de départ le plus simple : un processus Loki regroupe tous les composants nécessaires. La documentation recommande ce mode pour les expérimentations ainsi que pour les petits volumes de lecture et d’écriture, jusqu’à environ 20 Go de journaux par jour. Il s’agit d’une recommandation du fabricant pour ce domaine d’application, et non d’une garantie de capacité pour toutes les structures de stockage, d’interrogation ou d’étiquetage.

Si les exigences en matière de disponibilité augmentent sans qu'il soit nécessaire de faire évoluer de manière ciblée certains rôles Loki, un fonctionnement monolithique à haute disponibilité peut être envisagé. Le mode microservices est prévu pour les très grands clusters ou les environnements Kubernetes dans lesquels les composants doivent être mis à l'échelle séparément. Cette granularité ne supprime toutefois pas la nécessité de planification : elle augmente le nombre d'éléments opérationnels et, par conséquent, les efforts de diagnostic et de maintenance.

Le mode « Simple Scalable Deployment » ne constitue pas une solution intermédiaire neutre pour les nouveaux projets. Grafana a qualifié le SSD d’obsolète et a annoncé sa suppression avec Loki 4.0. Quiconque met en place une infrastructure aujourd’hui devrait donc évaluer une approche monolithique offrant une disponibilité adaptée ou une architecture à microservices en fonction des besoins réels en matière d’évolutivité, plutôt que de prévoir une architecture de transition à long terme.

Pour faciliter la prise de décision, il ne suffit pas de tenir compte des gigaoctets générés quotidiennement. Il faut également prendre en considération les pics d’écriture, le nombre et la cardinalité des flux, la séparation des mandants requise, la conservation des données, ainsi que l’expertise de l’équipe en matière de Kubernetes et de composants distribués. Les projets dont la mise en production est répartie à l'échelle mondiale nécessitent de toute façon une distinction claire entre les services opérationnels centraux et les composants en périphérie ; l'article consacré à Hébergement web pour le rendu Edge et la livraison décentralisée.

Commencez modestement si les sources de logs, les étiquettes et les accès ne sont pas encore définis de manière stable. Un changement d'architecture doit être justifié par des besoins observés, tels qu'une évolutivité ciblée ou une disponibilité accrue, et non par une anticipation générale d'une croissance future. Ainsi, l'effort nécessaire pour Gestion des journaux par rapport aux avantages offerts par la recherche centralisée et le traitement des incidents.

Collecter les journaux Linux en toute sécurité avec Alloy

Avant la mise en place, il convient de dresser un inventaire des sources : quels fichiers journaux sont réellement utiles pour l'exploitation et la gestion des incidents ? Sur un serveur web Linux, il s'agit souvent du journal systemd, des fichiers journaux d'accès et d'erreurs Nginx, de PHP-FPM, des événements SSH et des tâches Cron. Dans le cas des conteneurs, il faut y ajouter les sorties du runtime et les journaux spécifiques à l’application. Il est tout aussi important de procéder à une vérification préalable des mots de passe, des clés API, des identifiants de session et des données à caractère personnel ; ces informations ne doivent en aucun cas être transmises de manière centralisée sans avoir été préalablement examinées.

Pour les nouvelles installations, Grafana Alloy la méthode prise en charge pour la collecte et le transfert. Promtail ne doit donc plus être utilisé par défaut : son cycle de vie a pris fin le 2 mars 2026, et la documentation recommande d'utiliser Alloy ou un autre client pris en charge pour les migrations et les nouvelles configurations. Une installation Promtail existante nécessite donc une migration planifiée plutôt qu’une mise à jour tacite.

Le modèle de configuration reste simple : une source lit des fichiers, le journal ou les logs des conteneurs ; un traitement facultatif peut rejeter les lignes indésirables ou formater les champs ; ensuite, elle transmet loki.write les données à Loki. Alloy fournit des composants pour, entre autres, les fichiers, les journaux systemd, Docker, Kubernetes, Syslog et les événements Windows. Le choix de la source dépend de l'endroit où l'application envoie ses événements de manière fiable.

Un modèle ne constitue pas encore une configuration prête pour la production. Les droits d'accès aux fichiers doivent uniquement accorder au processus Alloy l'accès en lecture nécessaire ; l'accès au journal, l'adresse de destination, la vérification des certificats, le protocole TLS, la mise en mémoire tampon en cas de perturbations réseau et la gestion des pannes doivent être vérifiés en fonction de l'installation. Les identifiants d'accès et les informations relatives aux clients ne doivent pas figurer dans des fichiers d'exemple partagés. Commencez par un petit nombre de sources, vérifiez le contenu et le volume, puis élargissez la collecte par la suite.

Le filtrage au niveau de l'agent ne réduit en rien la responsabilité quant à l'origine des données et ne remplace pas non plus un système d'autorisations. Il empêche toutefois que des sorties de débogage connues ou des informations confidentielles clairement identifiées ne parviennent jusqu'au référentiel central. Pour les contenus nécessaires d’un point de vue technique, il doit être possible de déterminer quel service les envoie, qui est autorisé à les consulter ultérieurement et pendant combien de temps ils sont nécessaires.

Concept de marque et planification avant le déploiement

A Concept de marque définit le contexte stable dans lequel les journaux peuvent être localisés. Pour plusieurs hôtes et environnements, on peut par exemple utiliser env, cluster, namespace, app, service et, si la référence est utile à long terme, un nom d'hôte. Leurs valeurs doivent être limitées et prévisibles. Chaque ensemble distinct d'étiquettes forme un flux distinct ; par conséquent, le modèle influe directement sur l'ingestion, l'indexation et les requêtes ultérieures.

En revanche, les identifiants de requête, de trace et d'utilisateur, les adresses IP des clients ainsi que les identifiants de conteneurs dynamiques ne constituent pas des étiquettes appropriées. Ils génèrent trop de valeurs différentes et, par conséquent, de nombreux petits flux. Les informations à cardinalité élevée peuvent, le cas échéant, être intégrées sous forme de métadonnées structurées. Pour une analyse ponctuelle, il est souvent plus judicieux de ne récupérer le contenu du journal qu’au moment de la requête avec json, logfmt, pattern ou regexp zu parsen.

Die Tabelle liefert keine Speicherprognose, sondern eine Entscheidungsgrundlage. Besonders die Retention gehört zum Plan, weil sie nicht aus dem Logvolumen abgeleitet werden kann: Fachliche Aufbewahrungspflichten, Sicherheitsbedarf und Löschvorgaben können voneinander abweichen. Wiederherstellbarkeit ist ebenfalls eine eigene Anforderung; die automatische Löschung abgelaufener Logs ersetzt kein Backup- oder Wiederanlaufkonzept.

Ein praktikabler erster Standard kann beispielsweise env, service et host für klassische Webserver verwenden; Container-Plattformen ergänzen nur dann cluster et namespace, wenn diese bei der Fehlersuche wirklich selektieren. Das Schema sollte mit Entwicklern und Betrieb abgestimmt sein. Nachträgliche, uneinheitliche Labels erschweren Vergleiche zwischen Umgebungen und machen die zentrale Suche weniger verlässlich.

Für die Planung zählt nicht nur, was technisch erfassbar ist, sondern auch die Zuständigkeit. Ein Team sollte für Quellen und Filter verantwortlich sein, ein anderes gegebenenfalls für Storage und Zugriff. So wird sichtbar, ob ein fehlendes Feld im Logformat ergänzt, als strukturierte Metadaten behandelt oder bewusst nicht erhoben werden sollte.

Sécuriser efficacement les clients et les accès

Loki kann Logdaten mandantenfähig verarbeiten. Wenn die Mandantentrennung aktiviert ist, erwartet Loki je Anfrage den Header X-Scope-OrgID. Dieser Header ist jedoch keine Anmeldung und kein Berechtigungsnachweis: Ein Client könnte seinen Wert sonst selbst bestimmen. Loki bringt keine vollständige Authentifizierungsschicht mit; Schutz und erzwungene Zuordnung müssen davor liegen.

Ein belastbarer Ablauf beginnt am vertrauenswürdigen Reverse Proxy oder Identity-Layer. Nach erfolgreicher Anmeldung ermittelt diese Schicht die berechtigte Organisation, setzt die Mandanten-ID serverseitig, erzwingt TLS und leitet nur erlaubte Anfragen an Loki weiter. Direkte, aus dem Netz erreichbare Loki-Endpunkte würden diese Kontrolle umgehen. Auch Schreibzugriffe von Agenten benötigen eine eindeutig begrenzte Identität und einen geschützten Übertragungsweg.

Das Berechtigungskonzept beantwortet, wer Logs lesen oder einspeisen darf. Es ersetzt weder die Filterung von Geheimnissen noch die Datenschutzprüfung: Tokens, Session-IDs und personenbezogene Angaben können auch innerhalb eines korrekt zugeordneten Mandanten problematisch sein. Datenminimierung muss daher bereits an Quelle und Verarbeitung greifen, während Rechte den verbleibenden Bestand nach Aufgaben und Mandanten begrenzen.

Bei verteilten Hosting-Architekturen hilft es, den Zugriffspunkt als eigene Sicherheitsgrenze zu behandeln. Der Beitrag zu dezentralem Hosting und seinen Architekturfragen ordnet ein, warum verteilte Komponenten keine zentrale Verantwortlichkeit für Identitäten und Datenzugriffe aufheben. Für Loki heißt das konkret: Jede Weiterleitung muss nachvollziehbar einer vertrauenswürdigen Instanz und einer festgelegten Mandantenregel zugeordnet sein.

Regelmäßige Prüfungen sollten deshalb nicht nur Dashboards einschließen. Kontrolliere, ob der Proxy anonyme Zugriffe ablehnt, ob ein vorgegebener Mandanten-Header vom Client überschrieben werden kann und ob Schreibkonten nur die vorgesehenen Ziele erreichen. Solche Prüfungen belegen keine vollständige Sicherheit, decken aber typische Lücken zwischen Login, Routing und Logspeicher früh auf.

Gérer la conservation et le stockage de manière contrôlée

Zentrale Logs sollten nicht einfach so lange gespeichert werden, wie im Objektspeicher Platz ist. Die Rétention muss zu gesetzlichen, vertraglichen und betrieblichen Aufbewahrungspflichten passen – und ebenso zu dem Zeitpunkt, ab dem Daten für die Fehleranalyse keinen Nutzen mehr bringen. Ohne aktivierte Aufbewahrung bleiben an Loki gesendete Logs laut Dokumentation unbegrenzt erhalten. Das kann Kosten, Datenschutzrisiken und den Umfang einer späteren Wiederherstellung erhöhen.

Bei TSDB und BoltDB-Shipper setzt der Compactor die konfigurierten Löschfristen um. Er sollte als einzelne Instanz laufen und ein persistentes Arbeitsverzeichnis erhalten, damit seine Arbeit nicht bei einem Neustart unvollständig verloren geht. Der Objektspeicher enthält dabei sowohl Log-Chunks als auch Indexdaten; seine Auslegung gehört deshalb zum Betriebskonzept und nicht nur zur Kapazitätsplanung.

Unterschiedliche Fristen je Logstrom können sinnvoll sein, etwa wenn Sicherheitsereignisse länger benötigt werden als ausführliche Debug-Ausgaben. Solche streambezogenen Regeln benötigen mindestens 24 Stunden Retention und arbeiten ausschließlich mit Label-Selektoren. Inhaltliche Filter oder beliebige LogQL-Ausdrücke sind dafür nicht vorgesehen. Deshalb müssen die Labels den fachlichen Kontext bereits zuverlässig abbilden, bevor Retention-Regeln darauf aufbauen.

Warnung: Eine pauschale Lifecycle-Regel auf dem gesamten Storage-Bucket kann Index- oder Clusterzustandsobjekte entfernen und Abfragen beschädigen. Besser ist ein gezieltes Löschkonzept, das Loki-Retention, Speicherklassen und getrennte Buckets oder Präfixe berücksichtigt. Retention ersetzt außerdem kein Backup: Sie bestimmt das geplante Löschen von Logdaten, während Wiederherstellungsanforderungen festlegen, welche Konfigurationen, Zugriffswege und gegebenenfalls Speicherdaten nach einem Ausfall verfügbar sein müssen.

Détecter les ondes d'erreur et vérifier les problèmes d'enregistrement

In Grafana Explore lassen sich Ereignisse mehrerer Hosts in einem gemeinsamen Zeitraum untersuchen. Das verkürzt den Weg bei einem Incident: Statt sich nacheinander auf Webserver einzuloggen, kann die Untersuchung zunächst nach Umgebung und Dienst eingegrenzt werden. Eine zentrale Suche zeigt jedoch Korrelationen, nicht automatisch die Ursache; Metriken, Traces, Deployments und Anwendungszustand bleiben für die Diagnose wichtige Ergänzungen.

Für eine Fehlerwelle kann LogQL aus passenden Zeilen eine Metrik ableiten. Die folgende Abfrage zählt beispielhaft Nginx-Zeilen mit HTTP-Status 500 als Rate über fünf Minuten. Sie ist eine Grundlage für eine Auswertung oder einen Alert, aber keine Aussage darüber, welcher Wert in jeder Anwendung kritisch ist.

sum(rate({env="prod", service="nginx"} |= " 500 " [5m]))

Ein sinnvoller Alert-Schwellenwert entsteht aus der normalen Fehlerrate, dem Verhalten der Anwendung und vorhandenen Monitoring-Signalen. Ein einzelner 500-Fehler kann bei einer selten genutzten Verwaltungsfunktion anders zu bewerten sein als bei einem Checkout. Prüfe daher zunächst historische Muster und verknüpfe den Alarm mit einem klaren Zuständigkeitsteam, bevor er produktiv eskaliert wird.

Antwortet Loki beim Schreiben mit 429, sollten Limits nicht reflexhaft erhöht werden. Zuerst ist zu klären, ob ein Dienst ungewöhnlich viele Zeilen erzeugt, eine Schleife Fehler wiederholt oder dynamische Labels eine große Zahl kleiner Streams erzeugen. Loki begrenzt Aufnahme global und pro Stream zum Schutz der Plattform. Erst nach dieser Prüfung lässt sich entscheiden, ob Filterung, Labelkorrekturen oder eine begründete Anpassung der Limits nötig sind.

Utiliser Loki à bon escient et de manière responsable

Für einen einzelnen VPS mit Nginx, systemd und wenigen Containern kann Loki im monolithischen Modus eine überschaubare zentrale Suche schaffen, sofern Logquellen, Speicher und Zugriffe klar geregelt sind. Die Dokumentation ordnet diesen Modus Experimenten und kleinen Lese- und Schreibvolumina zu; ungefähr 20 GB Logs täglich sind dabei eine Herstellerorientierung, keine Kapazitätszusage für jede Storage-, Abfrage- oder Labelstruktur.

Mehrere Linux-Webserver profitieren besonders von einer gemeinsamen Zeitleiste für Web-, Journal- und Anwendungsereignisse. Bei Container-Deployments entscheidet ein stabiles Labelmodell für Umgebung und Dienst darüber, ob diese Suche handhabbar bleibt. Sehr große Kubernetes-Umgebungen oder gezielt separat zu skalierende Rollen können den Microservices-Modus rechtfertigen, tragen dann aber deutlich mehr Betriebs- und Fehleranalyseaufwand. Für Neuplanungen ist SSD keine dauerhafte Standardoption, weil dieser Modus als veraltet markiert ist.

Eine mandantenfähige Plattform benötigt zusätzlich eine belastbare Zugriffskette. Loki trennt Anfragen über die Mandantenkennung, stellt aber keine vollständige Authentifizierungsschicht bereit. Ein vertrauenswürdiger Proxy oder Identity-Layer muss Zugriffe authentifizieren, TLS erzwingen und die Zuordnung serverseitig setzen. Auch ein unterstützter Agent ist Teil der Grundlage: Promtail wird nicht mehr unterstützt; für neue Installationen ist etwa Grafana Alloy der vorgesehene Weg.

• Einzelner VPS: Quelleninventar, Filter für Geheimnisse und eine einfache, überprüfbare Retention vor dem Rollout festlegen.
• Mehrere Hosts: stabile Labels für Umgebung und Service vereinbaren, damit die zentrale Suche Incident-Wege tatsächlich verkürzt.
• Container-Plattform: dynamische IDs nicht als Labels verwenden; Stream-Anzahl und Aufnahmeverhalten fortlaufend beobachten.
• Mehrmandantenbetrieb: Authentifizierung, serverseitige Mandantenzuordnung und Berechtigungen vor der Freigabe von Loki-Endpunkten umsetzen.
• Tout environnement : documenter les exigences en matière de restauration et vérifier régulièrement la configuration, le concept de stockage ainsi que les délais de suppression.

En l'absence de responsables des sources de journaux, d'une stratégie relative aux contenus sensibles ou d'objectifs de restauration clairs, il convient tout d'abord de Principes de fonctionnement doit être clarifiée. Loki permet d'agréger les journaux et de les rendre consultables, mais ne remplace ni la minimisation des données, ni les sauvegardes, ni le contrôle d'accès, ni une analyse technique des causes. Son utilité ne se concrétise que lorsque la technologie, les responsabilités et la conservation des données sont planifiées conjointement.