在第 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 社区讨论。