La télémétrie sans mystère : Prometheus, Loki, Tempo et Grafana, et pourquoi OpenTelemetry

C'est lundi, neuf heures du matin, et les virements d'une banque prennent trois fois plus de temps que d'habitude. Les plaintes arrivent, un incident est ouvert et cinq équipes se retrouvent sur le même appel : canaux digitaux, système central, antifraude, réseaux et infrastructure. Chacune consulte son propre écran et chacune conclut la même chose : « de notre côté, tout va bien ». Deux heures passent avant que quelqu'un remarque que la lenteur venait de la requête d'un seul service.

Ce scénario, illustratif et sans client derrière, ne décrit pas une mauvaise équipe. Il décrit un système dont personne ne peut voir le parcours complet d'une opération. La télémétrie est la réponse à ce problème : les données qu'un système émet sur lui-même pendant qu'il travaille, afin qu'on puisse le comprendre de l'extérieur, sans l'ouvrir et sans deviner. Cet article s'adresse à celles et ceux qui répondent de ces systèmes dans une banque, une fintech, un assureur, une enseigne de retail ou une entreprise réglementée, ainsi qu'au directeur métier qui veut comprendre ce qu'on lui demande lorsque l'équipe technique dit « nous avons besoin d'observabilité ».

Nous parlerons de quatre outils ouverts très utilisés —Prometheus, Loki, Tempo et Grafana— et d'un standard, OpenTelemetry, qui les relie. Nous expliquerons à quoi répond chacun, comment ils se croisent, pourquoi un standard commun est utile, comment on les monte dans des conteneurs et dans Kubernetes, quand il suffit de lire les logs et quand il faut instrumenter le logiciel de l'intérieur, et ce que tout cela coûte et quels risques cela comporte.

Trois signaux pour trois questions différentes

Un système en production peut raconter son histoire de trois manières, et chacune répond à une question différente. Cet article se concentre sur les trois signaux opérationnels les plus courants, ceux qu'OpenTelemetry appelle des signaux [2] : métriques, traces et logs.

• Métriques : que se passe-t-il, et en quelle quantité ? Une métrique est une mesure capturée pendant que le système tourne : combien de virements par minute, combien de temps ont pris 95 % d'entre eux, combien ont échoué. C'est un nombre dans le temps, peu coûteux à conserver et excellent pour voir une tendance ou déclencher une alerte. Elle ne dit pas quelle opération a échoué.
• Traces : par où cette opération est-elle passée et où s'est-elle arrêtée ? Une trace est le parcours complet d'une requête à travers tous les services qu'elle a touchés, avec le temps passé dans chacun [2]. C'est la carte d'une seule opération. Chaque tronçon de cette carte s'appelle un span.
• Logs : que disait le système à ce moment-là ? Un log est l'enregistrement d'un événement : une ligne de texte ou de données avec la date, la gravité et le message. C'est le détail fin : « le délai d'attente du pool de connexions a été dépassé ».

Aucun des trois ne suffit seul. La métrique avertit mais ne localise pas ; la trace localise mais n'explique pas ; le log explique mais, sans contexte, c'est une aiguille dans une botte de foin. La bonne pratique, et le fil de cet article, consiste à les utiliser en chaîne. Dans une instrumentation bien conçue, la métrique avertit généralement, la trace circonscrit généralement le parcours et les logs peuvent apporter le détail ; la qualité de la réponse dépend de ce qui a été émis et conservé.

À quoi répond chaque outil

Chaque signal a un outil ouvert conçu pour le stocker et l'interroger. Avant le tableau, une précision utile pour un comité : aucun de ces outils n'est interchangeable avec un autre. Ce sont des stockages spécialisés.

Deux précisions qui évitent des malentendus. La première : Prometheus n'est pas une caisse enregistreuse. Sa propre documentation avertit que, si l'on a besoin d'une exactitude totale, comme pour la facturation à la requête, ce n'est pas un bon choix [9]. Il sert à l'exploitation —savoir si le système est sain—, pas à effectuer un rapprochement. Dans une banque ou une fintech, cette frontière compte : le rapprochement vit dans les écritures comptables, pas dans un tableau de bord de latence.

La seconde : Loki est peu coûteux précisément parce qu'il n'indexe pas le contenu des logs, seulement quelques étiquettes par flux (de quel service et de quel environnement il provient). Les données sont compressées en blocs et stockées dans un stockage d'objets [15]. La contrepartie est que la recherche de texte dans les logs se fait au moment de la requête, et non avec un index préalable, et que les étiquettes doivent être choisies avec soin. Nous y reviendrons dans les coûts.

Le rôle de Grafana

Grafana est la fenêtre. Selon sa documentation, il permet d'interroger, de visualiser, d'alerter et d'explorer des métriques, des logs et des traces, quel que soit l'endroit où ils sont stockés [19]. Chaque système de stockage se connecte comme une source de données : Prometheus, Loki et Tempo sont trois sources, et Grafana peut en avoir d'autres à côté, comme des bases de données SQL [20].

Sa valeur ne tient pas au joli tableau de bord, mais au fait qu'il croise les sources. Depuis un même endroit, on peut passer d'un graphique à une trace et d'une trace à ses logs. Pour un dirigeant, cela se traduit par quelque chose de concret : Grafana peut concentrer l'enquête dans une seule vue si les sources, les autorisations et les liens sont configurés, au lieu de cinq écrans et d'un appel.

Comment l'information se croise

Que les trois signaux existent ne signifie pas qu'ils soient reliés. La liaison n'apparaît pas en installant Grafana : elle se conçoit dès que l'on instrumente le logiciel et se teste de bout en bout. Le fil conducteur est un identifiant, le trace_id, qui voyage avec chaque opération. Le standard de propagation qu'OpenTelemetry utilise par défaut, W3C Trace Context, transporte cet identifiant dans un en-tête appelé traceparent d'un service au suivant [2].

Imaginez le trace_id comme le numéro de suivi d'un colis. Si chaque service l'estampille sur ce qu'il produit, on peut ensuite demander « tout ce qui s'est passé avec le numéro 4F2A… ».

De la métrique à la trace : les exemplars

Un exemplar est un échantillon concret rattaché à une métrique agrégée. Pensez à un graphique de latence : chaque point résume des milliers d'opérations. Un exemplar est, en ce point, l'exemple d'une opération réelle —avec son trace_id— qui a contribué à cette mesure. Dans Grafana, il apparaît comme une étoile sur le graphique ; en cliquant, la trace de cette opération s'ouvre dans Tempo [20].

Pour que le clic du graphique vers la trace fonctionne, quatre éléments doivent être activés ; s'il en manque un, le clic ne mène nulle part. La documentation de Grafana le résume ainsi : les métriques donnent la vue agrégée et les traces, la vue fine d'une requête [20]. Il convient de connaître ces conditions avant de les promettre à qui que ce soit :

1. L'application doit émettre le trace_id avec la mesure, au sein d'une trace qui est conservée.
2. Prometheus doit stocker les exemplars. Aujourd'hui, cette capacité s'active avec un indicateur marqué comme expérimental et désactivé par défaut [12].
3. Dans Grafana, il faut configurer la source Prometheus pour que le lien pointe vers Tempo et indique quel champ porte le trace_id [20].
4. La trace visée doit encore exister : si l'échantillonnage ou la rétention l'ont déjà écartée, le clic ne mène nulle part.

Une voie alternative consiste à faire calculer par Tempo des métriques à partir des traces —taux de requêtes, erreurs et durée, le fameux trio RED (Rate, Errors, Duration), les trois mesures standard avec lesquelles on surveille un service— et à les envoyer vers une base compatible avec Prometheus, avec ses exemplars [17]. Cette voie doit être testée au regard des limites de séries actives, un sujet que nous reprenons dans les coûts.

De la trace au log : le `trace_id` dans chaque ligne

Depuis une trace dans Tempo, Grafana peut ouvrir les logs de ce service dans cette fenêtre de temps, en interrogeant Loki. Cela se configure dans la source de données de Tempo (trace to logs), et il existe un lien équivalent vers les métriques (trace to metrics) [21]. Pour corréler un log avec sa trace, incluez le trace_id ; ajoutez le span_id lorsque vous devez restreindre la recherche au span qui a émis le log. Le modèle de données des logs d'OpenTelemetry les prévoit comme des champs à part entière [40], et pour les formats qui ne sont pas OTLP, il recommande de les nommer trace_id, span_id et trace_flags [41].

Du log à la trace

Le chemin inverse se configure dans Loki avec des champs dérivés (derived fields) : une règle qui extrait le trace_id de la ligne et le transforme en lien vers Tempo [47]. Les deux côtés sont nécessaires : ne configurer que Tempo ne rend pas un log navigable vers sa trace.

Une règle d'or de ce croisement : le trace_id, et en général tout identifiant de client, de commande, de compte ou de police, ne doit pas être une étiquette de Loki. Il doit voyager dans le contenu du log, ou comme métadonnée structurée. Nous expliquons plus loin pourquoi [14].

Pourquoi OpenTelemetry plutôt que chaque technologie directement

Les quatre outils précédents ont leurs propres façons de recevoir des données. On pourrait programmer chaque application pour qu'elle parle directement à chacun : une bibliothèque pour les métriques de Prometheus, une autre pour les logs vers Loki et une autre pour les traces vers Tempo. Cela fonctionne, mais cela attache le code de chaque service à trois modèles différents, trois stratégies de nouvelle tentative et trois chemins de migration.

OpenTelemetry (abrégé OTel) est un projet de la CNCF, la fondation qui héberge Kubernetes et Prometheus. Il se définit comme un cadre pour générer, exporter et collecter de la télémétrie ; il est neutre vis-à-vis des fournisseurs et, point important, ce n'est pas un backend : il ne stocke ni ne dessine rien [1]. Il apporte quatre éléments :

• API et SDK : des bibliothèques par langage avec lesquelles le logiciel émet métriques, traces et logs selon un modèle commun.
• OTLP : le protocole commun pour transporter les trois signaux, sur gRPC (port 4317 par défaut) ou HTTP (4318) [4].
• Conventions sémantiques : des noms standard pour ce que l'on mesure, de sorte que « le service » ou « le pod » portent le même nom dans les trois signaux [46]. Sans cet accord, le croisement entre outils se rompt.
• Collector : un programme intermédiaire qui reçoit la télémétrie, l'enrichit, la filtre et la réexpédie vers une ou plusieurs destinations [6].

La conséquence pratique : l'application émet une seule fois, dans un langage standard, et les décisions sur la destination, ce qui est filtré et ce qui est masqué vivent dans une configuration contrôlée, et non dispersées dans le code de chaque équipe. Les systèmes de stockage eux-mêmes parlent déjà ce langage : Loki, Tempo et Alloy peuvent recevoir l'OTLP, et Prometheus peut recevoir des métriques OTLP lorsque --web.enable-otlp-receiver est explicitement activé [13][16][18][26].

Pour un dirigeant, l'argument est celui de la portabilité et du contrôle. La documentation d'OpenTelemetry le présente comme le fait de ne pas être attaché à un fournisseur et de n'apprendre qu'un seul ensemble de conventions [1]. OpenTelemetry réduit la dépendance du code vis-à-vis de la destination, même si une migration peut encore exiger de valider conventions, exportateurs, échantillonnage, tableaux de bord, alertes et rétention ; la destination se change dans le Collector.

Deux nuances d'honnêteté, parce que ce type de promesse se gonfle facilement :

• La portabilité n'est pas gratuite. Même avec OpenTelemetry, les tableaux de bord, les alertes et les requêtes écrites en PromQL, LogQL et TraceQL se réécrivent si l'on change de système de stockage. Ce que l'on économise, c'est la réinstrumentation du logiciel, qui est souvent la partie la plus coûteuse.
• La maturité varie selon le signal et le langage. Selon la spécification, les traces, les métriques et les logs ont un protocole stable, mais le SDK de métriques figure comme « mixte » et les profils sont encore en développement [3]. Par langage, Java a les trois signaux stables ; Go, Python et JavaScript ont des traces et des métriques stables, tandis que les logs sont en candidat à la version finale en Go et en développement en Python et JavaScript [5]. Celui qui programme en Java part d'un terrain plus solide ; celui qui programme dans d'autres langages doit vérifier l'état des logs avant de miser sur eux.

À titre de référence d'adoption, dans l'enquête annuelle 2024 de la CNCF, à la question sur les projets incubés (n=689), 39 % ont déclaré OpenTelemetry en production et 23 % en évaluation ; c'est un échantillon de sa communauté, et non une part de marché [44].

Comment on le monte : conteneurs et Kubernetes

La télémétrie a besoin de trois éléments sur son chemin : ce qui la génère (le logiciel), ce qui la collecte et la traite (le Collector ou un agent) et ce qui la stocke et l'affiche (Prometheus, Loki, Tempo, Grafana). Ce qui change, c'est l'endroit où l'on place le collecteur selon la plateforme.

Dans Docker et Docker Compose

Compose déclare plusieurs services, réseaux et volumes dans un seul fichier ; c'est pourquoi on l'utilise pour le développement, les tests intégrés et les petits environnements [28]. Le montage typique est le suivant : les applications envoient de l'OTLP vers un conteneur avec le Collector (ou Alloy) ; le Collector répartit les traces vers Tempo, les logs vers Loki et les métriques vers Prometheus ; et Grafana interroge les trois. Le Collector s'exécute comme une image officielle avec son fichier de configuration monté ; sans ce fichier, il ne démarre pas [28].

Deux détails sur les logs dans Docker surprennent souvent :

• Docker capture par défaut la sortie standard et la sortie d'erreur standard. Si l'application écrit uniquement dans des fichiers, docker logs n'affichera pas ces lignes. C'est pourquoi les images officielles de serveurs web redirigent leurs fichiers vers la sortie standard [28].
• Le pilote par défaut ne fait pas de rotation des logs. Le pilote json-file n'a pas de limite de taille par défaut, et Docker recommande le pilote local, qui fait une rotation par défaut (selon Docker, fichiers de 20 Mo, jusqu'à cinq) [28]. Un disque plein à cause des logs est un véritable incident d'exploitation.

De plus, le mode de livraison compte : en mode bloquant, qui est celui par défaut, un pilote lent peut freiner l'application ; en mode non bloquant, il utilise un tampon et, s'il se remplit, il écarte des messages [28]. Et avec le pilote Fluentd en mode synchrone, s'il n'y a pas de connexion, le conteneur s'arrête [29]. Il faut choisir en connaissance de cause entre ne pas perdre de logs et ne pas freiner le service.

Dans Kubernetes

Kubernetes recommande que les applications écrivent sur la sortie standard et que le stockage des logs soit externe, avec un cycle de vie séparé de celui du pod ; il ne fournit pas de stockage de logs propre [27]. La rotation est assurée par le kubelet (valeur par défaut de Kubernetes : fichiers de 10 Mio et cinq par conteneur) et kubectl logs ne voit que le fichier le plus récent [27]. Autrement dit, sans collecteur, les logs d'un pod qui a redémarré ou fait l'objet d'une rotation peuvent être perdus.

La documentation de Kubernetes décrit trois modèles pour collecter au niveau du cluster : un agent par nœud, un agent dans chaque pod, ou l'application qui envoie directement à la destination [27]. OpenTelemetry les traduit en ces montages :

Quatre précautions que la documentation signale et qui, lorsqu'on les ignore, se paient en reprises pendant la mise en œuvre :

1. Étiqueter chaque log avec son propriétaire. Un log lu depuis un fichier ne sait pas de quel pod il provient. Le processeur k8sattributes ajoute le pod, l'espace de noms, le déploiement et le nœud à chaque enregistrement, et il est stable pour les trois signaux [33]. La lecture de fichiers (filelog) est en bêta pour les logs [32] et, par défaut, ne lit que ce qui arrive après le démarrage ; sans sauvegarde de sa position, un redémarrage peut dupliquer ou perdre des lignes [32].
2. Une métrique, un seul rédacteur. Deux collecteurs qui rapportent la même série produisent des données hors séquence dans Prometheus [8].
3. Le collecteur aussi tombe en panne. Avec une file d'envoi, des tentatives et un stockage persistant configurés, il peut résister aux pannes transitoires ; même ainsi, un disque plein, une panne prolongée ou les limites de nouvelles tentatives peuvent entraîner des pertes [35]. On le dimensionne et on le surveille comme n'importe quel service.
4. Avec l'Operator, l'ordre compte. L'instrumentation automatique exige que sa ressource de configuration existe avant le pod, que l'annotation soit au bon endroit et qu'il y ait un redémarrage ; en outre, elle écrase des variables comme JAVA_TOOL_OPTIONS [34].

Un avertissement sur Promtail. C'est l'agent de logs que de nombreuses équipes ont installé il y a des années pour Loki. Grafana a déclaré sa fin de vie le 2 mars 2026 : il ne reçoit plus de mises à jour ni de support commercial, et il est recommandé de migrer vers Alloy, avec un outil de conversion [22]. Celui qui l'a encore en production fonctionne sans le soutien de l'éditeur.

Un agent qui lit le log, ou instrumenter l'application ?

C'est la décision la plus pratique de tout le sujet, et elle est mal posée lorsqu'on la présente comme « l'ancien contre le moderne ». Ce sont deux chemins aux avantages différents.

• Un agent qui lit est un programme qui prend ce que le logiciel écrit déjà —sur la sortie standard ou dans un fichier— et l'achemine vers le système de stockage. Il n'exige pas de modifier le logiciel. En contrepartie, il faut interpréter (analyser) des lignes de formats divers, et il ne peut pas inventer un trace_id que l'application n'a pas écrit [32][40]. OpenTelemetry décrit les deux voies —lire des fichiers ou la sortie standard, ou envoyer directement en OTLP— et résume le compromis ainsi : la première ne demande aucun changement mais exige une analyse robuste ; la seconde évite la complexité des fichiers mais demande une configuration dans l'application [39].
• Instrumenter de l'intérieur consiste à utiliser le SDK d'OpenTelemetry ou un appender —un adaptateur qui relie le système de logs que le framework utilise déjà, comme Logback ou Log4j en Java, à OpenTelemetry— pour que chaque enregistrement sorte avec son contexte de trace et des données structurées [38]. OpenTelemetry ne remplace pas ces bibliothèques de logs : il s'y raccorde [38]. En contrepartie, il faut modifier et déployer du code.

La réponse mature est souvent hybride, avec une condition : ne pas dupliquer. Si l'application exporte un événement par son appender et que ce même événement est en plus relu depuis le fichier, le stockage reçoit deux copies. Chaque flux se déclare pour un chemin ou pour l'autre.

Une note sur l'« instrumentation automatique ». En Java, l'agent d'OpenTelemetry s'attache au démarrage (-javaagent) et injecte du code à l'exécution pour capturer la télémétrie des bibliothèques courantes : les appels HTTP entrants et sortants, la base de données [37]. Il donne une visibilité rapide sans modifier le code source. Mais il couvre les bords techniques, pas la logique métier : la documentation est explicite sur le fait que le code propre de l'application n'est normalement pas instrumenté tout seul [36]. Une décision comme « approbation de crédit » ou « affectation de stock » n'apparaît dans la trace que si quelqu'un l'a marquée dans le code. Ce que procure l'instrumentation automatique, c'est un bon point de départ, non la fin du travail.

Que surveiller dans chaque secteur

Ce sont des scénarios illustratifs, sans clients ni chiffres mesurés. Chacun parcourt la même chaîne : métrique qui avertit, trace qui circonscrit le parcours, log qui apporte le détail.

Banque : virements et autorisations. On surveille, dans les métriques, le temps de réponse de 95 % des virements et le taux d'erreurs d'autorisation. Lorsqu'il augmente, l'exemplar ouvre la trace d'un virement lent ; la trace montre que le temps est passé dans la requête au système central, et le log du même trace_id indique que le délai d'attente du pool de connexions a été dépassé. Avec cette chaîne montée et testée, savoir où et pourquoi ne dépend plus de réunir cinq équipes ; le temps que cela prend dépend de la configuration du croisement telle que décrite plus haut. Avertissement : ces métriques servent à l'exploitation, non à effectuer un rapprochement [9].

Fintech : API ouvertes. Un partenaire qui consomme ses API signale que les paiements échouent « parfois ». Sans télémétrie, c'est une anecdote. Avec des traces, on peut chercher uniquement les opérations en échec de cette route et voir si elles coïncident avec la lenteur d'une requête antifraude externe. On surveille aussi le taux d'erreurs par partenaire, les rejets pour dépassement de limite de requêtes et la latence des notifications (webhooks). On sépare ainsi « notre système a échoué » de « un tiers s'est dégradé », preuves à l'appui.

Assurance : tarification et émission. Une tarification prend 40 secondes à l'heure de pointe. La trace révèle que chaque tarification interroge en série trois systèmes de tarifs, et la métrique d'erreurs montre que l'un d'eux se dégrade à midi. On décide de paralléliser ou de mettre un cache, non d'« acheter plus de serveurs ». À l'émission, on mesure le temps de bout en bout et l'endroit où les files s'accumulent.

Retail : checkout et stock. Pendant une promotion, le panier « reste en réflexion ». Les métriques montrent une saturation du service de stock ; la trace révèle que chaque consultation d'un produit l'interroge douze fois. On corrige la cause, non le symptôme. Et ici apparaît un coût concret : si l'on étiquette les métriques par produit ou par client, la cardinalité explose (voir plus bas).

Entreprise réglementée : facturation. Un auditeur demande ce qui s'est passé avec une demande de facturation mardi. Avec l'identifiant de trace, on reconstitue le parcours à travers tous les systèmes, et dans les logs associés on voit ce qui a été fait et quand. Avec une réserve : la télémétrie aide à comprendre le comportement technique, mais elle ne remplace pas un registre d'audit formel, intègre et avec la rétention approuvée. Les traces sont échantillonnées et conservées peu de temps ; cela se décide avec les équipes Risque, Confidentialité et Juridique, non par une configuration technique.

Coûts et risques : ce qu'on dit rarement

Dans de nombreux cas, le coût pertinent provient du volume, de la cardinalité, de la rétention, du calcul des requêtes et de l'exploitation ; le poids de chaque poste dépend de la plateforme et du contrat. Trois décisions pèsent particulièrement.

Cardinalité : chaque nouvelle étiquette est une facture

La cardinalité est le nombre de combinaisons distinctes d'étiquettes. Dans Prometheus, chaque nouvelle combinaison est une nouvelle série qui consomme de la mémoire, du disque et du calcul. Le guide du projet recommande de maintenir la cardinalité de chaque métrique sous 10 et, si elle dépasse environ 100 ou peut croître sans limite, de chercher une autre solution ; son exemple est clair : 10 000 nœuds avec des dizaines de systèmes de fichiers donnent environ 100 000 séries, acceptable, mais ajouter un quota par utilisateur en produit des millions [10]. On n'utilise pas non plus d'étiquettes pour des identifiants d'utilisateur ou des adresses e-mail [11]. Ces chiffres sont un guide de bonnes pratiques du projet, non une limite technique stricte.

Loki a sa propre version : des étiquettes à valeurs illimitées obligent à construire un index énorme et des milliers de minuscules blocs, et les performances du système se dégradent fortement. Le guide de Grafana —chiffre de fournisseur— suggère de ne pas dépasser 10 à 15 étiquettes et de déplacer les identifiants vers le contenu ou les métadonnées structurées [14].

Traduit en termes métier : dans la promotion de fin d'année du scénario retail, si chaque client est une étiquette, la facture et la lenteur augmentent précisément quand on a le plus besoin du système.

Données personnelles : ce qui n'est pas émis ne fuit pas

Les logs et les traces ont la mauvaise habitude de capturer trop. Un service qui, par erreur, écrit le nom complet et la pièce d'identité de la personne qui téléverse un fichier laisse ce texte dans le stockage, avec sa rétention, à disposition de qui a accès au tableau de bord. OpenTelemetry est clair : il ne peut pas savoir ce qui est sensible dans votre contexte, la responsabilité réglementaire revient à qui met en œuvre, et éviter d'émettre la donnée vaut mieux que la corriger ensuite ; il avertit même qu'appliquer un hash à un identifiant peut ne pas donner d'anonymat lorsque l'univers de valeurs est petit [42].

Le Collector offre des processeurs pour supprimer ou transformer des attributs, mais il convient d'évaluer leur maturité : pour les logs, redaction et filter figurent en alpha et transform en bêta [43]. Appuyer toute la protection sur un composant alpha est fragile. La pratique prudente comporte deux barrières : ne pas émettre la donnée depuis l'application et, en seconde ligne, filtrer dans le Collector. Au Mexique, la Loi fédérale de protection des données personnelles détenues par les particuliers en vigueur (publiée au Journal officiel le 20 mars 2025, qui a abrogé celle de 2010) a pour objet de réguler un traitement légitime, contrôlé et informé, et oblige le responsable à maintenir des mesures de sécurité administratives, techniques et physiques [45] ; ce qui est conservé et pendant combien de temps se valide avec les équipes Confidentialité et Juridique.

Rétention et disque : personne ne la décide à votre place

Kubernetes ne conserve pas les logs à long terme, et Docker, par défaut, peut remplir le disque [27][28]. La rétention à long terme est une décision du stockage et du métier, et elle doit distinguer métriques, logs, traces et preuves réglementaires. Nous n'incluons ni chiffres de rétention ni prix, car ils dépendent du fournisseur et du contrat ; tout chiffre cité sans ces données est une supposition.

Qui voit quoi, et qui l'exploite. Les tableaux de bord de Grafana montrent ce que contiennent les logs et les traces, de sorte que l'accès se conçoit par domaine : chaque équipe voit les tableaux de bord et les sources qui la concernent, et celles et ceux qui consultent des logs contenant des données personnelles forment un groupe plus restreint que ceux qui regardent un graphique de latence. Et exploiter cet ensemble d'outils requiert au moins une personne qui comprenne les requêtes (PromQL, LogQL, TraceQL) et le Collector ; c'est un coût humain, pas seulement d'infrastructure, qu'il convient de compter dès le départ.

À cela s'ajoute l'échantillonnage : conserver toutes les traces coûte cher, et n'en conserver que certaines oblige à décider lesquelles, par exemple toutes celles qui échouent et une fraction de celles qui vont bien. Avec un échantillonnage réalisé dans la gateway, le routage doit envoyer tous les spans d'une même trace vers le même collecteur [8]. Et une note sur la livraison du protocole : face à des pannes transitoires, une implémentation peut réessayer l'envoi ; sans accusé de réception, cela peut produire des doublons. Le stockage et les requêtes doivent donc les tolérer, sans supposer une livraison garantie [4].

Comment commencer sans vouloir tout faire

1. Choisissez un flux métier critique, pas « tout le système ». Un virement, un devis, un checkout, une facture. S'il échoue, cela fait mal ; c'est pourquoi on l'instrumente en premier.
2. Définissez à l'avance les trois ou quatre questions auxquelles vous voulez pouvoir répondre et le signal qui y répond : que mesure la métrique, que marque la trace, que doit dire le log ?
3. Convenez des noms dès le début. Un nom de service et un environnement cohérents dans les trois signaux valent plus que n'importe quel tableau de bord [46].
4. Commencez par ce qui ne demande pas de toucher au logiciel. Un agent qui lit la sortie standard et, en Java, l'instrumentation automatique donnent une première vue en peu de temps [36][37].
5. Instrumentez de l'intérieur ce qui compte pour le métier : les étapes de ce flux, avec le trace_id dans chaque ligne de log.
6. Fixez des règles de cardinalité et de données personnelles avant d'ouvrir le robinet : liste des attributs autorisés, quelles données ne sont pas émises et qui décide de la rétention.
7. Testez le croisement de bout en bout : du clic sur le graphique à la trace et de la trace au log. Si un saut échoue, c'est là que l'on apprend ce qui manquait, et non lors d'un incident réel.
8. Retirez ce qui n'est plus pris en charge. Si vous avez Promtail, planifiez la migration [22].

Avant de commencer, il convient d'accorder par écrit, pour le premier flux : le flux retenu, son responsable, la ligne de base et l'objectif de latence et d'erreur, la couverture minimale de traces, les attributs interdits, la rétention, le budget mensuel et le test de corrélation de la métrique vers la trace et vers le log.

Savoir quel outil existe est la partie facile. Le plus difficile est de savoir quelle partie de votre plateforme émet déjà ce qu'il faut, ce que l'on peut observer sans toucher au logiciel et ce qui requiert de l'instrumentation, où des données personnelles se glissent aujourd'hui dans les logs et quel coût entraîne chaque décision. C'est ce que nous examinons lors d'un diagnostic : nous vous remettons une carte des signaux de vos flux critiques, le tableau de ce qui est couvert par un agent et de ce qui requiert de l'instrumentation, l'inventaire des données personnelles qui arrivent aujourd'hui dans les logs, les facteurs de coût qui pèsent le plus dans votre cas et l'ordre recommandé pour l'adopter, afin que les équipes IT, sécurité, risque et métier décident avec la même information.