• Elasticsearch 是兼容 Prometheus 的指标后端——Prometheus Remote Write 并且 PromQL 现可在 Kibana 中原生运行，无需转换层。

• 指标存入 Elasticsearch 的列式 TSDS 架构 存储数据的效率比 Prometheus 高出 2.5 倍 且比 ClickHouse 高出 2 倍。

• ES|QL 时间序列查询的运行速度比 Prometheus 最高快 30 倍 在测量平均值和计数器速率方面，包括高基数工作负载。

• Elastic 的成本比 Datadog 低约 50%，且没有自定义指标分类和基于基数的计费。

• Grafana 可以通过原生 Prometheus API直接查询 Elasticsearch，在替换后端的同时保留您的可视化层。

• Kubernetes 和 AWS 监测随附预构建仪表板、警报模板、ML 异常作业以及采集时即可使用的智能体调查内容。此外，技能和 MCP 应用 均可供使用。

• 适用于指标、日志和跟踪的统一后端，支持智能体调查 无需在各个工具间拼接上下文。

• Discover 中的指标探索让任何人都能立即开始查询和分析指标，无需具备查询语言专业知识。

• 自定义仪表板快速而灵活，仪表板即代码、AI 辅助仪表板创建、变量控件以及可折叠面板意味着减少构建时间，将更多时间用于调查。

• 迁移工具，用于帮助轻松从 Datadog 和 Grafana 迁移仪表板以及告警规则/监测。

Elasticsearch 指标现在在 SRE 关注的每个维度上都具有竞争力：您可以保持每个指标的完整分辨率，查询速度比 Prometheus 快 30 倍，费用比 Datadog 低 50%，可以轻松地从 Grafana 或 Datadog 迁移仪表板和警报规则，并且无需在不相连的工具之间拼接上下文即可从警报找到根本原因。本篇博文的其余部分将逐一详细介绍这些内容。

Elasticsearch 指标性能：比 Prometheus 和 Mimir 快 30 倍

Datadog 和 Prometheus 迫使人们做出同样的权衡：要么放弃高基数数据，要么眼睁睁看着成本飙升。管理 Kubernetes、AWS 或任何高基数基础设施的 SRE 都知道这个问题的具体情况。在发生突发事件时至关重要的 Kubernetes 标签、临时 Pod 数据以及细粒度 OTel 维度，往往在预算收紧时最先被舍弃。

Elastic 将时序数据存储和 ES|QL 计算引擎重构为全列式指标引擎。添加新 Kubernetes 标签、新 AWS 实例标记或新应用程序维度不会加重系统负担；与为每个标签建立索引的系统相比，其成本要低得多。OTel、Prometheus 以及应用程序定义的指标均以完整分辨率存入同一个列式后端，将日志、追踪和指标统一汇聚在单一存储中。不丢弃任何数据，不缩短保留时间。

Elasticsearch 存储指标的效率最高比 Prometheus 高 2.5 倍（结果可能会因压缩等因素而有所不同），比 ClickHouse 高 2 倍。通过 ES|QL 运行的查询性能最高可比 Prometheus 快 30 倍 在测量平均值和计数器速率方面，包括竞争对手陷入停滞的高基数工作负载。这篇架构博文 介绍了 TSDS 的组织方式，以及列式布局为何能产生这些结果。

| | | | | | :------------------------: | :----------------: | :--------------: | :----------------: | | Dimension | 对比 Prometheus | 对比 Mimir | 对比 ClickHouse | | 查询性能 (ES|QL) | 最高可提升 30 倍 | 最高可提升 30 倍 | 最高可提升 8 倍 | | 存储效率 | 最高提升 2.5 倍 | 相当 | 提升 2 倍 |

关键的架构差异在于，Elasticsearch 指标不会维护随基数扩展的每个时序内存状态，因此添加数千个新 Kubernetes Pod 标签或 OTel 维度不会增加内存压力。

OTel、Prometheus 原生指标和应用程序定义的指标都以相同的方式全分辨率存储，查询速度快，成本只有 Datadog 的一半。

Elastic Observability 指标定价，无 Datadog 自定义指标惩罚

Observability 成本是团队更换平台的首要原因。对于 Datadog 的客户来说，痛点在于一种定价机制：自定义指标。Datadog 内置集成之外的任何用户定义值都会被归类为自定义指标，并按更高费率计费。这包括 Kubernetes、OpenTelemetry 和云原生工作负载默认生成的高基数数据。您的插桩粒度越细，账单增长得就越快。运行现代基础架构的团队很快就会达到这一上限，其响应也在预料之中：丢弃数据、缩短保留时间，并丢失在事件发生时最为关键的上下文。

Elasticsearch 指标消除了这种分类。每项指标定价相同，不收取按指标计的附加费、不按基数计费，也不强制汇总。您可以保留每项指标的全分辨率数据，而不会在月底收到意外账单。而且，由于 Elastic 的成本仅为 Datadog 的 50%，与财务部门的讨论也随之改变：不再是为了不超出预算而不得不舍弃哪些数据，而是因为保留了所有数据而发现了什么。这也是 AI 调查能够发挥作用的原因。与 Grafana 分散的 LGTM 堆栈不同，警报触发时上下文已经统一，无需在互不相连的工具之间手动拼凑。

Elasticsearch 对 Prometheus 和 PromQL 的原生支持

大多数 SRE 团队并未运行整洁的单一格式遥测管道。Prometheus 已深深嵌入应用程序、服务、平台和自动化中。从历史上看，迁移指标后端意味着重写查询、重建仪表板和重新培训工程师。这种阻力足以让团队继续使用已无法满足需求的平台，而不愿经历这一过程。

Elasticsearch 指标消除了大部分阻碍。Prometheus 指标通过 Prometheus Remote Write 传入并存入同一个列式存储中且无语义更改，端到端地保留了完整的指标保真度。将其指向 Elasticsearch 而不是 Mimir，数据便可顺畅流动。无需转换层，无需更改现有的抓取配置。

PromQL 现已在 Kibana 中原生支持，因此习惯使用 PromQL 的工程师无需改变其工作方式。现有的 PromQL 查询、仪表板和告警规则可直接迁移至 Kibana。 

PromQL 查询无需更改即可在 Elasticsearch 上运行

如果您的团队已经在编写 PromQL，则无需做出任何改变。这些查询可以原样针对作为后端的 Elasticsearch 运行，只需复制、粘贴即可。

CPU 使用率（容器级别）按 Pod 分组的各个容器每秒 CPU 速率。有助于在发生事件期间查明哪些 Pod 正在大量消耗 CPU。

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

内存工作集（容器级别）每个容器当前正在使用的内存。这是衡量 OOM 风险的关键数值，而非分配的总内存。

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

HTTP 请求率（应用级） 按实例分组的每秒请求吞吐量。调查延迟或错误峰值时的标准首要信号。

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

这三者均遵循标准 PromQL 语法。如果您使用 Elasticsearch 作为后端，它们无需修改即可运行。有关完整的语法参考和涵盖的内容，请参阅 PromQL 支持文档。

原生 Prometheus API 使 Elasticsearch 成为完全兼容 Prometheus 的后端。任何兼容 Prometheus 的前端（包括 Grafana）都可以直接查询 Elasticsearch，因此希望将 Grafana 保留为可视化层同时整合到 Elasticsearch 的团队完全可以做到这一点，而无需修改现有的仪表板或告警规则。

当 SRE 需要进行超出 PromQL 能力范围的深入分析时，ES|QL 可在单个接口中处理指标、日志和跟踪数据。TS 命令可处理时间序列特有内容：计数器速率、仪表值平均值、窗口函数，以及跨高基数维度的多级聚合。用于获取 CPU 计数器速率的同一查询可以与来自同一主机的日志进行联接，并呈现峰值发生前的部署事件。无需切换工具，也无需使用新的查询语言。查询语言、仪表板、警报规则、可视化层，所有这些都可以沿用。唯一的变化是，Elasticsearch 成为为所有内容提供支持的单一后端。

Elastic Observability：开箱即用的仪表板、警报和基础架构内容

大多数 Observability 供应商都要求您从零开始构建一切。Elastic Observability 从三个方面降低了这种需求：

Discover 中的指标探索。 全新的 Elasticsearch 指标探索体验 让 SRE 能够在用于日志的同一接口中探索指标，无需切换标签页，无需重复查询。连接 OTel 管道或 Prometheus 抓取配置，打开 Streams，数据流中的每个指标都会立即呈现为时序图表。无需构建仪表板，无需编写查询。团队可在此验证数据、发现模式，根据正在流动的内容的实时视图开始构建告警和 SLO，并与 Elasticsearch 中的日志、跟踪及其他已编入索引的数据进行交叉关联。

仪表板。Kibana 仪表板新增了支持延迟加载的可折叠面板，因此在需要之前，非立即可见的面板不会生成查询；此外还新增了 ES|QL 控制变量，让 SRE 无需编写新的查询即可通过下拉菜单操作可视化。Dashboards-as-code 也已推出，支持受版本控制的仪表板定义，使其能够跨环境以编程方式进行模板化、共享和部署。

开箱即用的基础架构内容。 Elastic 随附推出了两项全新的基础架构开箱即用 (OOTB) 体验：

• 全新的 Kubernetes 集成 包含分层仪表板、告警规则模板、ML 异常检测作业，以及 AI 辅助根本原因分析所需的上下文和提示，一切均已预先配置妥当，数据一开始导入即可使用。

• AWS 基础架构监控遵循相同的模式：核心 AWS 服务的开箱即用内容会在采集时激活，因此团队无需在每次有新服务或账户上线时都从头开始。同样的方法也适用于数据库和其他核心基础架构。该平台自带预设，而非一片空白。

借助 Elastic Observability 跨基础架构开展智能体调查

Elasticsearch 可在单个后端中关联指标、日志和跟踪，因此在呼叫工程师之前，调查上下文便已汇集完毕。

最棘手的是凌晨 2 点。RDS 实例达到连接限制，导致上游服务资源匮乏。Auto Scaling 组因深藏在应用程序日志中的原因而导致健康检查失败。Pod 重启在整个命名空间中引发级联反应。

在 Grafana LGTM 堆栈中，您在拥有足够的上下文来形成假设之前，就需要打开三个标签页。

在 Datadog 中，上下文是统一的，但 AI 是一个黑盒：不支持自带 LLM (BYO-LLM)，也没有数据驻留选项。

在 Elastic 中，指标、日志和跟踪共享单个后端和通用模式，因此在触发告警时，调查上下文就已整合就绪，无需跨工具进行手动关联，也不会在查询语言之间的转换中丢失上下文。ML 异常检测针对基础架构指标（Kubernetes、AWS、数据库）自动运行，因此调查始于带有上下文（包含典型行为、发生的变化以及偏差严重程度）的已评分异常，而不仅是单纯的阈值突破。

当告警触发时，Elastic 的调查工作流会在向任何人发送呼叫之前关联信号、汇总根因上下文，并呈现建议的后续步骤。智能体驱动的 Kubernetes 可观测性博文 端到端地演示了一个完整示例。EKS 故障排查演练 展示了 Agent Builder 与 MCP 如何协同工作，跨 EC2、EKS 和相关 AWS 服务实现完整的根因分析闭环。

除了在 Elastic Observability 中调查问题外，您还可以使用 Claude、Cursor、VS Code 或您喜爱的工具，通过 Elastic 提供的 MCP 应用和智能体技能分析问题。Observability MCP 应用可将分析能力扩展到您的团队已在使用的任何工作环境。如果您的团队在 Claude、Cursor 或 VS Code 中开展调查，相同的调查功能（基础架构运行状况汇总、服务依赖关系图表、异常详情、影响范围分析）将直接在对话中呈现为交互式视图。Grafana 和 Datadog 均不提供此功能。

• Observability MCP 应用——将 Claude、Cursor、VS Code 或任何兼容 MCP 的工具直接连接到您的 Elasticsearch 数据，使基础架构运行状况、服务依赖项和异常上下文在对话中以交互式视图的形式呈现，而无需离开您首选的工具。查看其如何与 Kubernetes 配合使用。

• 智能体技能 —— 面向 Kubernetes、AWS 和其他核心基础架构的预构建技能，让任何智能体（无论是在 Elastic 中还是您自己的智能体）都能针对您的可观测性数据运行结构化调查，无需自定义提示工程。将它们加入 Claude、Cursor 或您自己的智能体管道中，即可开箱即用。探索可观测性技能 或 浏览 GitHub 上的技能库。

从 Datadog 或 Grafana 迁移到 Elastic Observability

SRE 团队不更换可观测性平台的最常见原因是迁移问题。迁移积累数年的告警规则、数百个仪表板以及运行手册中嵌入的 PromQL 查询是一项艰巨的运维任务，而且在此期间维护并行技术栈的成本每天都在增加。

Observability 迁移平台 会自动处理转换。将 CLI 或 Claude/Cursor（借助 Elastic 的智能体技能）指向您的 Datadog 组织或 Grafana 实例，它就会将受支持的仪表板、告警规则和 PromQL 查询转换为 Kibana 原生输出。该工具让您可以查看已完全迁移的内容、需要微调的内容，以及完成全部迁移还需要您执行的操作。您可以直接迁移已构建的内容。

在采集方面，Prometheus Remote Write 意味着管道无需任何更改。抓取配置指向 Elasticsearch，而不是另一个兼容 Prometheus 的后端，并且数据会进入同一个列式存储中。工作流、查询和告警配置均可直接沿用，无需更改。对于希望在迁移期间或迁移后继续将 Grafana 用作可视化层的团队，Kibana 中的原生 Prometheus API 和 PromQL 支持意味着可以分阶段过渡，而无需一次性全部切换。

Elasticsearch 作为 Grafana 的后端

对于尚未准备好离开 Grafana 的团队来说，替换后端本身就是一种迁移路径，根据您的工作流程，有两种方法可以做到这一点。

如果您的团队目前正在运行 Prometheus，阻力最小的途径是 Grafana 的 Prometheus 数据源。Elasticsearch 现已提供原生兼容 Prometheus 的 API，因此您可以将 Grafana 现有的 Prometheus 插件直接指向 Elasticsearch。无需 Sidecar、无需适配器，也无需更改管道。现有的 PromQL 仪表板、告警规则和变量下拉列表无需修改即可直接使用，包括 Grafana 的 Metrics Drilldown 探索器。在您的 Prometheus 配置中将 Elasticsearch 添加为 remote_write 目标，并替换数据源 URL。对于大多数团队来说，这就是完整的迁移流程。请参阅端到端设置指南。

对于想要更进一步、在单个 Grafana 查询编辑器中同时查询日志、指标和追踪信息的团队，Grafana Elasticsearch 官方插件现已提供 ES|QL 支持。这直接在 Grafana 中实现了跨信号关联，并通过 Elasticsearch 在统一的列式后端中处理所有这三种数据类型。了解如何进行设置。

无论采用哪种方式，都可保留 Grafana，替换 Mimir 和 Loki，并充分利用底层 Elasticsearch 的列式存储和查询性能。多年的运营工作，得以保留。团队一直拖延的迁移工作最终变成了后端替换。

哪些功能已正式发布，哪些处于技术预览阶段

| 功能 | 状态 | | ----------------------------------------- | ------------ | | 列式指标引擎 (TSDS) | 正式发布 | | ES|QL 时序支持 | 正式发布 | | Kibana 中的 PromQL 支持 | 正式发布 | | Prometheus Remote Write 采集 | 正式发布 | | Kubernetes 基础架构开箱即用体验 | 正式发布 | | AWS 基础架构开箱即用体验 | 技术预览 | | Observability MCP 应用 | 技术预览 | | Agent 技能 | 技术预览 | | Observability 迁移 Platform | 技术预览 |

文中链接的各篇文章涵盖了 GA 与预览版的具体细节以及已知限制。

所有这些（列式指标引擎、原生 PromQL、Agent 驱动的调查以及迁移工具）均可在 Elastic 的三种部署模式下运行：Serverless、Elastic Cloud 和自托管。Datadog 没有本地部署选项；Grafana Cloud 将其最具价值的功能限制在托管部署中。使用 Elastic，您可以选择数据存储的位置。

Elastic Observability：在不丢失数据的情况下降低成本

现代云基础架构打破了围绕针对不同信号采用不同工具构建的可观测性模型。代价显而易见：重复的工具账单、事件发生期间的手动关联，以及为了控制预算而丢弃的数据。

一个能够高效存储所有信号的单一后端意味着您可以保留所需的内容，而无需支付通常随之而来的费用。与财务部门的对话方式也因此大为不同：不再是“为了不超出预算，我们不得不放弃数据”，而是“我们发现了以下情况”。AI 能够全面了解情况，因为只有单一全景视图；而且该平台自带充足的预构建内容，在第一天就能派上用场，而无需花费数周时间在仪表板上进行繁琐的操作。

之所以能够做到这一点，是因为 Elasticsearch 的构建方式与您可能要替换的平台不同：

• 列式指标存储在 TSDS 索引模式下极其高效地存储指标数据。 

• 原生 Prometheus 兼容性意味着现有抓取配置、PromQL 查询和仪表板无需重写即可正常工作。

• 在单个后端中统一指标、日志和跟踪意味着调查上下文是在查询时汇集的，而不是跨标签页手动收集。

• 同一引擎中的搜索与分析——用于日志的倒排索引，用于指标的列式索引，并通过 ES|QL 统一查询。

• 智能体调查能够在向任何人发送寻呼之前关联信号、发现异常并提出修复建议。

• 无服务器、Elastic Cloud 或自管理——由您选择数据的存放位置，这是 Datadog 无法提供的。

与财务部门关于成本的对话变成了关注您发现了什么，而不是花费了多少。

开始使用

• 开始免费试用

• Elastic Observability 文档

• Elastic Observability 实验室

常见问题

Elasticsearch 现在是否是可用于生产的指标平台？

是的。截至 2026 年 6 月，Elasticsearch 提供专为时序数据打造的重构列式存储引擎、原生 Prometheus Remote Write 采集、Kibana 中的 PromQL 支持、ES|QL 时序查询，以及适用于 Kubernetes 和 AWS 的开箱即用型基础架构仪表板。列式指标引擎、ES|QL 时序支持、PromQL 和 Prometheus 采集均已在 Elastic Serverless 中正式发布，并即将在 Elastic Cloud Hosted 中正式发布。

Elasticsearch 与 Datadog 在指标成本方面相比如何？

在同等指标工作负载下，Elastic Observability Serverless 的成本明显低于 Datadog，根据基于公开标价的说明性示例，成本降低超过 50%，通常降低近三分之二。这种差距是结构性的：Datadog 主要按主机计费，随着遥测采集规模扩大，还会对自定义指标和容器额外收费。在 Datadog 收费最高的工作负载中，成本差异最为显著：即 Kubernetes 和 OTel 等高基数、密集遥测采集的环境。

Elasticsearch 的指标性能与 Prometheus 和 Grafana Mimir 相比如何？

在测量平均值和计数器速率方面，Elasticsearch 上的 ES|QL 查询比 Prometheus 和 Mimir 快 30 倍，包括高基数工作负载。Elasticsearch 存储 OTel 指标每个数据点占用 3.75 字节；比 Prometheus 的效率高出 2.5 倍，比 ClickHouse 的效率高出 2 倍。

团队能否从 Datadog 或 Grafana 迁移到 Elasticsearch 而无需重新构建一切？

是的。Elastic 的可观测性迁移平台可以将 Datadog 和 Grafana 的仪表板、告警规则以及 PromQL 查询原封不动地迁移到 Kibana 中。团队还可以保留 Grafana 作为可视化层，同时将后端替换为 Elasticsearch，并在 Kibana 中使用原生 Prometheus API 和 PromQL 支持。

在指标可观测性方面，Elasticsearch 与 Grafana 有何不同？

Elasticsearch 将指标、日志和跟踪存储在单一统一的后端中，并使用一种查询语言 (ES|QL)，而 Grafana 的 LGTM 技术栈则将指标 (Mimir/Prometheus) 和日志 (Loki) 分散在不同的后端，需要使用单独的查询语言。Elasticsearch 还提供智能体调查能力，其中包括 AI 智能体、工作流、MCP 应用和 Agent 技能，比 Grafana 提供了更全面的功能集。 

Elasticsearch 是否原生支持 Prometheus 和 PromQL？

是的，有两种不同的方式。首先，Elasticsearch 可通过 Prometheus Remote Write 接收 Prometheus 指标，并提供原生兼容 Prometheus 的 API，因此可作为任何兼容 Prometheus 的前端（包括 Grafana）的后端。其次，Kibana 原生支持 PromQL，这意味着现有查询、仪表板和告警规则无需转换层或修改即可直接在 Kibana 中运行。

Elastic Observability 开箱即用提供哪些基础架构监测内容？

Elastic 提供预构建的仪表板、告警模板以及 ML 异常检测作业，涵盖主机、容器、云服务、数据库、网络设备等数百种基础架构集成。特别针对 Kubernetes 和 AWS，该平台还包含智能体调查内容，例如智能体技能以及 Observability MCP 应用，让团队可以直接在 Claude、Cursor 或 VS Code 中运行调查。所有这一切都在采集时可用，无需任何配置。