Observabilité Kubernetes : métriques, journaux, traces

Publié le

14 juil. 2026

Mis à jour le

15 juil. 2026

Temps de lecture

16 min de lecture

L'observabilité Kubernetes n'est pas une collection de tableaux de bord pour chaque ressource. C'est la capacité à expliquer le comportement d'un service à travers le client, le chemin de livraison, l'ingress, la charge de travail, le cluster et les dépendances. Un redémarrage de pod, un signal CPU élevé ou une sonde de disponibilité en échec peuvent être des éléments utiles, mais les clients perçoivent une requête terminée, une page retardée, un appel API en échec ou un résultat asynchrone manquant.

Cette chaîne de preuves compte le plus à l'échelle où opère une couche d'orchestration d'edge managée : Optimi se place devant les origines de ses clients à travers plusieurs fournisseurs de livraison, où un signal de cluster inexpliqué est un trou dans la preuve. L'observabilité Kubernetes ne mérite vraiment son nom que lorsque la télémétrie du cluster rejoint, requête par requête, ce qui s'est passé en périphérie, en reliant métriques, logs et traces dans une seule chronologie exploitable.

Commencez par le chemin de diagnostic. Lorsqu'une alerte se déclenche, l'ingénieur d'astreinte doit pouvoir déterminer le service et la région affectés, corréler une requête avec une trace et un événement de journal, comparer la publication actuelle à la précédente et examiner les conditions de plateforme qui l'entourent sans chercher dans des systèmes sans rapport.

L'observabilité Kubernetes en pratique : le scénario de paiement d'Acme Shop

Acme Shop reçoit un signalement indiquant que le paiement en zone UE est lent après une publication canary. L'équipe a besoin d'une vue unique, au niveau de la route, qui relie le résultat côté edge, la durée d'ingress, la publication de checkout-api, le temps d'attente du pool de base de données et un ID de trace assaini — sans jamais placer d'identifiant client, d'adresse e-mail, d'en-tête d'autorisation ou de corps de requête dans un label de métrique ou un attribut de trace.

Ce scénario relie cinq couches : edge et ingress pour la route, la région et le contexte de trace W3C ; checkout-api pour les métriques bornées, les journaux structurés et les spans ; les dépendances — pool de base de données, appel de paiement — tracées sans identifiants ni charges utiles ; le Collector pour les limites de ressources, l'authentification et la rétention ; et une vue d'incident qui combine tableau de bord, trace, journaux et événement de déploiement pour établir le périmètre de l'impact.

Définir un contrat de télémétrie

Publiez un contrat concis partagé par les équipes applicatives et plateforme. Définissez au minimum le nom du service, le namespace, le cluster, l'environnement, la région, la version de déploiement, le modèle de route de requête, la classe de statut de réponse, l'ID de trace et un ID de requête ou de corrélation sûr. Appliquez des règles de classification des données à chaque signal : ne placez ni identifiants, ni identifiants de session, ni en-têtes d'autorisation bruts, ni données personnelles inutiles dans les labels, les journaux ou les attributs de trace.

Maintenez une cardinalité de métriques bornée. L'ID utilisateur, l'adresse e-mail, l'URL complète, un ID de requête aléatoire, l'ID de conteneur et une chaîne de requête non bornée sont généralement des labels de métriques dangereux. Placez plutôt les détails de diagnostic dans des traces échantillonnées ou des journaux structurés. Un système de supervision surchargé par des labels à forte cardinalité est le moins fiable pendant l'incident où il est le plus nécessaire.

Chez Acme Shop, chaque signal inclut le nom du service, le namespace, l'environnement, la région et la version de publication, que la plateforme attache elle-même plutôt que de faire confiance à chaque service. Les conventions sémantiques Kubernetes d'OpenTelemetry définissent ces attributs de ressource, que le processeur d'attributs Kubernetes du Collector résout et attache automatiquement — par défaut via l'IP source de la connexion, un choix fragile derrière un sidecar de maillage de services. Les Collectors de production épinglent plutôt l'association à l'UID du pod, un attribut que le SDK applicatif définit lui-même.

Instrumenter quatre couches utiles

Application et ingress

Mesurez le débit de requêtes, les résultats d'erreur, les distributions de durée, la concurrence, le temps d'attente en file et les appels aux dépendances. Instrumentez une seule fois la limite HTTP ou RPC et utilisez des modèles de route plutôt que des chemins bruts. À l'ingress, capturez l'hôte, la route, la classe de réponse amont, la durée de requête et un identifiant pouvant joindre la télémétrie applicative. Comparez le timing de l'ingress à celui de l'application pour révéler les délais de mise en file, de proxy, TLS ou de réseau.

Charges de travail et nœuds Kubernetes

Collectez la disponibilité des déploiements, le nombre de réplicas souhaités par rapport aux réplicas prêts, les événements de cycle de vie des pods, les raisons de redémarrage, les demandes et limites de ressources, la limitation CPU, le jeu de travail mémoire, la latence de planification, la pression sur les nœuds et les symptômes réseau ou de stockage. Ces métriques expliquent les contraintes ; elles ne doivent pas être utilisées seules pour affirmer un impact utilisateur.

Journaux et événements

Utilisez des journaux structurés avec horodatage, niveau, identité du service, version de publication, ID de trace et résultat propre à l'événement. Les événements Kubernetes peuvent aider à expliquer les échecs de récupération d'image, de planification, les évictions et les actions de l'autoscaler, mais leurs caractéristiques de rétention et d'agrégation varient. Exportez les événements nécessaires aux opérations et testez que l'export reste disponible sous contrainte du plan de contrôle.

Traces distribuées

Propagez le contexte de trace depuis la première limite de requête contrôlée à travers les appels applicatifs, les files d'attente, les workers et les adaptateurs de services externes. L'échantillonnage nécessite une politique explicite. L'échantillonnage en queue ou sensible aux erreurs peut conserver les requêtes lentes et en échec tout en maîtrisant les coûts, mais le pipeline d'échantillonnage devient lui-même une dépendance qui nécessite de la capacité, une gestion de la contre-pression et des défaillances.

La politique d'échantillonnage est un compromis, pas un simple interrupteur. L'échantillonnage en tête décide avant de savoir si une trace a été lente ou a échoué, et peut donc écarter la requête qui comptait. L'échantillonnage en queue diffère cette décision : chaque span reste en mémoire jusqu'à la fin de la trace, puis elle est conservée ou supprimée selon une politique de latence ou d'erreur — au prix d'une mémoire qui peut épuiser le Collector plus vite que le réseau ne le ferait. Chez Acme Shop, cette mémoire reste bornée par une limite explicite, avec un repli automatique vers l'échantillonnage en tête plutôt que de laisser le Collector s'effondrer.

Utiliser OpenTelemetry de manière délibérée

OpenTelemetry fournit des API, SDK, conventions sémantiques et un Collector communs pour les pipelines de télémétrie. Utilisez-le pour éviter que chaque service dépende directement d'un unique backend de supervision, et non comme prétexte pour exporter tous les attributs possibles. Commencez par l'instrumentation automatique HTTP, d'exécution et de base de données lorsqu'elle est bien comprise, puis ajoutez des spans et attributs métier pour les opérations importantes.

Exécutez les Collectors avec des limites de ressources et une politique de perte documentée. Sous pression, décidez quelle télémétrie peut être échantillonnée ou supprimée et quels signaux doivent être préservés pour les alertes et l'audit. Protégez l'endpoint du collector, authentifiez les exporteurs et traitez la télémétrie comme des données de production : elle peut exposer la topologie, les comportements et un contexte sensible.

Ajouter la supervision de cluster sous les métriques, logs et traces corrélées

La trace de paiement d'Acme Shop explique une requête. La supervision de cluster explique ce que la plateforme faisait en dessous, et Kubernetes embarque trois outils plus étroits pour ce travail.

metrics-server agrège le CPU et la mémoire depuis chaque kubelet pour alimenter le HorizontalPodAutoscaler et kubectl top ; il ne conserve aucun historique, donc une fenêtre non surveillée pendant le canary est perdue.

kube-state-metrics observe le serveur API, pas les kubelets, et transforme l'état des objets — réplicas, conditions de nœud, redémarrages — en métriques qui confirment si le déploiement s'est bien comporté.

cAdvisor, exposé par le kubelet, rapporte des compteurs de CPU, de mémoire et de réseau par conteneur ; scrappé dans Prometheus, il devient la chronologie historique alignée sur les horodatages de trace.

Aucun de ces outils ne remplace la télémétrie corrélée décrite plus haut — ils répondent à « la plateforme était-elle saine », là où la trace répond à « cette requête était-elle saine ». Chez Acme Shop, les labels de kube-state-metrics restent volontairement étroits : chaque label optionnel multiplie la cardinalité comme le ferait un label HTTP non borné.

Construire les tableaux de bord à partir des questions de service

Chaque tableau de bord de service doit répondre à un ensemble limité de questions :

• Les requêtes valides réussissent-elles et se terminent-elles dans l'objectif de service ?
• Quelle route, région, classe de locataires ou publication contribue au changement ?
• Le délai se situe-t-il chez le client ou à la périphérie, dans l'ingress, la charge de travail, la file d'attente, le magasin de données ou une dépendance externe ?
• La capacité est-elle contrainte par les réplicas, la planification, les ressources de nœud, les pools de connexions ou un quota amont ?
• Quel événement de déploiement, de configuration, de trafic, DNS, de certificat ou de routage a coïncidé avec le changement ?

Créez des liens depuis les alertes vers un tableau de bord ciblé, des traces représentatives, les journaux pertinents, les runbooks et les déploiements récents. Testez ces liens avec une personne qui n'a pas construit le tableau de bord. Un tableau de bord qui nécessite une connaissance tribale pendant une panne n'est pas une interface fiable.

Une agrégation mondiale masque souvent la région ou la route en échec ; filtrez systématiquement les métriques synthétiques et applicatives par route et par région avant de déclarer un service sain.

Occasionnellement, la contrainte vient du plan de contrôle lui-même — webhook d'admission lent, contention de l'ordonnanceur, latence etcd — pendant que les tableaux de bord au niveau des pods restent silencieux. Depuis la version 1.22, le kube-apiserver peut exporter ses propres spans en OTLP derrière la feature gate alpha APIServerTracing, qu'Acme Shop n'active que lorsqu'aucune autre piste ne confirme la cause.

Observer le trafic public au-delà du cluster

La télémétrie du cluster commence trop tard pour une requête publique qui échoue au niveau du DNS, TLS, d'un pare-feu d'application web, d'une règle de périphérie ou d'un chemin réseau régional. Ajoutez des parcours synthétiques pour les chemins critiques depuis des emplacements sélectionnés et des mesures d'utilisateurs réels lorsque les pratiques de confidentialité et de consentement le permettent. Préservez une stratégie de corrélation entre la couche de livraison et l'origine afin que les opérateurs puissent comparer la réponse en périphérie, le timing amont, le statut de l'origine et l'état de publication.

Cela ne signifie pas qu'une moyenne mondiale unique de latence est pertinente. Segmentez selon la géographie des utilisateurs, la route, le type d'appareil ou de client lorsque cela est approprié, et la configuration de livraison. Une ressource publique rapide mise en cache ne prouve pas qu'une route applicative authentifiée est saine, et une réponse d'origine plus lente ne prouve pas qu'un fournisseur de livraison est en cause.

Tester le système d'observabilité

Menez des exercices de défaillance contrôlés : mauvaise publication, dépendance indisponible, problème de résolution DNS, pool de nœuds saturé, identifiant expiré, chemin d'ingress bloqué et panne du collector de télémétrie. Vérifiez que les alertes décrivent l'impact client, que les traces conservent des exemplaires utilisables, que les journaux peuvent être trouvés par ID de corrélation et que l'équipe d'incident dispose de l'accès. Réexaminez la rétention, les coûts et l'accès aux données après l'exercice.

Chez Acme Shop, cet exercice injecte un délai borné dans le pool de base de données d'un test de paiement jetable en bac à sable. L'équipe confirme que la trace conserve la requête lente, que le journal se retrouve par ID de trace, qu'aucun champ secret n'apparaît, et que l'échantillonnage en queue a bien conservé la trace retardée. Si le collector ou un canary ajoute une cardinalité excessive, elle arrête le canary et restaure la dernière révision validée ; si la télémétrie devient indisponible pendant un incident réel, elle déclare la lacune et répare le pipeline plutôt que de désactiver les protections de données.

Références officielles

• Kubernetes: Observability
• Kubernetes: Resource Metrics Pipeline
• OpenTelemetry: Kubernetes
• OpenTelemetry: Semantic Conventions
• OpenTelemetry Collector Contrib: processeur d'attributs Kubernetes
• OpenTelemetry: conventions sémantiques de ressource Kubernetes