Observabilité Kubernetes : métriques, journaux, traces

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.

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.

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.

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.

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.

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.

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.

Références officielles

• Kubernetes: Observability
• Kubernetes: Resource Metrics Pipeline
• OpenTelemetry: Kubernetes
• OpenTelemetry: Semantic Conventions