Dans la partie 1, nous avons expliqué comment l'intégration Kubernetes d'Elastic transmet la télémétrie à Elasticsearch via EDOT Collector. Dans cet article, nous allons plus loin avec un serveur MCP App (Model Context Protocol) qui expose cette télémétrie sous forme d'outils pouvant être appelés par l'IA, avec des interfaces utilisateur React interactives qui s'affichent directement dans la conversation. Nous verrons également comment aller plus loin avec Elastic Workflows : des runbooks automatisés qui prennent en charge l'ensemble du processus d'analyse des causes profondes, de l'alerte à la proposition de remédiation.

Elastic Observability MCP App s'affiche là où vous travaillez

Elastic Observability MCP App (version préliminaire) propose six vues, une par outil. Chaque vue s'affiche directement dans la conversation lorsque l'outil renvoie un résultat et propose, sous forme de boutons cliquables, des suggestions ciblées pour l'étape suivante. Vous savez ainsi immédiatement comment poursuivre l'investigation. MCP Apps va plus loin que les workflows d'agents autonomes : ses vues interactives s'affichent en temps réel directement dans votre chat ou votre environnement de développement intégré (IDE), au fil de la conversation, sans avoir à basculer vers Kibana.

Récapitulatif de l'état de santé du cluster

Demandez « Qu'est-ce qui ne fonctionne pas ? » ou « Donnez-moi un rapport d'état » et obtenez une orientation unique : badge de santé globale, services dégradés avec raisons, principaux consommateurs de mémoire pod, répartition de la gravité des anomalies et débit du service — le tout en une seule vue en ligne.

La vue s’adapte en fonction de ce que votre déploiement prend en charge. L’APM vous offre la santé de vos services. Les indicateurs Kubernetes ajoutent le contexte du pod et du Node. Les tâches ML superposent les anomalies. Si un signal est absent, la vue vous indique ce qui manque au lieu de renvoyer une erreur. Commençons par un rapport d'état du cluster Kubernetes :

Les rapports composites, comme le récapitulatif de l'état de santé, présentent les données sous une forme condensée, avec la possibilité de développer les détails. Vous pouvez ainsi choisir le niveau d'information à afficher. Les actions d'investigation suggérées fournissent des indications sur les informations renvoyées et orientent également les utilisateurs vers d'autres outils à exécuter.

Graphe des dépendances des services

Demandez « qu’est-ce qui appelle checkout ? » ou « montrez-moi la topologie » et obtenez un graphe de dépendances en couches — appelants en amont, dépendances en aval, protocoles, volume d’appels et latence par arête. Survolez une arête pour mettre en évidence l’ensemble du chemin d’appel. Demandons à Claude de « me montrer les dépendances de service du frontend » :

Utilisez le zoom, le déplacement et le survol pour obtenir tous les détails nécessaires à la compréhension des relations complexes entre les services :

Détails de l’anomalie

Demandez « quelles sont les anomalies ? » ou « y a-t-il quelque chose d'inhabituel dans checkout ? ». Vous obtenez alors automatiquement l'une des deux vues disponibles. Si plusieurs entités sont affectées, le mode Aperçu affiche le nombre d'anomalies par niveau de gravité, les entités affectées et une répartition par tâche. Si l'analyse porte sur une seule entité, le mode détaillé affiche le score, les valeurs réelles par rapport aux valeurs habituelles dans une barre de comparaison, le pourcentage d'écart et, lorsqu'elle est disponible, une série temporelle. Examinons le service frontend :

Il ne s'agit pas d'une requête ES|QL : c'est une explication des résultats d'une tâche de détection des anomalies préalablement définie. Comme indiqué dans la première partie de cette série d'articles de blog, l'intégration Kubernetes en propose plusieurs que vous pouvez activer. Cet outil vous aidera à en tirer le meilleur parti.

Observe

Observe constitue le principal point d'accès de l'agent à Elastic — un seul outil, avec deux modes pour répondre à trois besoins différents. Demandez « quel est le débit réseau de chacun de mes clusters Kubernetes ? » pour obtenir les résultats sous forme de tableau ou de graphique. Demandez « préviens-moi lorsque la mémoire passe sous les 80 Mo » ou « surveille la mémoire du frontend pendant les 10 prochaines minutes pour détecter toute activité inhabituelle ». L'outil reste alors en attente jusqu'à ce que la condition se déclenche ou que la période définie arrive à son terme.

La vue s’adapte au mode : un tableau de résultats pour les requêtes ponctuelles, un graphique de tendance en temps réel avec statistiques actuelles/de pointe/de référence pour l’échantillonnage et les seuils, et une carte de déclenchement avec score de gravité pour le mode anomalie. Nous allons l'utiliser ici pour identifier le nœud Kubernetes le plus sollicité :

Évaluez les risques à l’aide d’un rayon d’impact

Demandez « que se passe-t-il si ce nœud tombe en panne ? » pour obtenir un diagramme radial de l'impact : le nœud cible apparaît au centre, les déploiements entièrement indisponibles en rouge, les déploiements dégradés en orange et ceux qui ne sont pas affectés en gris. Une carte de synthèse flottante affiche les pods à risque ainsi que les possibilités de replanification. Les déploiements à réplica unique sont signalés comme des points uniques de défaillance. Que se passerait-il si notre nœud le plus sollicité tombait en panne :

Gestion des alertes

L'outil de gestion des alertes vous permet de créer, de répertorier, de consulter et de supprimer des alertes. Nous allons maintenant créer une alerte. Mais commençons par utiliser à nouveau Observe pour établir rapidement une valeur de référence et nous assurer que l'alerte est pertinente :

Demandez « alerte-moi si la mémoire du frontend dépasse 75 Mo ». L'agent crée alors une règle d'alerte Kibana persistante, c'est-à-dire un objet enregistré qui continue de s'exécuter une fois la conversation terminée. La vue affiche une fiche de règle actualisée en temps réel : nom de la règle, condition, période, intervalle de vérification, filtre KQL et tags. Les boutons suggérant les étapes suivantes permettent de vérifier la règle, de surveiller la stabilisation de l'indicateur ou de consulter l'état de santé actuel du cluster. L'agent confirme ce qui a été créé et indique où le retrouver dans Kibana :

Architecture de l’application MCP

L'application se compose d'un serveur Node.js, de six outils accessibles au modèle associés à six ressources de vue à fichier unique, d'outils propres à l'application pour relancer les requêtes et d'un regroupement avec vite-plugin-singlefile. Les outils sont regroupés selon le backend de déploiement (Universal, dépendant d'APM, de K8s ou du ML). L'agent et l'utilisateur savent ainsi d'emblée quels outils sont adaptés à un déploiement donné, au lieu de découvrir leurs limitations au moment de leur exécution. Le dépôt comprend six compétences (Skills) sous forme de fichiers .zip distincts qui indiquent à l'agent quand et comment appeler chaque outil.

Le diagramme suivant présente les composants de l'application : l'hôte MCP (Claude Desktop, VS Code ou équivalent), qui héberge le grand modèle de langage (LLM) et les compétences Claude lui indiquant comment utiliser les outils ; le serveur MCP App, un processus Node.js unique qui expose le registre des outils, regroupe les vues de l'interface utilisateur React et gère toutes les communications avec Elastic ; et enfin, la Suite Elastic, dans laquelle Elasticsearch et Kibana font office de backends pour les données en temps réel et les alertes.

Le diagramme ci-dessous retrace le traitement d'une requête utilisateur : Claude consulte le fichier de compétence pertinent pour déterminer quel outil appeler et comment renseigner ses paramètres. Il appelle ensuite l'outil, qui déclenche des requêtes côté serveur dans Elasticsearch et Kibana. En retour, Claude reçoit un résumé textuel concis ainsi qu'une ressource d'interface utilisateur React qui s'affiche directement sous la forme d'un widget interactif.

De l’alerte à la cause première : workflows d’investigation

Les règles d'alerte vous signalent qu'un problème est survenu. Les modules de ML vous indiquent le schéma à l'origine du problème. Elastic Workflows exécute automatiquement le diagnostic dès qu'une alerte se déclenche.

Nous proposons un workflow d'investigation Kubernetes (version préliminaire) qui se déclenche à partir d'une alerte Kubernetes et fournit un récapitulatif structuré des causes profondes avant même que vous n'ayez ouvert le moindre tableau de bord. Le SRE qui reçoit la notification ouvre l'alerte et découvre que l'investigation a déjà été effectuée.

Le workflow est un graphe orienté d’étapes qui interroge plusieurs sources de données — principalement via le langage de requête d’Elasticsearch (ES|QL), avec une recherche Elasticsearch pour la recherche d’anomalies ML. Les étapes if créent des branches selon les résultats des requêtes, en choisissant quelle corroboration exécuter (anomalie de mémoire ML vs classification des logs) et s’il faut évaluer l’état de santé en amont (uniquement en présence de dépendances APM). Les étapes d’IA apparaissent à trois endroits : la classification des modèles de logs sur le chemin non-OOM, la classification de l’état en amont (dégradé vs sain), et une étape finale ai.summarize qui synthétise tous les éléments structurés en un récit de cause première.

À quoi ressemble le workflow d’investigation dans la pratique

L'exemple d'exécution ci-dessous repose sur OpenTelemetry Astronomy Shop avec Elastic : 16 services, Kafka et PostgreSQL, tous préinstrumentés via OTLP. En plus de la télémétrie réelle de l'application, nous avons injecté une cascade OOMKill synthétique, qui génère des signaux K8s et APM synthétiques dans le même espace de noms via les flux de données EDOT. Le workflow ne fait aucune distinction entre nos signaux et les signaux réels : il se contente d'analyser l'alerte.

Alerte déclenchée : CrashLoopBackOff — app-deployment dans oteldemo-esyox-default. Nombre de redémarrages : 6.

Étape 1 du workflow — Caractériser le contexte du pod et du conteneur

Le workflow interroge les indicateurs K8s pour connaître le nombre de redémarrages, la cause de la dernière interruption et l'utilisation des ressources par rapport aux limites déclarées.

Résultat : dernière cause d'interruption, OOMKilled ; nombre de redémarrages, 6. (Remarque : les données d'utilisation de kubeletstats n'étaient pas disponibles pour ce pod sur cette période. Le workflow poursuit néanmoins son exécution.)

Branches du workflow : La raison de l’arrêt est OOMKilled, le workflow emprunte donc le chemin d’investigation de la mémoire, et non celui d’investigation des logs.

Étape 2a du workflow — Consulter les résultats d’anomalies ML

Plutôt que de recalculer les tendances de mémoire, le workflow interroge l’index d’anomalies ML à la recherche d’une anomalie k8s_pod_memory_growth active.

Résultat : aucune anomalie — le pic est attribué à la charge et non à une fuite potentielle.

Étape 3 du workflow — Vérifier l’état de santé du service en amont

Le workflow énumère les dépendances en amont à partir des agrégats APM service_destination.1m, puis compare le taux d’erreur actuel et la latence moyenne à la même heure il y a 7 jours. Une étape de classification par l’IA détermine si une dégradation en amont a précédé l’alerte. Résultat : une dépendance en amont — api-gateway. Latence moyenne actuelle 15,13 ms, taux d’erreur 41,26 %. Niveau de référence (il y a 168 h) : identique. Classification : upstream_healthy — dans les seuils de 5× d’erreur / 3× de latence. L’amont est écarté.

Étape 4 du workflow : mettre en corrélation avec les modifications récentes de K8s

Le journal des événements de l'espace de noms révèle un cycle rapproché Pulled → Created → Started → Killing → BackOff, qui se répète environ toutes les 60 à 90 secondes. Aucun déploiement ni événement de mise à l'échelle au cours des deux dernières heures.

Sortie du workflow :

HYPOTHÈSE DE CAUSE PREMIÈRE (confiance : élevée)

app-deployment subit un arrêt OOMKill en raison d’une pression sur la mémoire. Le pod a redémarré
6 fois avec le motif d'arrêt OOMKilled. Le ML a signalé le pic de mémoire comme
piloté par la charge (aucune fuite). L’api-gateway en amont est saine actuellement par rapport aux 7 derniers jours
référence. Il s’agit d’un problème d’allocation de ressources — la mémoire du conteneur
la limite est trop basse pour son ensemble de travail réel.

Données probantes :
- 6 redémarrages, dernière raison d’interruption OOMKilled
- Aucune anomalie de croissance de la mémoire ML → leak_suspected=false (liée à la charge)
- api-gateway en amont inchangé par rapport à la référence sur 7 j (15,13 ms, 41,26 %) → sain
- Les événements K8s indiquent des cycles rapprochés Pulled/Created/Started/Killing/BackOff ;
  aucun déploiement au cours des 2 dernières heures

Cause probable : limite de mémoire insuffisante pour l’ensemble de travail réel sous charge.

Étapes suivantes recommandées :
1. Augmentez la limite de mémoire du déploiement de l’application en fonction de l’utilisation observée
2. Examinez le code de l’application pour identifier des opportunités d’optimisation de la mémoire
3. Envisagez une dégradation progressive sur les chemins d’accès à forte charge

Impact en aval : aucun identifié à partir des métriques de destination APM.

Voilà ce que vous obtenez lorsque vous ouvrez l'alerte : pas un lien vers une multitude de logs ou un tableau de bord, mais une réponse.

client.Le même workflow est accessible sous forme d'outil MCP depuis Claude Desktop, VS Code ou tout autre client compatible avec MCP. Lorsqu'un développeur demande « pourquoi checkout renvoie-t-il des erreurs ? » depuis son environnement de développement intégré (IDE), l'agent appelle le workflow et renvoie le même résultat structuré directement dans l'éditeur — mêmes éléments probants, même cause profonde, sans avoir à quitter l'éditeur.

Voici une démonstration animée de l'exécution du workflow :

Compétence Observability pour les investigations Kubernetes

Nous proposons également une compétence d’investigation unique et complète (observability-k8s-investigation) qui intègre le protocole de diagnostic complet pour les problèmes liés aux charges de travail, aux nœuds et au plan de commande de Kubernetes. Il s’agit d’une méthodologie d’investigation prescriptive qui inclut le raisonnement qu’un SRE expérimenté applique instinctivement, mais consigne rarement par écrit. Vous en bénéficierez en maintenant Kibana à jour, car cette fonctionnalité est intégrée à nos compétences d’agent IA. Cela commence par des principes directeurs qui empêchent les erreurs de diagnostic les plus courantes :

• L’absence de preuve n’est pas une preuve. Si les requêtes de logs renvoient zéro ligne, signalez no_logs_available — ne déduisez pas un mode de défaillance à partir de résultats vides.
• OOMKilled ne signifie pas par défaut une fuite de mémoire. Comparez l’utilisation actuelle à une base de référence de 7 jours avant de conclure à une fuite. La limite est peut-être simplement sous-dimensionnée.
• Les indicateurs moyens du processeur masquent la régulation. Un pod peut sembler sain avec une utilisation moyenne de 40–60 % tout en subissant une forte régulation au p99. Regardez le max et le p95, pas seulement la moyenne.
• Les co-symptômes ne sont pas des causes. Deux services qui se dégradent simultanément partagent généralement une cause en amont. N’attribuez de lien de causalité que lorsque la dégradation d’un service précède clairement celle de l’autre et que le delta est important.

La compétence (Skill) définit ensuite une taxonomie des modes de défaillance couvrant 16 scénarios de défaillance K8s distincts au niveau des workloads, des nœuds, du plan de contrôle, de la mise à l'échelle automatique et du réseau — d'OOMKilled et de la limitation CFS aux blocages des webhooks d'admission et aux situations de split-brain des StatefulSets. Chaque mode repose sur un signal déterminant permettant de l'identifier et sur une liste de vérifications permettant de le confirmer.

Le processus d'investigation suit une démarche structurée : orientation (identifier le pod, l'espace de noms et le déploiement cibles), caractérisation (obtenir le nombre de redémarrages, les causes d'interruption et l'utilisation des ressources), classification (établir une correspondance avec la taxonomie), corroboration (récupérer les événements, les logs et les données APM, puis les comparer aux valeurs de référence) et synthèse (formuler une hypothèse sur la cause profonde avec un niveau de confiance adapté – élevé, moyen ou faible –, accompagnée d'éléments probants explicites et des prochaines étapes recommandées).

Lorsque les éléments probants correspondent à deux modes de défaillance, la compétence les indique tous les deux et précise celui qu'elle considère comme la cause, ainsi que la raison. Lorsque les éléments probants sont ambigus, la compétence l'indique clairement. « Des hypothèses concurrentes constituent un résultat valide » est un principe de conception explicite — générer une fausse impression de certitude est considéré comme un mode de défaillance de l'investigation elle-même.

Premiers pas

Ces fonctionnalités s'appuient sur l'intégration Kubernetes décrite dans la première partie. Une fois vos tableaux de bord et la collecte des données opérationnels :

Étape 1 — Activez les workflows d’investigation (préversion technique). Importez le workflow Kubernetes Crashloop Investigation depuis la page Workflows dans Kibana, et configurez-le éventuellement pour qu’il se déclenche sur une règle d’alerte.

Étape 2 — Installer l’application MCP sur un client compatible MCP (version préliminaire technique). Le dépôt de l’application MCP pour Observability se trouve sur GitHub (consultez la page Releases pour les téléchargements). Lors de l’installation de l’application, n’oubliez pas d’installer et d’activer également les compétences incluses. Accédez aux outils de l’exemple d’application MCP depuis votre client d’agent favori — les instructions se trouvent dans le fichier README disponible via le lien GitHub ci-dessus.

Étape 3 — Exploitez la K8s Investigation Skill (préversion technique). C’est gratuit si vous utilisez Agent Builder, car cette fonctionnalité est intégrée à AI Agent Skills. La Skill apprend à l’agent quand et comment appeler les outils et workflows sous-jacents, garantissant ainsi des diagnostics cohérents dans des contextes conversationnels.

Prochaines étapes

Les workflows d'investigation diagnostiquent les problèmes qui affectent les services que vous surveillez. La question suivante est plus complexe : qu'en est-il des services que vous ne surveillez pas ?

Nous réfléchissons à une fonctionnalité intelligente de couverture basée sur la topologie — elle détecterait automatiquement chaque workload déployé dans votre cluster via l'API Kubernetes, recouperait ces informations avec la télémétrie envoyée à Elastic et mettrait en évidence les éventuelles lacunes de couverture. « Vous avez 47 services. 11 d'entre eux ne disposent d'aucune trace distribuée. Voici votre angle mort le plus à risque. » Cette fonctionnalité est à l'étude et fera probablement l'objet d'un prochain article.

En parallèle, nous étendons les workflows à la remédiation. L'objectif n'est plus seulement de diagnostiquer, mais aussi d'agir : créer un cas auquel est joint le récapitulatif de l'investigation, proposer un rollback soumis à validation humaine ou mettre un workload à l'échelle pour gagner du temps pendant la résolution de la cause profonde.

Si vous utilisez Kubernetes sur Elastic aujourd’hui, indiquez-nous quelles étapes d’investigation vous répétez manuellement pour chaque incident, quelles mesures correctives vous confieriez à un workflow, et quels outils MCP nous devrions développer ensuite. Vous pouvez rejoindre la discussion de la communauté Elastic ici.