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 à analyser.

Le tableau ne fournit pas de prévision en matière de stockage, mais sert de base de décision. La durée de conservation, en particulier, fait partie intégrante du plan, car elle ne peut être déduite du volume des journaux : les obligations légales de conservation, les exigences de sécurité et les règles de suppression peuvent varier les unes par rapport aux autres. La restaurabilité constitue également une exigence à part entière ; la suppression automatique des journaux périmés ne remplace pas un concept de sauvegarde ou de reprise d'activité.

Une première norme applicable pourrait par exemple être env, service et host à utiliser pour les serveurs Web classiques ; les plateformes de conteneurs ne viennent compléter ces derniers que cluster et namespace, si celles-ci permettent réellement d'affiner la recherche lors du dépannage. Le schéma doit être défini en concertation avec les développeurs et l'équipe d'exploitation. L'ajout ultérieur d'étiquettes non uniformes complique les comparaisons entre les environnements et rend la recherche centralisée moins fiable.

Lors de la planification, il ne faut pas seulement tenir compte de ce qui est techniquement réalisable, mais aussi des responsabilités. Une équipe devrait être chargée des sources et des filtres, tandis qu’une autre pourrait, le cas échéant, s’occuper du stockage et de l’accès. Cela permet de déterminer si un champ manquant dans le format de journal doit être ajouté, traité comme des métadonnées structurées ou délibérément omis.

Sécuriser efficacement les clients et les accès

Loki peut traiter les données de journalisation de manière multi-clients. Lorsque la séparation des clients est activée, Loki attend l'en-tête suivant pour chaque requête X-Scope-OrgID. Cet en-tête ne constitue toutefois ni une authentification ni une preuve d'autorisation : sinon, un client pourrait en déterminer lui-même la valeur. Loki ne dispose pas d'une couche d'authentification complète ; la protection et l'attribution forcée doivent être mises en place en amont.

Un processus sécurisé commence au niveau du proxy inverse ou de la couche d’identité fiable. Une fois la connexion établie, cette couche identifie l’organisation autorisée, définit l’ID du client côté serveur, impose le protocole TLS et ne transmet à Loki que les requêtes autorisées. Des points de terminaison Loki directs, accessibles depuis le réseau, contourneraient ce contrôle. Les accès en écriture des agents nécessitent également une identité clairement délimitée et un canal de transmission sécurisé.

Le concept d'autorisation définit qui est autorisé à consulter ou à enregistrer des journaux. Il ne remplace ni le filtrage des informations confidentielles ni le contrôle de la protection des données : les jetons, les identifiants de session et les données à caractère personnel peuvent également poser problème au sein d'un mandant correctement attribué. La minimisation des données doit donc s’appliquer dès la source et lors du traitement, tandis que les droits limitent le volume de données restantes en fonction des tâches et des mandants.

Dans le cas des architectures d'hébergement distribuées, il est utile de considérer le point d'accès comme une frontière de sécurité à part entière. L'article sur l'hébergement décentralisé et ses enjeux architecturaux explique pourquoi les composants distribués ne suppriment pas la responsabilité centrale en matière d'identités et d'accès aux données. Concrètement, pour Loki, cela signifie que chaque redirection doit être attribuée de manière traçable à une instance de confiance et à une règle de client définie.

Les contrôles réguliers ne devraient donc pas se limiter aux tableaux de bord. Vérifiez si le proxy rejette les accès anonymes, si un en-tête de client prédéfini peut être écrasé par le client et si les comptes en écriture n'atteignent que les destinations prévues. De tels contrôles ne garantissent pas une sécurité totale, mais permettent de détecter rapidement les failles typiques entre la connexion, le routage et le stockage des journaux.

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

Les journaux centraux ne devraient pas être conservés simplement tant qu'il reste de l'espace dans le stockage d'objets. Les Rétention doit être conforme aux obligations légales, contractuelles et opérationnelles en matière de conservation des données – ainsi qu’à la date à partir de laquelle les données ne présentent plus d’utilité pour l’analyse des erreurs. Sans la fonctionnalité de conservation activée, les journaux envoyés à Loki sont conservés indéfiniment, selon la documentation. Cela peut entraîner une augmentation des coûts, des risques liés à la protection des données et de l'ampleur d'une restauration ultérieure.

Avec TSDB et BoltDB-Shipper, le Compactor applique les délais de suppression configurés. Il doit fonctionner en tant qu’instance unique et disposer d’un répertoire de travail persistant afin que son travail ne soit pas perdu en cas de redémarrage. Le stockage d'objets contient à la fois des blocs de journaux et des données d'index ; sa conception fait donc partie intégrante du concept d'exploitation et ne se limite pas à la seule planification des capacités.

Il peut être judicieux de définir des durées de conservation différentes selon les flux de journaux, par exemple lorsque les événements de sécurité doivent être conservés plus longtemps que les sorties de débogage détaillées. Ces règles liées aux flux nécessitent une durée de conservation d'au moins 24 heures et fonctionnent exclusivement avec des sélecteurs d'étiquettes. Les filtres de contenu ou les expressions LogQL arbitraires ne sont pas prévus à cet effet. C’est pourquoi les étiquettes doivent déjà refléter de manière fiable le contexte métier avant que les règles de rétention ne s’appuient sur celles-ci.

Avertissement : une règle de cycle de vie généralisée appliquée à l'ensemble du compartiment de stockage peut supprimer des objets d'index ou d'état de cluster et endommager les requêtes. Il est préférable d'adopter une stratégie de suppression ciblée qui tienne compte de la rétention Loki, des classes de stockage et des compartiments ou préfixes distincts. De plus, la rétention ne remplace pas la sauvegarde : elle détermine la suppression planifiée des données de journal, tandis que les exigences de restauration définissent les configurations, les chemins d'accès et, le cas échéant, les données stockées qui doivent être disponibles après une panne.

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

Dans Grafana Explore, il est possible d'analyser les événements de plusieurs hôtes sur une même période. Cela facilite la gestion d'un incident : au lieu de se connecter successivement aux serveurs web, l'analyse peut d'abord être ciblée par environnement et par service. Une recherche centralisée met toutefois en évidence des corrélations, mais ne révèle pas automatiquement la cause ; les métriques, les traces, les déploiements et l'état des applications restent des éléments complémentaires essentiels au diagnostic.

En cas de vague d'erreurs, LogQL peut calculer une métrique à partir des lignes correspondantes. La requête suivante, à titre d'exemple, compte les lignes Nginx présentant un statut HTTP 500 pour obtenir un taux sur cinq minutes. Elle sert de base à une analyse ou à une alerte, mais ne permet pas de déterminer quelle valeur est critique pour chaque application.

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

Une solution judicieuse Seuil d'alerte est calculé à partir du taux d'erreur normal, du comportement de l'application et des signaux de surveillance disponibles. Une erreur 500 isolée peut être évaluée différemment selon qu’elle survient dans une fonction administrative rarement utilisée ou lors d’un passage en caisse. Il convient donc d’examiner au préalable les tendances historiques et d’attribuer l’alerte à une équipe clairement désignée avant qu’elle ne soit transmise en production.

Si Loki renvoie le code 429 lors de l'écriture, il ne faut pas augmenter les limites de manière impulsive. Il convient tout d'abord de déterminer si un service génère un nombre inhabituellement élevé de lignes, si une boucle répète des erreurs ou si des étiquettes dynamiques génèrent un grand nombre de petits flux. Loki limite l'enregistrement de manière globale et par flux afin de protéger la plateforme. Ce n'est qu'après cette vérification qu'il est possible de décider si un filtrage, des corrections d'étiquettes ou un ajustement justifié des limites sont nécessaires.

Utiliser Loki à bon escient et de manière responsable

Pour un seul VPS équipé de Nginx, de systemd et de quelques conteneurs, Loki peut, en mode monolithique, offrir une recherche centralisée facile à gérer, à condition que les sources de journaux, le stockage et les accès soient clairement définis. La documentation réserve ce mode aux environnements expérimentaux et aux faibles volumes de lecture et d’écriture ; environ 20 Go de journaux par jour constituent une indication fournie par l’éditeur, et non une garantie de capacité pour chaque structure de stockage, d’interrogation ou d’étiquetage.

Plusieurs serveurs web Linux tirent particulièrement profit d’une chronologie commune pour les événements web, de journalisation et d’application. Dans le cadre de déploiements en conteneurs, c’est un modèle d’étiquetage stable pour l’environnement et le service qui détermine si cette recherche reste gérable. Les environnements Kubernetes de très grande envergure ou les rôles devant être mis à l'échelle de manière ciblée et séparée peuvent justifier le mode microservices, mais impliquent alors un effort nettement plus important en termes d'exploitation et d'analyse des erreurs. Pour les nouveaux projets, SSD n'est pas une option standard à long terme, car ce mode est considéré comme obsolète.

Une plateforme multi-clients nécessite en outre une chaîne d'accès robuste. Loki sépare les requêtes via l'identifiant client, mais ne fournit pas de couche d'authentification complète. Un proxy ou une couche d'identité fiable doit authentifier les accès, imposer le protocole TLS et définir le mappage côté serveur. Un agent pris en charge fait également partie des éléments fondamentaux : Promtail n'est plus pris en charge ; pour les nouvelles installations, Grafana Alloy est par exemple la solution recommandée.

• VPS unique : définir l'inventaire des sources, les filtres pour les informations confidentielles et une politique de conservation simple et vérifiable avant le déploiement.
• Plusieurs hôtes : convenir d'étiquettes stables pour l'environnement et le service, afin que la recherche centralisée permette réellement de raccourcir les parcours des incidents.
• Plateforme de conteneurs : ne pas utiliser d'identifiants dynamiques comme étiquettes ; surveiller en permanence le nombre de flux et le comportement d'enregistrement.
• Fonctionnement multi-clients : mettre en place l'authentification, l'affectation des clients côté serveur et les autorisations avant la mise à disposition des terminaux Loki.
• 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.