• Elasticsearch est un back-end de métriques compatible avec Prometheus — Prometheus Remote Write et PromQL fonctionne désormais nativement dans Kibana, aucune couche de traduction n’est requise.

• Les métriques arrivent dans l’architecture TSDS en colonnes d’Elasticsearch stockant les données jusqu’à 2,5 fois plus efficacement que Prometheus et 2 fois plus efficacement que ClickHouse.

• Les requêtes de séries temporelles ES|QL s’exécutent jusqu’à 30 fois plus rapidement que Prometheus sur les moyennes de jauges et les taux de compteurs, y compris les charges de travail à forte cardinalité.

• Elastic coûte environ 50 % moins cher que Datadog, sans classification des métriques personnalisées et sans facturation basée sur la cardinalité.

• Grafana peut interroger Elasticsearch directement via l’API native de Prometheus, en conservant votre couche de visualisation tout en remplaçant le back-end.

• Kubernetes et le monitoring AWS sont fournis avec des tableaux de bord prédéfinis, des modèles d’alertes, des tâches d’anomalie ML et du contenu d’investigation basé sur les agents, prêts dès l’ingestion. En outre, des compétences et des applications MCP sont disponibles.

• Back-end unifié pour les métriques, logs et traces, permettant des investigations agentiques sans assembler le contexte entre les outils.

• L’exploration des métriques dans Discover permet à chacun de commencer à interroger et à analyser des métriques immédiatement, sans qu’aucune expertise en langage de requête ne soit requise.

• La personnalisation des tableaux de bord est rapide et flexible — tableaux de bord en tant que code, création de tableaux de bord assistée par l’IA, contrôles de variables et panneaux réductibles permettent de consacrer moins de temps à la création et plus de temps aux investigations.

• Outils de migration pour aider à migrer facilement les tableaux de bord et les règles d’alerting / moniteurs depuis Datadog et Grafana.

Les métriques Elasticsearch sont désormais compétitives sur tous les plans importants pour les SRE : vous pouvez vous permettre de conserver chaque métrique à pleine résolution, les interroger jusqu’à 30 fois plus rapidement qu’avec Prometheus, payer 50 % de moins qu’avec Datadog, migrer facilement les tableaux de bord et les règles d’alerting depuis Grafana ou Datadog, et passer de l’alerte à la cause première sans avoir à reconstituer le contexte entre des outils déconnectés. La suite de cet article passe en revue chacun de ces éléments en détail.

Performances des métriques Elasticsearch : 30 fois plus rapides que Prometheus et Mimir

Datadog et Prometheus imposent le même compromis : abandonner les données à forte cardinalité ou voir les coûts s’envoler. Les SRE qui gèrent Kubernetes, AWS ou toute infrastructure à forte cardinalité connaissent bien la nature exacte de ce problème. Les étiquettes Kubernetes, les données éphémères des pods et les dimensions OTel granulaires qui comptent le plus lors d’un incident sont les premières à être sacrifiées lorsque les budgets se resserrent.

Elastic a repensé le stockage de données temporelles et le moteur de calcul ES|QL pour en faire un moteur de métriques entièrement en colonnes. L’ajout d’une nouvelle étiquette Kubernetes, d’un nouveau tag d’instance AWS ou d’une nouvelle dimension applicative ne surcharge pas le système ; cela engendre beaucoup moins de coûts que les systèmes qui indexent chaque étiquette. Les métriques OTel, Prometheus et définies par l’application arrivent toutes dans le même back-end en colonnes à pleine résolution, avec les logs, les traces et les métriques au sein d’un stockage unique. Aucune donnée n’est abandonnée, aucune rétention n’est raccourcie.

Elasticsearch stocke les métriques jusqu’à 2,5 fois plus efficacement que Prometheus (les résultats peuvent varier en raison de facteurs tels que le compactage), et 2 fois plus efficacement que ClickHouse. Les performances des requêtes via ES|QL sont jusqu’à 30 fois plus rapides que Prometheus sur les moyennes de jauge et les taux de compteur, y compris pour les charges de travail à forte cardinalité où les concurrents calent. L’article sur l’architecture explique comment TSDS est organisé et pourquoi la structure en colonnes produit ces résultats.

| | | | | | :------------------------: | :----------------: | :--------------: | :----------------: | | Dimension | vs. Prometheus | vs. Mimir | vs. ClickHouse | | Performances des requêtes (ES|QL) | Jusqu’à 30× plus rapide | Jusqu’à 30× plus rapide | Jusqu’à 8× plus rapide | | Efficacité du stockage | Jusqu’à 2,5× plus performant | Équivalent | 2× plus performant |

La principale différence architecturale réside dans le fait qu’Elasticsearch metrics ne maintient pas d’état en mémoire par série qui scale avec la cardinalité, de sorte que l’ajout de milliers de nouveaux labels de pods Kubernetes ou de dimensions OTel n’augmente pas la pression sur la mémoire.

Les métriques OTel, natives Prometheus et définies par l’application sont toutes stockées de la même manière en pleine résolution, interrogées rapidement, pour la moitié du coût de Datadog.

Tarification des métriques Elastic Observability sans les pénalités liées aux métriques personnalisées de Datadog

Le coût de l’observabilité est la raison n° 1 pour laquelle les équipes changent de plateforme. Pour les clients de Datadog, le problème se résume à un mécanisme de tarification : les métriques personnalisées. Toute valeur définie par l’utilisateur en dehors des intégrations intégrées de Datadog est classée comme métrique personnalisée et facturée à un tarif supérieur. Cela inclut les données à cardinalité élevée générées par défaut par Kubernetes, OpenTelemetry et les charges de travail cloud native. Plus votre instrumentation est granulaire, plus la facture augmente rapidement. Les équipes qui exploitent une infrastructure moderne atteignent rapidement ce plafond, et la réponse est prévisible : supprimer des données, réduire la rétention, perdre le contexte le plus important lorsqu'un incident survient.

Les métriques Elasticsearch suppriment cette classification. Chaque métrique est facturée au même tarif, sans pénalité par métrique, sans facturation basée sur la cardinalité, et sans agrégation forcée. Vous conservez chaque métrique en pleine résolution, sans facture surprise à la fin du mois. Et comme Elastic coûte 50 % du prix de Datadog, la discussion avec le service financier change : il ne s’agit plus de savoir quelles données vous avez dû abandonner pour respecter le budget, mais ce que vous avez découvert parce que vous avez tout conservé. C’est aussi la raison pour laquelle l’investigation par l’IA fonctionne. Contrairement à la stack LGTM fragmentée de Grafana, le contexte est déjà unifié lorsque l’alerte est déclenchée, et non assemblé manuellement à travers des outils déconnectés.

Prise en charge native de Prometheus et PromQL dans Elasticsearch

La plupart des équipes SRE n’exécutent pas de pipeline de télémétrie propre, dans un format unique. Prometheus est profondément intégré aux applications, services, plateformes et automatisations. Historiquement, la migration de back-ends de métriques impliquait de réécrire les requêtes, de recréer les tableaux de bord et de reformer les ingénieurs — un processus suffisamment contraignant pour que les équipes préfèrent rester sur des plateformes qui ne répondent plus à leurs besoins plutôt que d’entreprendre cette migration.

Les métriques Elasticsearch ont éliminé la majeure partie de ces frictions. Les métriques Prometheus arrivent via Prometheus Remote Write et arrivent dans le même stockage en colonnes sans modification sémantique, préservant ainsi une fidélité totale des métriques de bout en bout. Pointez-les vers Elasticsearch au lieu de Mimir, et les données circulent. Pas de couche de traduction, pas de modification des configurations de scrape existantes.

PromQL fonctionne désormais nativement dans Kibana, afin que les ingénieurs qui utilisent PromQL n’aient pas à changer leur façon de travailler. Les requêtes, tableaux de bord et règles d’alerte PromQL existants migrent directement vers Kibana. 

Les requêtes PromQL fonctionnent sans modification sur Elasticsearch

Si votre équipe écrit déjà en PromQL, rien n’a besoin de changer. Ces requêtes s’exécutent telles quelles sur Elasticsearch en tant que back-end — copiez, collez, et c’est parti.

Taux d’utilisation du processeur (au niveau du conteneur) Le taux de processeur par seconde pour l’ensemble des conteneurs, regroupé par pod. Utile pour repérer les pods qui sollicitent fortement le processeur lors d’un incident.

PROMQL sum by (pod) (rate(container_cpu_usage_seconds_total[5m]))

Jeu de travail de la mémoire (au niveau du conteneur) Mémoire actuellement utilisée par conteneur : la valeur qui importe pour le risque d’OOM, et non la mémoire totale allouée.

PROMQL sum by (container) (avg_over_time(container_memory_working_set_bytes[5m]))

Taux de requêtes HTTP (au niveau de l’application) Débit de requêtes par seconde groupé par instance. Un premier signal standard lors de l’analyse des pics de latence ou d’erreurs.

PROMQL sum by (instance) (rate(http_requests_total[5m]))

Les trois suivent la syntaxe PromQL standard. Si vous utilisez Elasticsearch comme back-end, elles s’exécutent sans modification. Pour obtenir la référence complète de la syntaxe et savoir ce qui est pris en charge, consultez la documentation sur la prise en charge de PromQL.

L’API native de Prometheus fait d’Elasticsearch un back-end entièrement compatible avec Prometheus. Toute interface frontale compatible avec Prometheus (y compris Grafana) peut interroger directement Elasticsearch, afin que les équipes souhaitant conserver Grafana comme couche de visualisation tout en centralisant leurs données sur Elasticsearch puissent le faire sans modifier les tableaux de bord ou les règles d’alerte existants.

Lorsque les SRE ont besoin d’aller plus loin que ce que permet PromQL, ES|QL fonctionne sur les métriques, les logs et les traces dans une seule interface. La commande TS prend en charge les spécificités des séries temporelles : taux de compteurs, moyennes de jauges, fonctions de fenêtrage et agrégations à plusieurs niveaux sur des dimensions à cardinalité élevée. La même requête qui extrait le taux d’un compteur de processeur peut être associée aux logs du même hôte et faire ressortir l’événement de déploiement qui a précédé le pic. Aucun changement d’outil, aucun nouveau langage de requête. Le langage de requête, les tableaux de bord, les règles d'alerte, la couche de visualisation, tout cela est repris. La seule chose qui change, c'est qu'Elasticsearch est l'unique back-end qui soutient tout.

Elastic Observability : tableaux de bord prêts à l’emploi, alertes et contenu d’infrastructure

La plupart des fournisseurs d’Observability vous obligent à tout construire de zéro. Elastic Observability a réduit ce besoin dans trois domaines :

Exploration des métriques dans Discover. La nouvelle expérience d’exploration des métriques d’Elasticsearch permet aux SRE d’explorer les métriques dans la même interface que celle utilisée pour les logs — sans changer d’onglet, ni dupliquer les requêtes. Connectez un pipeline OTel ou une configuration de scraping Prometheus, ouvrez Streams, et chaque métrique du flux de données s’affiche immédiatement sous la forme d’un graphique de série temporelle. Aucun tableau de bord à créer, aucune requête à écrire. C’est là que les équipes peuvent valider les données, repérer des tendances et commencer à créer des alertes et des SLO à partir d’une vue en direct de ce qui circule, puis les mettre en corrélation avec des logs, des traces et d’autres données indexées dans Elasticsearch.

Tableaux de bord. Les tableaux de bord Kibana bénéficient désormais de panneaux réductibles avec chargement différé, de sorte que les panneaux qui ne sont pas immédiatement visibles ne génèrent pas de requêtes tant qu’ils ne sont pas nécessaires, ainsi que de variables de contrôle ES|QL permettant aux SRE de manipuler des visualisations via des menus déroulants sans rédiger de nouvelles requêtes. Le Dashboards-as-code est également disponible, permettant de créer des définitions de tableaux de bord versionnées qui peuvent être basées sur des modèles, partagées et déployées par programmation dans l’ensemble des environnements.

Contenu d’infrastructure prêt à l’emploi.  Elastic propose deux nouvelles expériences d’infrastructure prêtes à l’emploi :

• La nouvelle intégration Kubernetes est fournie avec des tableaux de bord hiérarchiques, des modèles de règles d’alerte, des tâches de détection des anomalies ML, ainsi que le contexte et les invites nécessaires à l’analyse des causes premières assistée par l’IA — le tout préconfiguré et prêt dès que les données commencent à affluer. 

• La surveillance de l’infrastructure AWS suit le même modèle : le contenu prêt à l’emploi pour les principaux services AWS s’active lors de l’ingestion, afin que les équipes ne repartent pas de zéro chaque fois qu’un nouveau service ou compte est mis en ligne. La même approche s’étend aux bases de données et aux autres infrastructures essentielles : la plateforme arrive avec des choix préconfigurés, et non vierge.

Investigations agentiques sur l’ensemble de votre infrastructure avec Elastic Observability

Elasticsearch met en corrélation les métriques, les logs et les traces dans un seul back-end, de sorte que le contexte d'investigation soit rassemblé avant qu'un ingénieur ne soit alerté.

Le plus difficile, c'est à 2 h du matin. Une instance RDS atteignant ses limites de connexion, privant les services en amont. Un groupe Auto Scaling échouant aux contrôles d'intégrité pour une raison enfouie dans les logs d'application. Un redémarrage de pod se propageant en cascade à travers un espace de nom.

Dans une suite Grafana LGTM, vous ouvrez trois onglets avant d’avoir suffisamment de contexte pour formuler une hypothèse.

Dans Datadog, le contexte est unifié, mais l’IA est une boîte noire : pas de BYO-LLM, aucune option de résidence des données.

Dans Elastic, les métriques, les logs et les traces partagent un même back-end et un schéma commun. Le contexte d’investigation est donc déjà prêt lors du déclenchement de l’alerte : aucune corrélation manuelle entre les outils, aucune perte de contexte liée au passage d’un langage de requête à un autre. La détection des anomalies par ML s’exécute automatiquement sur les métriques d’infrastructure (Kubernetes, AWS, bases de données). L’investigation commence donc à partir d’une anomalie scorée comprenant des informations contextuelles sur ce qui est normal, ce qui a changé et le niveau de gravité de l’écart, et non pas d’un simple franchissement de seuil brut.

Lorsqu’une alerte se déclenche, le workflow d’investigation d’Elastic met en corrélation les signaux, rassemble le contexte de la cause première et propose les étapes suivantes recommandées avant que quiconque ne soit alerté. L’article sur l’observabilité Kubernetes agentique présente un exemple complet de bout en bout. Le guide pratique de dépannage EKS montre comment Agent Builder et MCP fonctionnent ensemble pour une boucle complète d’analyse de la cause première sur EC2, EKS et les services AWS associés.

En plus d'examiner les problèmes dans Elastic Observability, vous pouvez utiliser Claude, Cursor, VS Code ou votre outil préféré pour analyser les problèmes à l'aide des applications MCP et des compétences d'agent d'Elastic. L'application MCP Observability étend l'analyse là où votre équipe travaille déjà. Si votre équipe mène des investigations dans Claude, Cursor ou VS Code, les mêmes fonctionnalités d'investigation (cumul de l'état de l'infrastructure, graphe de dépendances de service, détails des anomalies, analyse du rayon d'impact) s'affichent sous la forme de vues interactives directement dans la conversation. Ni Grafana ni Datadog ne proposent cela.

• Application MCP Observability — Connecte Claude, Cursor, VS Code, ou tout outil compatible MCP directement à vos données Elasticsearch, afin que l’état de santé de l’infrastructure, les dépendances des services et le contexte des anomalies apparaissent sous forme de vues interactives au sein de la conversation, sans quitter l’outil de votre choix. Découvrez comment cela fonctionne avec Kubernetes.

• Agent Skills — Des compétences préconçues pour Kubernetes, AWS, et d’autres infrastructures de base permettent à n’importe quel agent — dans Elastic ou le vôtre — d’exécuter des investigations structurées sur vos données d’observabilité sans ingénierie de prompt personnalisée. Intégrez-les à Claude, Cursor, ou à votre propre pipeline d’agents, et elles fonctionnent immédiatement. Découvrez les compétences d’observabilité ou parcourez la bibliothèque de compétences sur GitHub.

Migrer depuis Datadog ou Grafana vers Elastic Observability

La raison la plus courante pour laquelle les équipes SRE ne changent pas de plateforme d’observabilité est la migration. Le transfert d’années de règles d’alerte, de centaines de tableaux de bord et de requêtes PromQL intégrées aux runbooks est une tâche opérationnelle colossale, et le coût pour assurer la maintenance de piles parallèles pendant cette opération augmente chaque jour.

L’Observability Migration Platform gère la traduction automatiquement. Pointez la CLI ou Claude/Cursor (avec les compétences d’agent d’Elastic) vers votre organisation Datadog ou votre instance Grafana, et l’outil convertit les tableaux de bord, les règles d’alerte et les requêtes PromQL pris en charge en sorties natives Kibana. L’outil vous permet de voir ce qui a été entièrement migré, ce qui nécessitait des ajustements, et ce que vous devez faire pour tout migrer. Vous migrez ce que vous avez déjà créé.

Côté ingestion, Prometheus Remote Write signifie que le pipeline ne nécessite aucune modification. Les configurations de scraping pointent vers Elasticsearch au lieu d’un autre back-end compatible avec Prometheus, et les données arrivent dans le même magasin en colonnes. Les workflows, requêtes et configurations d’alerte sont repris sans modification. Pour les équipes qui souhaitent conserver Grafana comme couche de visualisation pendant ou après la migration, l’API Prometheus native et la prise en charge de PromQL dans Kibana permettent d’effectuer la transition par phases plutôt que de basculer d’un seul coup.

Elasticsearch en tant que back-end pour Grafana

Pour les équipes qui ne sont pas prêtes à quitter Grafana, remplacer le back-end constitue une solution de migration à part entière, et il existe deux manières de procéder selon votre workflow.

Si votre équipe utilise actuellement Prometheus, la solution la plus simple est la source de données Prometheus de Grafana. Elasticsearch propose désormais une API native compatible avec Prometheus, vous permettant ainsi de pointer le plug-in Prometheus existant de Grafana directement vers Elasticsearch. Aucun sidecar, aucun adaptateur et aucune modification de pipeline ne sont requis. Les tableaux de bord PromQL, les règles d’alerte et les menus déroulants de variables existants fonctionnent sans modification, y compris l’explorateur Metrics Drilldown de Grafana. Ajoutez Elasticsearch comme cible remote_write dans votre configuration Prometheus, puis remplacez l’URL de la source de données. C’est l’ensemble de la migration pour la plupart des équipes. Consultez le guide de configuration de bout en bout.

Pour les équipes qui souhaitent aller plus loin et interroger simultanément des logs, des métriques et des traces à partir d’un éditeur de requêtes Grafana unique, le plug-in Grafana Elasticsearch officiel intègre désormais la prise en charge d’ES|QL. Cela permet la corrélation inter-signaux directement dans Grafana, Elasticsearch gérant les trois types de données dans un back-end en colonnes unifié. Découvrez comment le configurer.

Dans tous les cas, conservez Grafana, remplacez Mimir et Loki, et bénéficiez pleinement du stockage en colonnes et des performances d’interrogation d’Elasticsearch en dessous. Des années de travail opérationnel, préservées. La migration que les équipes repoussaient devient un simple remplacement du back-end.

Ce qui est en GA et ce qui est en préversion technique

| Capacité | Statut | | ----------------------------------------- | ------------ | | Moteur de métriques en colonnes (TSDS) | GA | | Prise en charge des séries temporelles par ES|QL | Disponibilité générale | | Prise en charge de PromQL dans Kibana | GA | | Ingestion Prometheus Remote Write | GA | | Expérience OOTB de l’infrastructure Kubernetes | GA | | Expérience prête à l’emploi pour l’infrastructure AWS | Aperçu technique | | Observability MCP App | Aperçu technique | | Compétences des agents | Préversion technique | | Observability Migration Platform | Préversion technique |

Les différents articles mis en lien tout au long de ce document abordent les spécificités de la disponibilité générale par rapport à la préversion ainsi que les limites connues.

Tout cela (le moteur de métriques colonnaire, PromQL natif, les investigations agentiques et les outils de migration) fonctionne dans les trois modes de déploiement d’Elastic : serverless, Elastic Cloud et autogéré. Datadog ne propose aucune option sur site ; Grafana Cloud limite ses fonctionnalités les plus utiles aux déploiements hébergés. Avec Elastic, vous choisissez où résident vos données.

Elastic Observability : réduire les coûts sans perdre de données

L'infrastructure cloud moderne a brisé le modèle d'observabilité reposant sur des outils distincts pour des signaux distincts. Le coût est réel : factures d'outils en doublon, corrélation manuelle lors des incidents, et données supprimées simplement pour respecter le budget.

Un seul back-end qui stocke efficacement chaque signal signifie que vous conservez ce dont vous avez besoin sans la facture qui l’accompagne habituellement. C’est un tout autre type de conversation à avoir avec l’équipe financière : non pas "nous avons dû supprimer des données pour respecter le budget", mais "voici ce que nous avons trouvé". L’IA dispose d’une vue d’ensemble, car il n’y en a qu’une seule, et la Platform offre suffisamment de contenu prédéfini pour être utile dès le premier jour, et non après des semaines de travail fastidieux sur les tableaux de bord.

C’est possible parce qu’Elasticsearch est conçu différemment des plateformes que vous remplacez probablement :

• Le stockage en colonnes des indicateurs permet de stocker très efficacement les données d'indicateurs en mode d'index TSDS. 

• La compatibilité native avec Prometheus permet d'utiliser les configurations de scraping, les requêtes PromQL et les tableaux de bord existants sans avoir à les réécrire.

• L'unification des indicateurs, des logs et des traces dans un même backend permet de rassembler le contexte d'investigation au moment de la requête, sans avoir à le reconstituer manuellement dans différents onglets.

• La recherche et l'analyse dans un même moteur – un index inversé pour les logs et un index en colonnes pour les indicateurs, tous deux interrogés avec ES|QL.

• Les investigations agentiques mettent en corrélation les signaux, font ressortir les anomalies et suggèrent des mesures de remédiation avant même l'envoi d'une notification.

• Serverless, Elastic Cloud ou autogéré – vous choisissez où résident vos données, une possibilité que Datadog n'offre pas.

La conversation sur les coûts avec le service financier porte sur ce que vous avez trouvé, et non sur ce que vous avez dépensé.

Pour commencer

• Démarrer un essai gratuit

• Documentation Elastic Observability

• Elastic Observability Labs

Questions fréquentes

Elasticsearch est-il désormais une plateforme de métriques prête pour la production ?

Oui. Depuis juin 2026, Elasticsearch intègre un moteur de stockage en colonnes reconstruit et spécialement conçu pour les données temporelles, l’ingestion native via Prometheus Remote Write, la prise en charge de PromQL dans Kibana, l’interrogation de données temporelles avec ES|QL, ainsi que des tableaux de bord d’infrastructure prêts à l’emploi pour Kubernetes et AWS. Le moteur de métriques en colonnes, la prise en charge des données temporelles par ES|QL, PromQL et l’ingestion via Prometheus sont tous disponibles en disponibilité générale dans Elastic Serverless et seront bientôt en disponibilité générale dans Elastic Cloud Hosted.

Comment le coût des métriques d’Elasticsearch se compare-t-il à celui de Datadog ?

Pour des charges de travail comparables en matière de métriques, Elastic Observability Serverless revient nettement moins cher que Datadog — dans des exemples illustratifs fondés sur les prix catalogue publiés, de plus de 50 % moins cher, et souvent plus près de deux tiers de moins. L’écart est structurel : Datadog facture principalement à l’hôte, puis ajoute des frais pour les métriques personnalisées et les conteneurs à mesure que l’instrumentation augmente. La différence de coût est la plus importante précisément pour les charges de travail que Datadog facture le plus : les environnements à haute cardinalité et fortement instrumentés, tels que Kubernetes et OTel.

Comment les performances d’Elasticsearch en matière de métriques se situent-elles par rapport à Prometheus et Grafana Mimir ?

Les requêtes ES|QL sur Elasticsearch s’exécutent jusqu’à 30 fois plus vite que Prometheus et Mimir sur les moyennes de jauges et les taux de compteurs, y compris sur les charges de travail à cardinalité élevée. Elasticsearch stocke les métriques OTel à 3,75 octets par point de données ; jusqu’à 2,5 fois plus efficacement que Prometheus et 2 fois plus efficacement que ClickHouse.

Les équipes peuvent-elles migrer de Datadog ou Grafana vers Elasticsearch sans devoir tout reconstruire ?

Oui. L’Observability Migration Platform d’Elastic convertit les tableaux de bord et les règles d’alerte Datadog et Grafana, et migre les requêtes PromQL telles quelles dans Kibana. Les équipes peuvent également conserver Grafana comme couche de visualisation tout en remplaçant le back-end par Elasticsearch, en tirant parti de la prise en charge native de l’API Prometheus et de PromQL dans Kibana.

En quoi Elasticsearch est-il différent de Grafana pour l’observabilité des métriques ?

Elasticsearch stocke les métriques, les logs et les traces dans un seul back-end unifié avec un seul langage de requête (ES|QL), tandis que la pile LGTM de Grafana répartit les métriques (Mimir/Prometheus) et les logs (Loki) entre des back-ends distincts nécessitant des langages de requête distincts. Elasticsearch propose également des capacités d’investigation agentique, qui comprennent AI Agent, Workflows, MCP App et les compétences des agents, soit un ensemble de capacités plus complet que celui de Grafana. 

Elasticsearch prend-il nativement en charge Prometheus et PromQL ?

Oui, de deux façons distinctes. Premièrement, Elasticsearch accepte les métriques Prometheus via Prometheus Remote Write et expose une API native compatible avec Prometheus, ce qui lui permet de servir de back-end pour n’importe quel front-end compatible avec Prometheus, y compris Grafana. Deuxièmement, Kibana prend en charge PromQL en mode natif, ce qui signifie que les requêtes, les tableaux de bord et les règles d’alerte existants s’exécutent directement dans Kibana, sans couche de traduction ni modification.

Quel contenu de monitoring de l’infrastructure est disponible prêt à l’emploi avec Elastic Observability ?

Elastic propose des tableaux de bord préconfigurés, des modèles d’alerte et des tâches ML de détection des anomalies dans le cadre de centaines d’intégrations d’infrastructure couvrant les hôtes, les conteneurs, les services cloud, les bases de données, les équipements réseau et bien plus encore. Pour Kubernetes et AWS en particulier, la plateforme inclut également du contenu d’investigation agentique, tel que des compétences d’agent et une application MCP Observability qui permet aux équipes de mener des investigations directement depuis Claude, Cursor ou VS Code. Tout cela est disponible dès l’ingestion, sans configuration requise.

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.