作者来自 Elastic Bahubali Shetti 及 Vinay ChandrasekharElasticsearch 现在在指标metrics领域也是一流方案比 Prometheus 快 30 倍存储效率最高提升 2.5 倍比 Datadog 低 50%。了解我们新增的所有能力。过去几个月里Elastic 在 Elasticsearch 中发布了一个专为时序数据设计的列式存储引擎同时支持原生 Prometheus 数据接入与存储、PromQL 支持并提供了全新的指标探索体验、预构建基础设施仪表板、智能体式调查能力以及从 Datadog 和 Grafana 的迁移路径。当前能力包括Elasticsearch 现在是一个兼容 Prometheus 的指标后端 —— 支持 Prometheus Remote Write 和在 Kibana 中原生运行 PromQL无需任何转换层。指标数据写入 Elasticsearch 的列式 TSDS 架构相比 Prometheus 存储效率最高提升至 2.5×相比 ClickHouse 提升约 2 倍。ES|QL 时序查询在平均值gauge averages和计数器速率counter rates上相比 Prometheus 在高基数工作负载下可实现 最高 30× 更快。Elastic 的成本比 Datadog 低约 50%没有自定义指标分类也没有基于基数的计费。Grafana 可以通过 原生 Prometheus API 直接查询 Elasticsearch在保留可视化层的同时替换后端。Kubernetes 和 AWS 监控提供开箱即用的预构建仪表板、告警模板、机器学习异常检测作业以及智能体调查内容。同时还提供 skills 和 MCP 应用。统一后端支持指标、日志和追踪使得无需跨工具拼接上下文即可进行智能体式调查。在 Discover 中的指标探索体验让任何人都可以立即开始查询与分析指标无需精通查询语言。自定义仪表板构建快速且灵活 —— dashboard-as-code、AI 辅助仪表板生成、变量控制以及可折叠面板设计让用户更少时间构建、更多时间调查问题。提供迁移工具可轻松将 Datadog 和 Grafana 中的仪表板与告警规则/监控迁移过来。Elasticsearch 的指标能力如今在 SRE 关注的所有关键维度上展开竞争你可以以全分辨率保留所有指标以比 Prometheus 快 30 倍的速度查询以比 Datadog 低 50% 的成本运行并且可以从 Grafana 或 Datadog 轻松迁移仪表板和告警规则同时从告警直接追溯到根因而无需在多个工具之间拼接上下文。本文接下来将逐一展开这些能力。Elasticsearch 指标性能比 Prometheus 和 Mimir 快 30 倍Datadog 和 Prometheus 强制用户做同样的权衡要么丢弃高基数数据要么看着成本失控。负责 Kubernetes、AWS 或任何高基数基础设施的 SRE 都熟悉这个问题的具体形态。当发生事故时最关键的 Kubernetes label、短暂的 pod 数据以及精细的 OpenTelemetry 维度往往也是预算收紧时最先被舍弃的内容。Elastic 重新构建了时序数据存储和 ES|QL 计算引擎使其成为完全列式的指标引擎。新增一个 Kubernetes label、一个 AWS 实例标签或一个应用维度不会对系统造成压力其增加的成本远低于那些需要对每个 label 建索引的系统。OpenTelemetry、Prometheus 以及应用自定义指标都会以完整分辨率进入同一个列式后端并与日志、追踪数据统一存储在同一系统中。没有数据丢失也不需要缩短保留周期。Elasticsearch 在指标存储效率上比 Prometheus 高达 2.5 倍由于压缩等因素不同结果可能有所变化比 ClickHouse 高约 2 倍。通过 ES|QL 的查询性能在 gauge 平均值和 counter 速率等场景下相比 Prometheus 可实现 最高 30 倍速度提升包括在竞争系统会出现性能瓶颈的高基数工作负载中。架构文章 详细说明了 TSDS 的组织方式以及为什么列式结构能够带来这些性能结果。维度相比 Prometheus相比 Mimir相比 ClickHouse查询性能ESQL最高快 30×最高快 30×存储效率最高提升 2.5×持平提升 2×关键的架构差异在于Elasticsearch metrics 不维护随基数增长而扩展的“按时间序列per-series内存状态”因此新增成千上万的 Kubernetes pod labels 或 OpenTelemetry 维度不会增加内存压力。OpenTelemetry、Prometheus 原生指标以及应用自定义指标都会以相同方式、全分辨率地存储在系统中并以高速方式查询同时成本约为 Datadog 的一半。在没有 Datadog 自定义指标惩罚的情况下使用 Elastic Observability metrics 定价可观测性成本是团队切换平台的首要原因。对于 Datadog 用户来说问题核心在于一个定价机制自定义指标custom metrics。任何不属于 Datadog 内置集成的用户定义指标都会被归类为自定义指标并按溢价计费。这包括 Kubernetes、OpenTelemetry 和云原生工作负载天然产生的高基数数据。你的监控越精细账单增长越快。运行现代基础设施的团队很快会触达这个上限而常见反应是丢数据、缩短保留周期、失去在事故发生时最关键的上下文。Elasticsearch metrics 移除了这一分类机制。所有指标统一定价没有按指标计费的惩罚没有基于基数的额外收费也不需要强制降采样或汇总。你可以在不担心月底“意外账单”的情况下保留所有指标的完整分辨率。而且由于 Elastic 的成本约为 Datadog 的 50%与财务沟通的重点也发生变化不再是为了控制预算必须丢弃哪些数据而是因为保留了全部数据而获得了哪些洞察。这也是 AI 调查能力能够成立的原因之一。与 Grafana 那种碎片化的 LGTM 技术栈不同在告警触发时上下文已经是统一的而不是在多个工具之间手动拼接出来的。Elasticsearch 中对 Prometheus 与 PromQL 的原生支持大多数 SRE 团队并不会运行一个干净、统一格式的可观测性数据管道。Prometheus 已经深度嵌入在应用、服务、平台以及自动化系统中。历史上迁移指标后端意味着要重写查询、重建仪表板并重新培训工程师——这种摩擦足以让团队继续留在已经不再适合自身规模的平台上。Elasticsearch metrics 已经移除了大部分这类摩擦。Prometheus 指标通过 Prometheus Remote Write 写入并以相同的列式存储结构落地不会发生语义变化从端到端保持完整指标精度。只需将目标从 Mimir 指向 Elasticsearch数据即可流动无需转换层也不需要修改现有 scrape 配置。PromQL 现在在 Kibana 中原生支持因此习惯使用 PromQL 的工程师无需改变工作方式。现有 PromQL 查询、仪表板和告警规则都可以直接迁移到 Kibana。PromQL 查询在 Elasticsearch 上无需修改即可运行如果你的团队已经在使用 PromQL那么无需做任何改动。这些查询可以直接在 Elasticsearch 后端运行——复制、粘贴即可使用。CPU 使用率容器级按 Pod 聚合的容器 CPU 每秒使用速率。在事故排查中用于识别哪些 Pod 正在消耗 CPU。PROMQLsum by (pod) (rate(container_cpu_usage_seconds_total[5m]))内存工作集容器级当前容器实际使用的内存active memory这是判断 OOM 风险的关键指标而不是总分配内存。PROMQLsum by (container) (avg_over_time(container_memory_working_set_bytes[5m]))HTTP 请求速率应用级按实例聚合的每秒请求吞吐量是分析延迟或错误突增时的第一信号。PROMQLsum by (instance) (rate(http_requests_total[5m]))这三种查询都遵循标准 PromQL 语法。如果使用 Elasticsearch 作为后端它们可以直接运行无需任何修改。完整语法参考可见 PromQL 支持文档。原生 Prometheus API 支持原生 Prometheus API 使 Elasticsearch 成为完全兼容 Prometheus 的后端。任何兼容 Prometheus 的前端包括 Grafana都可以直接查询 Elasticsearch因此希望保留 Grafana 可视化层同时将后端统一到 Elasticsearch 的团队可以在不修改现有仪表板或告警规则的情况下实现迁移。当 SRE 需要超越 PromQL 能力时ES|QL 可以在指标、日志和追踪之间提供统一查询接口。TS命令专门处理时序语义计数器速率、指标平均值、窗口函数以及跨高基数维度的多级聚合。同一个查询既可以计算 CPU 计数器速率也可以关联同一主机的日志从而定位导致异常的部署事件。无需切换工具也无需学习新的查询语言。查询语言、仪表板、告警规则、可视化层——全部可以迁移过来。唯一变化的是Elasticsearch 成为所有能力的统一后端。Elastic Observability开箱即用的仪表板、告警与基础设施内容大多数可观测性厂商都要求你从零开始构建一切。Elastic Observability 在三个方面减少了这部分工作量Metrics exploration in Discover在 Discover 中进行指标探索全新的 Elasticsearch 指标探索体验 让 SRE 可以在与日志相同的界面中探索指标——无需切换标签页也无需重复编写查询。连接 OpenTelemetryOTel管道或 Prometheus 抓取配置后打开 Streams每个数据流中的指标都会立即以时间序列图的形式呈现。不需要构建仪表板也不需要编写查询。团队可以在这里验证数据、发现模式并从实时数据视图中开始构建告警和 SLO同时与 Elasticsearch 中的日志、追踪以及其他索引数据进行交叉关联分析。仪表板Dashboards。Kibana 仪表板新增了可折叠面板与懒加载机制因此未立即可见的面板不会在需要之前触发查询。同时引入 ES|QL 控制变量使 SRE 可以通过下拉菜单直接操控可视化而无需编写新的查询。Dashboards-as-code 也已发布支持对仪表板定义进行版本管理可以模板化、共享并在不同环境中通过程序化方式部署。开箱即用的基础设施内容Out-of-the-box infrastructure content。Elastic 正在提供两种新的基础设施开箱即用体验新的 Kubernetes 集成 提供分层仪表板、告警规则模板、机器学习异常检测任务以及用于 AI 辅助根因分析的上下文与提示信息——所有内容在数据开始流入的瞬间就已预配置完成并可直接使用。AWS 基础设施监控遵循相同模式针对核心 AWS 服务提供开箱即用OOTB的内容在数据开始写入时即自动激活因此团队在每次引入新服务或新账号时都不需要从零开始。同样的方法也扩展到数据库及其他核心基础设施——平台本身带有明确的“最佳实践配置”而不是一个空白起点。使用 Elastic Observability 进行跨基础设施的智能体式调查Agentic investigationsElasticsearch 在单一后端中关联指标、日志和追踪数据因此在工程师被告警通知之前调查所需的上下文就已经被组装完成。最困难的时刻通常是在凌晨 2 点一个 RDS 实例触发连接数上限导致上游服务资源不足一个 Auto Scaling 组因健康检查失败而异常扩缩容而原因隐藏在应用日志中一个 Pod 重启引发整个命名空间级联故障。在 Grafana 的 LGTM 技术栈中你往往需要打开三个不同的标签页才能勉强形成一个初步假设。在 Datadog 中上下文是统一的但 AI 是一个黑盒无法使用自带 LLMBYO-LLM也没有数据驻留data residency选项。在 Elastic 中指标、日志和追踪共享同一个后端与统一数据模型因此在告警触发时调查上下文已经完成组装——无需跨工具手动关联也不会在不同查询语言之间丢失上下文。机器学习异常检测会自动在基础设施指标Kubernetes、AWS、数据库上运行因此调查从一个带有评分的异常开始同时附带“正常行为基线”“变化点”和“严重程度”而不仅仅是一个简单的阈值告警。当告警触发时Elastic 的调查工作流会自动关联信号、组装根因上下文并在工程师被通知之前给出建议的下一步操作。面向 Kubernetes 的智能体可观测性文章 展示了完整端到端流程。EKS 故障排查演示 则说明了 Agent Builder 与 MCP 如何协同在 EC2、EKS 及相关 AWS 服务之间完成完整根因闭环。除了在 Elastic Observability 中直接进行问题分析之外你还可以使用 Claude、Cursor、VS Code 或其他工具通过 MCP Apps 和 Elastic 的 agent skills 来分析问题。Observability MCP App 将分析能力扩展到团队已经在使用的工具中。如果你的团队在 Claude、Cursor 或 VS Code 中进行排障同样的调查能力基础设施健康汇总、服务依赖图、异常详情、影响范围分析会以交互式视图直接呈现在对话中。Grafana 和 Datadog 都不具备这一能力。Observability MCP App—— 将 Claude、Cursor、VS Code 或任何兼容 MCP 的工具直接连接到你的 Elasticsearch 数据使基础设施健康状态、服务依赖关系以及异常上下文能够以交互式视图形式出现在对话中而无需离开当前工具。了解其在 Kubernetes 中的使用方式。Agent Skills智能体技能—— 面向 Kubernetes、AWS 等核心基础设施的预置技能让任何 agent无论是在 Elastic 内部还是你自定义的 agent都可以在无需定制 prompt 工程的情况下对你的可观测性数据执行结构化调查。可以直接将这些技能接入 Claude、Cursor 或你自己的 agent 管道中即开即用。浏览 observability skills 或 查看 GitHub 技能库。从 Datadog 或 Grafana 迁移到 Elastic ObservabilitySRE 团队不愿切换可观测性平台的最常见原因就是迁移本身。迁移多年积累的告警规则、数百个仪表板以及嵌入在 runbook 中的 PromQL 查询是一项高成本的运维任务而在迁移过程中同时维护两套系统的成本每天都在累积。Observability Migration Platform可观测性迁移平台 可以自动完成这种转换。你只需将 CLI 或带有 Elastic agent skills 的 Claude/Cursor 指向你的 Datadog 组织或 Grafana 实例它就会将支持的仪表板、告警规则以及 PromQL 查询转换为 Kibana 原生格式。工具会清晰标出哪些内容已完整迁移、哪些需要调整以及还需要你补充什么从而完成全部迁移。你可以直接迁移已有的系统资产。在数据接入层Prometheus Remote Write 意味着数据管道无需修改。只需将 scrape 配置从原 Prometheus 兼容后端指向 Elasticsearch数据就会进入同一个列式存储引擎。工作流、查询和告警配置都无需改变即可继续使用。对于希望在迁移期间或迁移后继续使用 Grafana 的团队来说原生 Prometheus API 与 Kibana 对 PromQL 的支持使迁移可以分阶段进行而不是一次性切换。以 Elasticsearch 作为 Grafana 后端对于尚未准备完全放弃 Grafana 的团队替换后端本身就是一种迁移路径而且根据工作流不同有两种实现方式。如果你的团队当前使用 Prometheus最低成本路径是继续使用 Grafana 的Prometheus 数据源。由于 Elasticsearch 现在提供原生 Prometheus 兼容 API你可以直接将 Grafana 的 Prometheus 插件指向 Elasticsearch。将 Grafana Prometheus 数据源直接连接到 Elasticsearch。无需 sidecar、无需 adapter也无需修改数据管道。现有 PromQL 仪表板、告警规则以及变量下拉框都可以原样运行包括 Grafana 的 Metrics Drilldown 探索功能。只需在 Prometheus 配置中添加 Elasticsearch 作为remote_write目标并替换数据源 URL这就是大多数团队的完整迁移路径。查看端到端配置指南。对于希望更进一步、在同一个 Grafana 查询编辑器中同时查询日志、指标和追踪的团队官方 Grafana Elasticsearch 插件现在支持 ES|QL。这使得跨信号关联可以直接在 Grafana 中完成而 Elasticsearch 在统一的列式后端中处理三种数据类型。查看配置方法。无论哪种方式你都可以继续保留 Grafana同时替换 Mimir 和 Loki并在底层获得 Elasticsearch 的列式存储与查询性能优势。多年积累的运维工作得以保留而原本令人望而却步的迁移变成了一次后端切换。什么是正式发布以及什么是技术预览Tech Preview能力状态列式指标引擎TSDSGAESQL 时序支持Kibana 中 PromQL 支持GAPrometheus Remote Write 写入GAKubernetes 基础设施开箱即用体验GAAWS 基础设施开箱即用体验技术预览可观测性 MCP 应用技术预览Agent skills智能体技能技术预览可观测性迁移平台技术预览各个帖子中链接的内容分别说明了 GA 与预览功能的差异以及已知限制。以上所有能力列式指标引擎、原生 PromQL、智能体式调查能力、迁移工具都可以在 Elasticsearch 的三种部署模式中运行Serverless、Elastic Cloud以及自建部署。Datadog 没有本地部署选项而 Grafana Cloud 将其高价值功能限制在托管环境中。在 Elasticsearch 中你可以选择数据存放的位置。Elasticsearch 可观测性在不降低数据量的情况下降低成本现代云基础设施已经打破了“按信号拆分工具”的可观测性模式而这种模式的成本是真实存在的工具重复订阅费用、故障时跨系统关联的手工成本以及为了控制预算而被迫丢弃数据。一个统一后端如果能高效存储所有信号就可以让你在不增加成本的情况下保留需要的数据。这会改变和财务部门的对话方式不再是“我们因为预算限制不得不丢数据”而是“这是我们实际发现的情况”。AI 也能获得完整上下文因为只有一个完整数据视图而且平台自带足够多的预置内容开箱即可使用而不是几周仪表盘搭建之后才可用。这之所以可行是因为底层架构与传统平台不同列式指标存储在 TSDS 索引模式下高效存储指标数据原生 Prometheus 兼容性无需改写 scrape 配置、PromQL 查询或仪表盘统一指标、日志与链路追踪查询时自动拼接上下文而不是手动跨系统关联搜索与分析统一引擎日志用倒排索引指标用列式索引并通过 ES|QL 一起查询智能体式调查能力自动关联信号、发现异常并在告警前给出修复建议多部署模式支持Serverless、Elastic Cloud 或自建部署均可选择数据位置Datadog 无法提供同等灵活性因此与财务讨论的重点从“我们花了多少”变成“我们发现了什么”。快速开始开始免费试用Elastic 可观测性文档Elastic Observability Labs常见问题Elasticsearch 现在是生产级指标平台了吗是的。截至 2026 年 6 月Elasticsearch 已经提供面向时序数据重构的列式存储引擎、原生 Prometheus Remote Write 写入、Kibana 中 PromQL 支持、ES|QL 时序查询能力以及 Kubernetes 和 AWS 的开箱即用基础设施监控。相关能力在 Serverless 中已 GA在 Elastic Cloud Hosted 中即将 GA。Elasticsearch 和 Datadog 在指标成本上有什么区别在可比的指标工作负载中Elastic Observability Serverless 的成本显著低于 Datadog在公开定价对比的示例中通常低 50% 以上甚至接近三分之二。差异主要来自计费模型Datadog 主要按主机计费并对自定义指标和容器规模额外收费而 Elastic 的成本更偏向数据量与存储效率。Elasticsearch 和 Prometheus / Grafana Mimir 的性能对比如何ES|QL 在高基数场景下的 gauge 平均值与 counter rate 查询中相比 Prometheus 和 Mimir 可达到最多约 30 倍加速。其对 OTel 指标的存储效率也更高约 3.75 bytes / data point。是否可以从 Datadog 或 Grafana 无缝迁移可以。Elasticsearch 提供迁移平台可转换 Datadog / Grafana 仪表盘、告警规则并将 PromQL 查询迁移到 Kibana同时支持保留 Grafana 作为可视化层。Elasticsearch 与 Grafana 在指标可观测性上的核心区别Elasticsearch 将指标、日志、链路统一在一个后端并使用 ES|QL 统一查询而 Grafana LGTM 体系将数据分散在 Mimir / Loki 等不同后端需要不同查询语言。Elastic 还提供智能体式调查能力Agent skills、MCP 应用等。是否原生支持 Prometheus 和 PromQL支持。既可以通过 Prometheus Remote Write 写入也可以在 Kibana 中直接使用 PromQL无需转换层。开箱即用的基础设施监控有哪些包括 Kubernetes、AWS 等大量集成的预置仪表盘、告警模板和异常检测并支持智能体调查能力Agent skills、MCP 应用等。原文Elasticsearch: best-in-class for logs, now best-in-class for metrics — Elastic Observability Labs