• 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 中运行调查。所有这一切都在采集时可用，无需任何配置。

在第 1 部分中，我们介绍了 Elastic Kubernetes 集成如何通过 EDOT Collector 将遥测数据发送/传输至 Elasticsearch。在本文中，我们将更进一步，介绍一个 MCP (Model Context Protocol) 应用服务器，它将这些遥测数据公开为 AI 可调用的工具，并配有以内联方式渲染的交互式 React UI。我们还将介绍如何利用 Elastic Workflows 更进一步：通过自动化 Runbook 处理从告警到修复建议的完整根本原因分析闭环。

在您工作的界面中呈现的 Observability MCP 应用

Elastic Observability MCP 应用（技术预览版）提供六个视图，每个工具对应一个视图。当工具返回结果时，每个视图都会以内联方式呈现，并以可点击按钮的形式显示针对性的后续步骤提示，让您无需猜测下一步该怎么做。MCP 应用比独立的智能体工作流更进一步，它们直接在您的聊天窗口或 IDE 中以内联方式呈现交互式实时视图，无需切换上下文至 Kibana。

集群健康状况汇总

询问“哪里出故障了？”或“给我一份状态报告”，即可一目了然地掌握全局：包括整体健康状态标识、性能下降的服务及其原因、内存占用最高的 pod、异常严重程度分解，以及服务吞吐量——全部在一个内联视图中。

视图会根据您的部署支持的内容进行调整。APM 为您提供服务运行状况。Kubernetes 指标添加了 pod 和 Node 上下文。ML 作业也会将异常纳入其中。如果信号不存在，视图会告诉您缺少了什么，而不是直接失败。我们将从 Kubernetes 集群的状态报告开始：

诸如健康摘要之类的复合报告采用了精简的数据呈现方式并支持展开详细信息，以便您可以选择一次查看适量的信息。建议的调查操作不仅为返回的具体信息提供指导，还会指引用户运行其他工具。

服务依赖关系图表

问“哪些服务会调用 checkout？”或者“显示拓扑结构”并获取分层依赖图表——上游调用者、下游依赖项、协议、每条边的调用量和延迟。将鼠标悬停在一条边上即可突出显示完整的调用路径。让我们让 Claude “给我看看前端的服务依赖关系”：

缩放、平移和悬停以获取理解复杂服务关系所需的所有详细信息：

异常详情

底部“有什么异常？”或“checkout 中是否存在异常？”并自动获取两种视图之一。如果多个实体受到影响，概述模式会显示严重性计数、受影响的实体以及按作业细分的信息。如果重点关注单个实体，详细信息模式会显示分数、带比较条的实际值与典型值、偏差百分比，以及可用时的时间序列。让我们检查一下前端服务：

这不是 ESQL 查询，而是对先前定义的异常检测作业结果的解释。正如本博客系列的第 1 部分所讨论的，Kubernetes 集成附带了一些供您启用的项。此工具将帮助您充分利用它们。

Observe

Observe 是智能体访问 Elastic 的主要方式，一个工具，两种模式，满足三种不同需求。说“我的每个 Kubernetes 集群的网络吞吐量是多少”，即可获得结果表格或图表。说“当内存降到 80MB 以下时告诉我”或“在接下来 10 分钟内留意前端内存的任何异常”，它会一直等待，直到条件触发或时间窗口结束。

视图可根据模式进行调整：用于单次查询的结果表、用于采样和阈值条件的带当前/峰值/基线统计数据的实时趋势图，以及用于异常模式的按严重程度评分的触发卡。我们将在此处使用它来识别最繁忙的 Kubernetes 节点：

利用影响半径评估风险

询问“如果此 Node 宕机会发生什么？”，并获取一个辐射状影响图：目标 Node 位于中心，完全中断的部署用红色表示，性能降级的部署用琥珀色表示，未受影响的部署用灰色表示。浮动摘要卡显示有风险的 Pod 和重新调度的可行性。单副本部署被标记为单点故障。如果我们繁忙的 Node 发生故障，会发生什么情况：

警报管理

使用告警管理工具，您可以创建、列出、获取告警信息以及删除告警。接下来，我们将创建一个告警，但首先请再次使用 Observe 快速获取基线，以确保告警合理：

只需说出“如果前端内存超过 75MB，请向我发出告警”，智能体就会创建一条持久性 Kibana 告警规则，一个在对话结束后仍会继续运行的已保存对象。该视图呈现一个实时规则卡片：规则名称、条件、窗口、检查间隔、KQL 筛选器和标签。后续步骤按钮可用于验证规则、观察指标趋于稳定或检查当前集群健康状况。智能体确认已创建的内容以及在 Kibana 中的查找位置：

MCP 应用架构

该应用由一个 Node.js 服务器、六个对应六个单文件视图资源且面向模型的工具、用于重新查询的应用专属工具以及 vite-plugin-singlefile 打包组成。工具按部署后端（通用、APM 依赖、K8s 依赖、ML 依赖）进行分组，因此智能体和用户都可以提前知道哪些工具适用于特定部署，而不是在调用时发现功能缺口。该代码库包含六个以独立 .zip 产物形式提供的技能，用于指导智能体何时以及如何调用各个工具。

下图显示了构成该应用程序的三个组件：MCP 主机（Claude Desktop、VS Code 或类似程序），其中包含 LLM 和 Claude 技能，用于教授 LLM 如何使用这些工具；MCP 应用服务器，一个单独的 Node.js 进程，用于公开工具注册表、打包 React UI 视图并处理与 Elastic 的所有通信；以及 Elastic Stack 本身，其中 Elasticsearch 和 Kibana 用作实时数据和警报后端。

下图展示了用户请求的流程：Claude 会读取相关的技能文件，以了解应调用哪个工具以及如何填充其参数；随后调用该工具，该工具会触发针对 Elasticsearch 和 Kibana 的服务器端查询；最后，Claude 会收到简洁的文本摘要，以及一个以内联方式呈现为交互式小部件的 React UI 资源。

从告警到根本原因：调查工作流

告警规则会告诉您出了问题。ML 模块会告诉您模式。Elastic Workflows 运行诊断，而且是在告警触发的瞬间自动进行。

我们正在发布 Kubernetes 调查工作流（技术预览版）。该工作流可由 Kubernetes 告警触发，并在您打开任何仪表板之前返回结构化的根因摘要。接到通知的 SRE 打开警报后发现调查已经完成。

该工作流程是一个有向图，其中包含数个查询多个数据源的步骤，主要通过 Elasticsearch 查询语言 (ES|QL)，并使用 Elasticsearch 搜索进行 ML 异常查找。if 步骤会根据查询结果进行分支，选择运行哪种证实（ML 内存异常与日志分类），以及是否评估上游运行状况（仅在存在 APM 依赖项时）。AI 步骤出现在三个位置：在非 OOM 路径上对日志模式进行分类、对上游降级与健康状态进行分类，以及最后的 ai.summarize，用于将所有结构化证据综合为根本原因叙述。

调查工作流在实践中是如何运作的

下面的示例执行基于在 Elastic 上运行的 OpenTelemetry Astronomy Shop，有 16 个服务、Kafka、PostgreSQL，均已通过 OTLP 进行了预插桩。除了 Shop 的真实遥测数据之外，我们还注入了合成 OOMKill 级联。该级联通过 EDOT 数据流将合成 K8s 和 APM 信号写入同一个命名空间。该工作流无法区分我们的信号与真实信号，只是对告警进行调查。

告警触发：CrashLoopBackOff —— oteldemo-esyox-default 中的 app-deployment。重启次数：6。

工作流步骤 1 —— 描述 pod 和容器上下文

该工作流查询 K8s 指标以获取重启次数、上次终止原因，以及相对于声明限制的利用率。

结果：上次终止原因 OOMKilled，重启次数为 6。（注意：此 pod/窗口的 kubeletstats 利用率不可用，工作流程将继续正常进行。）

工作流分支：终止原因是 OOMKilled，因此工作流采用内存调查路径，而不是日志调查路径。

工作流步骤 2a —— 查阅 ML 异常结果

该工作流无需重新计算内存趋势，而是查询 ML 异常索引以查找活跃的 k8s_pod_memory_growth 异常。

结果：未发现异常，峰值被标记为负载驱动，而非疑似泄漏。

工作流步骤 3 —— 检查上游服务运行状况

该工作流从 APM service_destination.1m 聚合中枚举上游依赖项，然后将当前错误率和平均延迟与 7 天前的同一小时进行对比。AI 分类步骤将判断上游降级是否先于警报发生。结果：一个上游 api-gateway。当前平均延迟 15.13 ms，错误率 41.26%。基线（168 小时前）：相同。分类：upstream_healthy，处于 5× 错误/3× 延迟阈值以内。已排除上游。

工作流步骤 4 —— 关联最近的 K8s 变更

该命名空间的事件日志显示，Pulled → Created → Started → Killing → BackOff 的紧密循环大约每 60–90 秒重复一次。过去两小时内没有部署或扩展事件。

工作流输出：

根本原因假设（置信度：高）

app-deployment 在内存压力下正在发生 OOMKill。Pod 已重启
6 次，终止原因为 OOMKilled。ML 将内存激增标记为
负载驱动（无泄漏）。上游 api-gateway 当前与 7 天对比状态正常
基线。这是一个资源分配问题——容器的内存
限制对其真实工作集而言过低。

证据：
- 6 次重启，上次终止原因 OOMKilled
- 无 ML 内存增长异常 → leak_suspected=false（负载驱动）
- 上游 API 网关与 7d 基线相比无变化（15.13 毫秒，41.26%）→ 正常运行
- K8s 事件显示密集的 Pulled/Created/Started/Killing/BackOff 循环；
  过去 2 小时内无部署

可能的原因：在负载下，内存限制不足以满足实际工作集的需求。

推荐的后续步骤：
1. 根据观察到的使用情况提高应用部署内存限制
2. 审查应用程序代码以寻找内存优化机会
3. 考虑高负载路径上的优雅降级

下游影响：从 APM 目标指标中未发现任何影响。

上面的输出是您打开警报时的样子 — 不是指向一堆日志或仪表板的链接，而是一个答案。

同样的工作流可作为 MCP 工具，从 Claude Desktop、VS Code 或任何兼容 MCP 的客户端进行访问。当开发人员询问“为什么 checkout 会报错？”在其 IDE 中，智能体调用工作流并内联返回相同的结构化输出，相同的证据、相同的根因，无需离开编辑器。

以下是工作流执行的动画演示：

用于 Kubernetes 调查的可观测性技能

我们还将推出一项全面的调查技能（observability-k8s-investigation），其中编码了用于诊断 Kubernetes 工作负载、节点和控制平面问题的完整协议。这是一种具有明确指导性的调查方法，其中包含经验丰富的 SRE 凭直觉会运用、但很少会记录下来的推理过程。只需让 Kibana 保持最新状态，您就能获得这一功能，因为它已内置于我们的 AI 智能体技能中。它始于可防止最常见误诊的指导原则：

• 缺乏证据并不等于证据。如果日志查询返回零行，请报告 no_logs_available，切勿从空结果推断故障模式。
• OOMKilled 默认并不意味着存在内存泄漏。在断定存在泄漏之前，请将当前使用量与 7 天基线进行比较。可能只是限制设置过小。
• 平均 CPU 指标会掩盖限制。Pod 在平均利用率为 40–60% 时可能看起来很正常，但在 p99 时却会受到严重的限制。请查看最大值和 p95，而不仅仅是平均值。
• 共同症状并非原因。两个服务同时出现性能下降通常存在共同的上游原因。只有当一个服务的性能下降明显早于另一个服务且差异较大时，才能认定因果关系。

在此基础上，该 Skill 包含了一套故障模式分类体系，涵盖工作负载、Node、控制平面、自动扩缩和网络层等 16 种不同的 K8s 故障模式，从 OOMKilled 和 CFS 限流，到准入 Webhook 拦截和 StatefulSet 脑裂均包括在内。每种模式都包含一个用于识别它的关键信号以及一份用于确认它的佐证检查清单。

调查流程遵循结构化的弧线：定位（解析目标 Pod、命名空间、部署）、表征（获取重启次数、终止原因、利用率）、分类（与分类法进行匹配）、证实（拉取事件、日志、APM、基线比较）以及综合（以校准的置信度（高、中或低）生成带有明确证据和建议后续步骤的根因假设）。

当两种失效模式都与证据相符时，该技能会同时指出两者，并说明其认为哪一种是因果原因以及原因所在。当证据模棱两可时，报告会明确指出。“相互竞争的假设也是有效的结果”是一项明确的设计原则，人为制造虚假信心被视为调查本身的失败模式。

开始使用

这些功能基于第 1 部分中所述的 Kubernetes 集成。在仪表板和数据收集运行后：

步骤 1 — 启用调查工作流（技术预览）。从 Kibana 中的工作流页面导入 Kubernetes Crashloop 调查工作流，并可选择将其配置为由告警规则触发。

步骤 2 — 在兼容 MCP 的客户端上安装 MCP 应用（技术预览）。MCP App for Observability 仓库可在 GitHub 上找到（有关下载信息，请参阅 Releases 页面）。安装该应用时，别忘了同时安装并启用其中包含的技能。通过您喜爱的智能体客户端访问 Example MCP App 的工具（说明在上方 GitHub 链接的 README 中）。

步骤 3 — 利用 K8s 调查技能（技术预览版）。如果您使用 Agent Builder，那么这项功能无需开发，因为它已内置于 AI Agent Skills 中。该技能会指导智能体何时以及如何调用底层工具和工作流，从而确保在对话上下文中提供一致的诊断。

下一步

调查工作流可诊断您正在监测的服务中出现的问题。接下来的问题更难：您未监测的服务又该怎么办？

我们正在考虑支持拓扑感知的覆盖智能，通过 Kubernetes API 自动发现部署在集群中的每个工作负载，与流入 Elastic 的遥测数据进行交叉比对，并找出差距。”您有 47 个服务。其中 11 个没有分布式跟踪。这是您风险最大的盲点。“该功能正在考虑之中，可能会在以后的博文中进行介绍。

与此同时，我们正在将工作流扩展至修复方向，不仅是诊断，更是付诸行动：创建附有调查摘要的案例、提议回滚以供人工审批，或在解决根本原因的同时扩展工作负载以争取时间。

如果您目前在 Elastic 上运行 Kubernetes，请告诉我们您在每次事件中都会手动重复哪些调查步骤、您愿意信任工作流提出哪些修复建议，以及我们接下来应该构建哪些 MCP 工具。您可以在此处加入 Elastic 社区讨论。