Les équipes qui exploitent Kubernetes ont besoin de davantage que de tableaux affichant la consommation du processeur et de la mémoire ainsi que les taux d’erreur. La complexité des environnements cloud natifs fait qu’une seule requête peut passer par une passerelle d’entrée, des services, des files d’attente, du stockage et des processus en arrière-plan, tandis que les charges de travail se déplacent et que les versions changent en permanence. Ainsi, un déploiement peut sembler sain au niveau du Deployment, alors qu’une dépendance en aval, une boucle de nouvelle tentative ou une pression sur un chemin du plan de contrôle provoque une hausse de la latence.
Dans un article publié sur le blog de la CNCF, Neel Shah, de Stackgen, explique que la surveillance traditionnelle répond à des questions prédéfinies, telles que : l’utilisation du processeur a-t-elle dépassé un certain seuil ? Les erreurs sont-elles en hausse ? Selon l’approche présentée dans l’article, l’observabilité vise plutôt à aider l’équipe à enquêter sur un problème auquel elle ne s’attendait pas et à passer de l’observation du symptôme à la compréhension de la cause et de l’étendue.
Les métriques ouvrent l’enquête, mais n’y mettent pas fin
Les métriques restent le point de départ naturel, car elles sont numériques, efficaces à stocker et à interroger, et adaptées aux alertes et à l’analyse des tendances. Dans Kubernetes, elles peuvent montrer la pression exercée sur les nœuds, les redémarrages de conteneurs, l’augmentation de la latence des requêtes, le ralentissement du serveur d’API ou l’accumulation d’éléments dans les files d’attente.
L’article propose de s’appuyer sur le modèle RED pour les services, c’est-à-dire le taux de requêtes, les erreurs et la durée, ainsi que sur le modèle USE pour l’infrastructure, c’est-à-dire l’utilisation, la saturation et les erreurs. Ces indicateurs aident à établir le tableau initial de l’incident : une hausse du taux de requêtes avec une latence stable diffère d’une augmentation de la durée et de la saturation avec un trafic constant.
Mais transformer chaque détail en étiquette dans une métrique crée un problème de cardinalité, car le grand nombre de combinaisons uniques augmente les coûts et ralentit les requêtes. L’article met notamment en garde contre l’inclusion des identifiants de requêtes ou d’utilisateurs, ou de valeurs quasi uniques, dans les métriques ; ces détails conviennent davantage aux journaux ou aux traces distribuées.
Chaque signal répond à une question différente
Les journaux ajoutent le contexte local que les graphiques ne conservent généralement pas. Lorsqu’ils sont structurés et utilisent des champs cohérents tels que l’heure, le niveau de gravité, le nom du service, l’espace de noms, l’identité du conteneur, le chemin de la requête et le contexte de traçage, il devient plus facile de relier un événement précis au service ou au processus qui l’a produit. Une métrique peut indiquer que le service de paiement est affecté, tandis que le journal révèle l’expiration d’un délai, une exception ou l’échec d’une dépendance.
Les traces distribuées répondent à une autre question : comment une requête donnée s’est-elle déplacée dans le système et où le temps a-t-il été consommé ? Elles sont particulièrement importantes dans Kubernetes, car la panne peut être répartie entre plusieurs services, des tentatives répétées, des limites de files d’attente ou des appels à une base de données. La transmission du contexte de traçage permet de relier les différents segments dans le contexte d’une même requête, tandis que des conventions sémantiques communes contribuent à uniformiser les noms de champs et les attributs entre les métriques, les journaux et les traces.
L’article intègre également le profilage à cette vue d’ensemble. Une fois que les métriques ont identifié le service lent, que la trace a identifié le chemin de requête affecté et que les journaux ont clarifié l’événement local, les données de profilage peuvent aider à déterminer la fonction ou le chemin de code qui consomme le processeur ou la mémoire.
Qu’est-ce qui change concrètement pendant l’incident ?
L’article présente l’exemple d’un service checkout qui, après une nouvelle mise en production, commence à dépasser son objectif de latence, alors que les indicateurs du processeur et de la mémoire restent normaux. Les métriques révèlent l’existence du problème, puis une trace d’une requête lente montre que la majeure partie du délai se situe à l’étape d’autorisation du paiement. Les journaux affichent ensuite des messages répétés d’expiration de délai associés au même contexte de requête.
Cette séquence fait passer l’équipe d’une question générale — pourquoi le service de paiement est-il devenu lent ? — à des options opérationnelles plus précises, comme revenir sur une modification d’une dépendance, réduire l’amplification des nouvelles tentatives ou détourner temporairement le trafic pendant l’enquête. L’article souligne également que la meilleure alerte est celle qui reflète un risque pour la qualité du service ou son objectif de fiabilité, et non une simple anomalie brute des ressources de l’infrastructure ; il donne l’exemple d’une alerte liée à une hausse de la valeur p99 de la latence des réponses au-dessus d’une seconde pendant dix minutes.
Des règles de conception applicables
- Commencer par les métriques et les journaux disponibles, puis élargir progressivement la couverture au lieu de tout collecter sans objectif.
- Privilégier les dimensions liées au service et à la charge de travail plutôt que les étiquettes à très forte unicité dans les métriques.
- Utiliser une structure de métadonnées cohérente entre les métriques, les journaux et les traces distribuées.
- Ajouter les identifiants de requête ou de traçage aux journaux afin de faciliter le passage d’un signal à l’autre.
- Construire les alertes autour des risques de fiabilité et de la qualité du service, et pas uniquement autour de la pression exercée sur les ressources.
- Considérer l’observabilité comme une composante de la conception de l’application et de la plateforme, et non comme un ajout ultérieur après la mise en production.
Lecture éditoriale de certi.news : la valeur fondamentale ici ne réside pas dans l’appel à acheter un outil ou à adopter une implémentation unique, mais dans la redéfinition de l’objectif de l’observabilité. Ce qui change réellement, c’est la manière d’utiliser les données : la métrique capture l’écart, la trace détermine le chemin, le journal explique l’événement et le profilage peut identifier la cause au niveau du code. Des limites pratiques évidentes subsistent toutefois ; collecter davantage de signaux ne garantit pas une meilleure compréhension, tout comme l’absence de noms et de champs normalisés peut rendre les corrélations fragiles, tandis que les détails uniques peuvent augmenter le coût des métriques et dégrader les performances des requêtes. L’utilité dépend donc de la qualité de la conception et de la corrélation entre les signaux, et non du nombre de tableaux de bord.