Elasticsearch : la référence pour les logs, désormais aussi pour les métriques

Store high-cardinality metrics efficiently with time series data streams, and keep your Prometheus and PromQL workflows along for the ride. 

Dig into infrastructure and metrics monitoring. Start a free cloud trial or try Elastic on your local machine now.

Au cours des derniers mois, Elastic a mis à disposition dans Elasticsearch un moteur de stockage en colonnes spécialement conçu pour les données temporelles, l’ingestion et le stockage natifs de Prometheus, la prise en charge de PromQL, et nous avons proposé une nouvelle expérience d’exploration des métriques, des tableaux de bord d’infrastructure prédéfinis, l’investigation agentique ainsi qu’un parcours de migration depuis Datadog et Grafana. Les fonctionnalités incluent désormais :

• 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.

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

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.