Elastic 基于 Agentic 架构与 MCP 的 Kubernetes 智能可观测性深度解析

第一章：引言与核心概念

1.1 Agentic 可观测性

Agentic（智能体驱动） 是人工智能领域的一个重要范式，指系统能够自主决策、主动执行、持续迭代以完成复杂任务，而非被动响应用户指令。

传统可观测性工具（如 Kibana Dashboard）是**"人找数据"------工程师发现问题后，手动查询日志、指标、追踪。而 Agentic 可观测性是"数据找人"**------AI Agent 主动监控集群状态，在异常发生时自动展开调查，并给出根因分析。

核心转变：从"工具辅助人工排查" → "AI 自主完成排查闭环"

1.2 MCP（Model Context Protocol）

MCP 是由 Anthropic 提出的模型上下文协议，它标准化了 AI 模型与外部工具/数据源之间的通信方式。

┌─────────────────────────────────────────────────────────────┐
│                    MCP 的核心价值                             │
├─────────────────────────────────────────────────────────────┤
│  1. 统一接口：AI 模型无需为每个工具写适配代码                    │
│  2. 上下文传递：工具返回的结构化数据直接注入对话上下文            │
│  3. 可组合性：多个工具可以链式调用，形成工作流                   │
│  4. 实时渲染：工具返回的不仅是文本，还可以是交互式 UI 组件        │
└─────────────────────────────────────────────────────────────┘

在 Elastic 的场景中，MCP 充当了**"AI 大脑 ↔ 可观测性数据"**之间的桥梁。Claude、Cursor 等 AI 客户端通过 MCP 调用 Elastic 的工具，获取 K8s 集群的实时数据。

1.3 整体架构概览

数据源
Elastic Stack
MCP 层
用户层
Claude Desktop
VS Code / Cursor
其他 MCP 客户端
MCP Host

承载 LLM 和 Skills
MCP App Server

Node.js 进程
Elasticsearch

指标/日志/追踪存储
Kibana

告警规则/可视化
ML Anomaly Detection

异常检测引擎
EDOT Collector

OpenTelemetry 采集器
Kubernetes API
应用 APM 数据

架构说明：

• MCP Host：运行 AI 模型的客户端（如 Claude Desktop），加载 Skills 文件教 AI 如何调用工具
• MCP App Server：Node.js 服务，暴露工具注册表，将 React UI 视图打包为单文件内联渲染
• Elastic Stack：数据存储和计算后端，包括 Elasticsearch（数据）、Kibana（告警/可视化）、ML（异常检测）

---

第二章：MCP App 的六大视图工具详解

Elastic Observability MCP App 提供了 6 个核心工具，每个工具对应一个独立的 React 视图，支持在聊天界面中内联渲染。

2.1 集群健康总览（Cluster Health Rollup）

功能：一键获取集群整体健康状态。

查询示例 ："what's broken?" 或 "give me a status report"

返回内容包含：

维度	说明
整体健康徽章	绿/黄/红三色状态指示
降级服务列表	服务名 + 降级原因
Top Pod 内存消耗者	按内存使用排序的 Pod 列表
异常严重度分布	ML 检测到的异常按级别分类
服务吞吐量	各服务的请求处理速率

自适应渲染逻辑：
APM 可用
K8s 指标可用
ML 作业运行中
信号缺失
用户请求集群健康报告
检测可用数据源
渲染服务健康状态
渲染 Pod/节点上下文
渲染异常检测层
显示"缺少数据"提示
组合为统一视图

设计亮点：

• 渐进式披露：复杂报告采用"摘要 + 展开详情"模式，用户自主控制信息密度
• 智能引导：每个视图附带"下一步操作建议"按钮，降低用户决策成本

---

2.2 服务依赖图谱（Service Dependency Graph）

功能：可视化展示服务间的调用拓扑关系。

查询示例 ："what calls checkout?" 或 "show me the topology"

图谱包含信息：

• 上游调用方（Upstream Callers）
• 下游依赖（Downstream Dependencies）
• 协议类型（HTTP/gRPC 等）
• 调用量（Call Volume）
• 延迟分布（Latency per Edge）

交互特性：

• 悬停高亮完整调用链路
• 支持缩放（Zoom）和平移（Pan）
• 点击节点查看详情

下游
目标
上游
HTTP 500/s
gRPC 300/s
HTTP 1.2k/s
gRPC 800/s
HTTP 600/s
API Gateway
Auth Service
Frontend
Checkout Service
Catalog Service
Payment Service

说明 ：依赖图谱的数据来源于 APM（Application Performance Monitoring）的 service_destination 聚合数据。Elastic APM Agent 或 OpenTelemetry Collector 在每个服务调用时注入追踪信息（Trace ID、Span ID），服务端根据这些 Span 的父子关系重建调用拓扑。

---

2.3 异常详情（Anomaly Details）

功能：展示机器学习异常检测的结果，并自动选择最合适的视图模式。

查询示例 ："what's anomalous?" 或 "is anything unusual in checkout?"

两种自动切换的视图模式：

模式	触发条件	展示内容
概览模式	多个实体受影响	严重度计数、受影响实体列表、按作业分类的异常分布
详情模式	单个实体聚焦	异常分数、实际值 vs 典型值对比条、偏差百分比、时间序列图

关键概念解释：

什么是 ML 异常检测？

Elastic 的 ML 模块使用无监督学习算法（如时间序列分解、贝叶斯推断）建立每个指标的正常行为基线。当实际值偏离基线超过阈值时，标记为异常。

异常分数计算逻辑：
┌────────────────────────────────────────┐
│  异常分数 = f(偏离程度, 持续时间, 历史模式) │
│                                        │
│  • 偏离程度：实际值与基线的差异倍数        │
│  • 持续时间：异常持续的时间长度            │
│  • 历史模式：该时段历史上是否常出现异常     │
└────────────────────────────────────────┘

重要澄清 ：这不是对原始数据的 ESQL 查询，而是对预计算异常结果索引 （.ml-anomalies-*）的查询。异常检测作业需要预先配置并启用（Elastic Kubernetes 集成自带多个预设作业）。
原始指标数据

k8s.pod.memory.usage
ML 异常检测作业

k8s_pod_memory_growth
异常结果索引

.ml-anomalies-*
MCP 工具查询
AI 解释并渲染视图

---

2.4 观测工具（Observe）

功能 ：Agent 访问 Elastic 数据的主要入口，一个工具覆盖三种使用场景。

三种模式对比：

场景	查询示例	返回视图
一次性查询	"what is the network throughput of each kubernetes cluster"	结果表格或图表
阈值监控	"tell me when memory drops below 80MB"	实时趋势图 + 当前/峰值/基线统计
异常监控	"watch the frontend memory for anything unusual for the next 10 minutes"	严重度评分触发卡片，阻塞等待条件触发

模式自适应渲染逻辑：
一次性查询
阈值条件
异常检测
用户 Observe 请求
解析意图
结果表格/图表
实时趋势图

当前值/峰值/基线
严重度评分卡片

阻塞等待触发
内联渲染

技术细节 ：阈值监控和异常监控模式使用了长轮询或 WebSocket机制，MCP Server 保持连接直到条件满足或超时。这要求 MCP 客户端支持异步/流式响应。

---

2.5 爆炸半径分析（Blast Radius）

功能：评估某个节点故障时的影响范围。

查询示例 ："what happens if this node goes down?"

可视化设计：

• 中心：目标故障节点
• 红色环：完全中断的 Deployment（所有副本都在该节点）
• 琥珀色环：降级的 Deployment（部分副本受影响）
• 灰色环：不受影响的 Deployment

关键分析指标：
风险评估
单副本 Deployment 检测
⚠️ 单点故障标记
Pod 重新调度可行性
✅ 可调度 / ❌ 资源不足
爆炸半径分析
所有副本在此节点
部分副本在此节点
无副本在此节点
目标节点

Node-X
Deployment 分布分析
🔴 完全中断

需立即处理
🟡 降级运行

剩余副本承受全部负载
⚪ 不受影响

设计原理 ：

爆炸半径分析基于 Kubernetes 的 Pod 调度信息 （spec.nodeName）和 Deployment 副本分布。通过查询 Elasticsearch 中的 Kubernetes 状态数据，计算每个 Deployment 在目标节点上的副本占比。

优化建议：原文提到"rescheduling feasibility（重新调度可行性）"，但未详细说明判断逻辑。实际实现中应检查：

1. 集群剩余资源是否足够容纳迁移的 Pod
2. 是否存在 Pod 亲和性/反亲和性约束阻止调度
3. 节点污点（Taint）与 Pod 容忍度（Toleration）匹配情况

---

2.6 告警管理（Alert Management）

功能：创建、列出、查看、删除 Kibana 告警规则。

完整使用流程：
Kibana MCP Server AI Agent 用户 Kibana MCP Server AI Agent 用户 "alert me if frontend memory goes above 75MB" 调用 Observe 获取基线数据 查询当前内存趋势 返回基线数据 确认阈值合理性 调用 Alert Management 创建规则 POST /api/alerting/rule 返回规则 ID 和状态 规则创建成功 展示规则卡片 + 后续操作建议

创建的规则特性：

• 持久化：Kibana 的 Saved Object，对话结束后继续运行
• 实时规则卡片：展示规则名、条件、时间窗口、检查间隔、KQL 过滤条件、标签
• 智能后续动作：验证规则、观察指标稳定化、检查集群健康

重要说明 ：这里创建的是 Kibana Alerting Rule，不是一次性的查询。它会在后台持续评估，条件触发时通过配置的渠道（邮件、Slack、PagerDuty 等）通知。

---

第三章：MCP App 技术架构深度解析

3.1 组件架构

Elastic Stack 层
MCP App Server 层
MCP Host 层
读取
指导
Query
Manage
Detect
Build
Render
LLM Core
Skills .zip
Context
Node.js Server
工具注册表
React UI
内部工具
vite-plugin
Elasticsearch
Kibana Alerting
ML API

3.2 工具分组策略

工具按部署依赖的后端能力分组，避免运行时能力缺失：

分组	依赖	工具
Universal	基础 Elastic Stack	Cluster Health, Observe, Alert Management
APM-dependent	APM 数据接入	Service Dependency Graph, Blast Radius (部分)
K8s-dependent	Kubernetes 集成	所有 K8s 相关工具
ML-dependent	ML 模块启用	Anomaly Details

设计优势：

• 前置声明：Agent 和用户在使用前就知道哪些工具可用
• 优雅降级：缺少某类数据时，视图明确告知"缺少 xxx 信号"，而非报错

3.3 Skills 机制

Skills 是教 AI Agent 何时以及如何调用工具的指令文件。

Skill 文件结构（observability-k8s-investigation）：
┌─────────────────────────────────────────┐
│ 1. 治理原则（防止误诊）                   │
│    • 无证据 ≠ 证据不存在                  │
│    • OOMKilled ≠ 内存泄漏                 │
│    • 平均 CPU 隐藏节流问题                │
│    • 共症状 ≠ 因果关系                    │
│                                         │
│ 2. 故障模式分类学（16 种 K8s 故障模式）    │
│    • 工作负载层：OOMKilled, CrashLoopBackOff│
│    • 节点层：CFS 节流, 磁盘压力           │
│    • 控制平面：准入 Webhook 阻塞           │
│    • 自动扩缩容：HPA 失效                 │
│    • 网络层：DNS 解析失败, 服务发现异常     │
│                                         │
│ 3. 调查流程（结构化弧线）                  │
│    Orient → Characterize → Classify →    │
│    Corroborate → Synthesize              │
└─────────────────────────────────────────┘

3.4 请求生命周期

React UI 资源 Elasticsearch MCP App Server Skills 文件 Claude (MCP Host) 用户 React UI 资源 Elasticsearch MCP App Server Skills 文件 Claude (MCP Host) 用户 "Show me service dependencies of frontend" 读取相关 Skill 文件 确定调用 service_dependency_graph 工具 参数：service_name="frontend" 调用工具 查询 APM service_destination 聚合 返回拓扑数据 生成文本摘要 + 构建 React UI 返回 {text_summary, ui_resource} 内联渲染交互式组件 展示可缩放/悬停的依赖图谱

---

第四章：自动化根因分析工作流（Investigation Workflows）

4.1 工作流核心思想

告警告诉你"什么出了问题"，ML 告诉你"模式是什么"，工作流告诉你"为什么"和"怎么办"。
告警触发
工作流自动执行
多数据源查询
AI 分析推理
结构化根因报告
SRE 收到通知时

调查已完成

4.2 工作流架构：有向图

Kubernetes Investigation Workflow 是一个有向图（Directed Graph），节点代表调查步骤，边代表决策分支。
OOMKilled
其他原因
存在异常
无异常
是
否
告警触发

CrashLoopBackOff
Step 1: 特征化 Pod 上下文
终止原因?
Step 2a: 查询 ML 异常
Step 2b: 日志分类
ML 异常结果?
标记为疑似泄漏
标记为负载驱动
AI 分类日志模式
存在 APM 依赖?
Step 3: 检查上游服务健康
跳过上游检查
AI 分类: 上游健康 vs 降级
Step 4: 关联 K8s 变更事件
AI 综合所有证据
输出根因假设

置信度: 高/中/低

4.3 工作流执行实例深度分析

场景：OpenTelemetry Astronomy Shop（16 个服务 + Kafka + PostgreSQL），注入合成 OOMKill 级联。

Step 1：特征化 Pod 和容器上下文

查询内容：

• Pod 重启次数（kubernetes.container.restarts）
• 最后终止原因（kubernetes.container.last_termination_reason）
• 资源利用率 vs 声明限制

结果：

Last termination reason: OOMKilled
Restart count: 6
Utilization vs limits: kubeletstats 数据不可用（优雅降级）

关键设计 ：当某个数据源不可用时，工作流继续执行而非中断。这是生产级系统的必备特性------真实环境中数据缺失是常态。

分支决策：终止原因为 OOMKilled → 走内存调查路径（而非日志调查路径）

Step 2a：查询 ML 异常结果

查询逻辑 ：查询 .ml-anomalies-* 索引，查找 k8s_pod_memory_growth 作业在目标 Pod 上的活跃异常。

结果：

ML 异常状态: 无活跃异常
结论: 内存尖峰为负载驱动，非疑似泄漏

原理说明：

• 内存泄漏特征 ：内存持续增长，ML 的 memory_growth 作业会检测到趋势性异常
• 负载驱动特征：内存突增但与请求量正相关，无持续增长趋势，ML 不会标记

Step 3：检查上游服务健康

查询逻辑：

1. 从 APM service_destination.1m 聚合中枚举上游依赖
2. 对比当前错误率和平均延迟 vs 7 天前同一时段

结果：

上游服务: api-gateway
当前平均延迟: 15.13 ms
当前错误率: 41.26%
7 天前基线: 平均延迟 15.13 ms, 错误率 41.26%

AI 分类逻辑：

if (当前错误率 <= 基线错误率 × 5) 且 (当前延迟 <= 基线延迟 × 3):
    分类 = "upstream_healthy"
else:
    分类 = "upstream_degraded"

结论 ：upstream_healthy --- 在 5× 错误率 / 3× 延迟阈值内，排除上游因素。

优化建议 ：原文中错误率 41.26% 看起来很高，但基线也是 41.26%，说明这是该服务的正常错误率（可能是预期内的 4xx 响应）。这引出一个重要原则：绝对值无意义，变化量才有意义。建议在工作流中明确展示"变化倍数"而非原始值。

Step 4：关联近期 K8s 变更

事件日志分析：

时间线模式：
Pulled → Created → Started → Killing → BackOff
循环周期：约 60-90 秒

部署历史：

过去 2 小时内无 Deployment 变更或扩缩容事件

模式解读：

• 紧凑的循环周期（60-90 秒）表明 Pod 启动后迅速被 OOMKill
• 无部署变更排除了"新版本引入问题"的可能性

---

4.4 最终输出报告

┌─────────────────────────────────────────────────────────────┐
│  ROOT CAUSE HYPOTHESIS (confidence: high)                   │
├─────────────────────────────────────────────────────────────┤
│  app-deployment 因内存压力触发 OOMKill。Pod 已重启 6 次，      │
│  最后终止原因为 OOMKilled。ML 将内存尖峰标记为负载驱动（非泄   │
│  漏）。上游 api-gateway 与 7 天基线一致（15.13 ms, 41.26%）。 │
│  这是资源分配问题------容器内存限制低于实际工作集需求。            │
├─────────────────────────────────────────────────────────────┤
│  Evidence:                                                  │
│  • 6 次重启，最后终止原因 OOMKilled                          │
│  • 无 ML memory-growth 异常 → leak_suspected=false           │
│  • 上游 api-gateway 与 7d 基线一致 → healthy                 │
│  • K8s 事件显示紧凑的 Pulled/Created/Started/Killing/BackOff │
│    循环；过去 2h 无部署变更                                   │
├─────────────────────────────────────────────────────────────┤
│  Likely cause: 内存限制不足以支撑实际负载下的工作集            │
├─────────────────────────────────────────────────────────────┤
│  Recommended next steps:                                    │
│  1. 根据观测到的使用量提升 app-deployment 内存限制            │
│  2. 审查应用代码的内存优化空间                                │
│  3. 考虑在高负载路径上实现优雅降级                            │
├─────────────────────────────────────────────────────────────┤
│  Downstream impact: APM destination 指标未识别到下游影响       │
└─────────────────────────────────────────────────────────────┘

设计哲学 ：当 SRE 收到告警通知时，打开看到的不是日志链接或 Dashboard 链接，而是一个完整的答案。

---

第五章：调查技能（Investigation Skill）深度解析

5.1 治理原则：防止最常见的误诊

Elastic 的 K8s 调查 Skill 编码了资深 SRE 的直觉性推理，将其显性化为可执行规则：

原则 1：无证据 ≠ 证据不存在

❌ 错误："日志查询返回 0 行，说明服务没有输出日志"
✅ 正确："log_queries_returned_zero_rows → 报告 no_logs_available"

原理：日志可能因采集器故障、过滤规则、保留策略等原因缺失。从缺失推断行为是逻辑谬误。

原则 2：OOMKilled ≠ 内存泄漏

❌ 错误："Pod 被 OOMKill 了，一定是内存泄漏"
✅ 正确："先对比当前使用量 vs 7 天基线，再判断是泄漏还是限制不足"

原理 ：OOMKill 只是结果，原因可能是：

• 内存限制设置过低（最常见）
• 突发流量导致正常内存增长
• 内存泄漏（需 ML 趋势异常确认）
• 内存碎片化（较少见）

原则 3：平均 CPU 隐藏节流

❌ 错误："Pod CPU 平均使用率 40%，很健康"
✅ 正确："检查 max 和 p95 CPU 使用率，同时查看 CFS throttling 指标"

原理：Linux CFS（Completely Fair Scheduler）调度器以 100ms 为周期分配 CPU 时间。如果 Pod 的 CPU limit 为 1 核，但在某 100ms 周期内需要 2 核，则该周期内 50% 的请求会被节流（throttle）。平均到 1 分钟可能只有 40%，但用户体验是间歇性卡顿。
渲染错误: Mermaid 渲染失败: Parse error on line 8: ...> E[显示 40% 使用率
"看起来很健康"] end -----------------------^ Expecting 'SQE', 'DOUBLECIRCLEEND', 'PE', '-)', 'STADIUMEND', 'SUBROUTINEEND', 'PIPE', 'CYLINDEREND', 'DIAMOND_STOP', 'TAGEND', 'TRAPEND', 'INVTRAPEND', 'UNICODE_TEXT', 'TEXT', 'TAGSTART', got 'STR'

关键指标 ：container_cpu_cfs_throttled_seconds_total（累计节流时间）

原则 4：共症状 ≠ 因果关系

❌ 错误："Service A 和 Service B 同时降级，A 导致了 B"
✅ 正确："两个服务同时降级通常共享上游原因。仅当 A 的降级明显先于 B，
         且时间差足够大时，才可归因"

原理：相关性 ≠ 因果性。共因（Common Cause）比因果链更常见。

5.2 故障模式分类学

Skill 覆盖了 16 种 K8s 故障模式，横跨 5 个层次：
K8s 故障模式

16 种
工作负载层
OOMKilled
CrashLoopBackOff
ImagePullBackOff
Evicted
节点层
CFS Throttling
Disk Pressure
Memory Pressure
PID Pressure
控制平面
Admission Webhook 阻塞
API Server 不可用
etcd 性能退化
自动扩缩容
HPA 失效
VPA 建议未生效
Cluster Autoscaler 延迟
网络层
DNS 解析失败
服务发现异常
StatefulSet Split-Brain

每种模式包含：

• 关键信号（Pivotal Signal）：唯一标识该故障的指标/事件
• 确证清单（Corroboration Checklist）：排除其他可能性的验证步骤

5.3 调查流程：结构化弧线

Orient

定向
Characterize

特征化
Classify

分类
Corroborate

确证
Synthesize

综合
确定目标 Pod
确定命名空间
确定 Deployment
获取重启次数
获取终止原因
获取资源利用率
匹配故障分类学
拉取事件
拉取日志
拉取 APM 数据
基线对比
产生根因假设
校准置信度

高/中/低
明确证据
推荐下一步

5.4 置信度校准机制

核心原则："竞争假设是有效输出"------制造虚假置信度本身就是调查的失败模式。

置信度	含义	示例
High	单一故障模式完美匹配所有证据，无矛盾	OOMKilled + 无泄漏 + 健康上游 + 无变更
Medium	主要证据支持，但存在少量不确定性	日志显示异常但 ML 数据缺失
Low	多个假设均部分匹配，或关键证据缺失	同时符合 OOM 和节流特征

当证据模糊时的输出示例：

Competing Hypotheses:
1. 内存限制不足 (置信度: medium) --- 符合 OOMKilled 和重启模式
2. 应用内存泄漏 (置信度: low) --- 缺少 7 天基线数据，无法排除

建议: 提升内存限制后观察 24 小时，若继续 OOMKill 则启用 ML 内存增长检测

---

第六章：错误纠正与优化建议

6.1 原文潜在问题分析

问题 1：Blast Radius 的"重新调度可行性"缺乏判断标准

原文描述 ："A floating summary card shows pods at risk and rescheduling feasibility"

问题：未说明如何判断"可行性"。

优化方案：
否
是
否
是
否
是
评估重新调度可行性
节点剩余资源

是否足够?
❌ 不可调度

需先扩容集群
Pod 亲和性约束

是否满足?
❌ 约束冲突

需调整亲和性规则
节点污点

是否兼容?
❌ 污点不匹配

需添加容忍度或选择其他节点
✅ 可调度

预计恢复时间: X 秒

问题 2：Observe 的"阻塞等待"模式缺少超时和取消机制说明

原文描述 ："it blocks until the condition fires or the window expires"

问题：未说明：

• 最大阻塞时长是多少？
• 用户如何取消阻塞？
• 超时后的行为是什么？

优化方案：

Observe 监控模式设计：
┌─────────────────────────────────────────┐
│  最大阻塞时长: 10 分钟（可配置）           │
│  检查间隔: 10 秒                         │
│  取消方式: 用户发送新消息或点击取消按钮     │
│  超时行为: 返回"条件未在窗口期内触发"      │
│  资源占用: 长轮询连接，占用 1 个 HTTP 连接 │
└─────────────────────────────────────────┘

问题 3：ML 异常检测的误报率未提及

原文描述：ML 异常检测作为核心证据来源，但未讨论其局限性。

优化方案：应补充 ML 的适用边界：

ML 异常检测的局限性：
1. 冷启动问题：新部署的服务需要至少 2-4 周数据建立基线
2. 季节性模式：需要至少一个完整周期（如一周）才能识别
3. 变更影响：Deployment 更新后基线需要重新学习
4. 阈值敏感度：过于敏感会导致告警疲劳，过于迟钝会漏报

问题 4：Workflow 中的 AI 分类步骤缺乏可解释性

原文描述 ："An AI classification step decides whether upstream degradation preceded the alert"

问题：AI 的决策过程是黑盒，不利于审计和调试。

优化方案：

AI 分类步骤应输出：
┌─────────────────────────────────────────┐
│ Classification: upstream_healthy        │
│ Reasoning:                              │
│   • 当前错误率 41.26% <= 基线 41.26% × 5 │
│   • 当前延迟 15.13ms <= 基线 15.13ms × 3  │
│   • 变化倍数: 错误率 1.0×, 延迟 1.0×      │
│ Thresholds: error_rate_multiplier=5,    │
│             latency_multiplier=3        │
└─────────────────────────────────────────┘

6.2 架构层面的优化建议

建议 1：增加缓存层减少 ES 查询压力

缓存命中
缓存未命中
MCP App Server
本地缓存

Redis/Memory
直接返回
Elasticsearch

适用场景：集群健康总览、服务依赖图谱等变化较慢的数据。

建议 2：引入请求去重机制

当多个用户同时询问相似问题时，避免重复查询 ES：

请求指纹 = hash(工具名 + 参数 + 时间窗口)
┌─────────────────────────────────────────┐
│  if 指纹存在于进行中请求队列:            │
│      等待该请求完成，共享结果             │
│  else:                                  │
│      发起新查询，加入队列                 │
└─────────────────────────────────────────┘

建议 3：增加调查历史的上下文传递

调查历史存储 Agent 用户 调查历史存储 Agent 用户 "Why is checkout erroring?" 查询该服务的近期调查记录 返回 30 分钟前的 OOM 调查结论 判断是否为同一问题的复发 "checkout 在 30 分钟前因内存限制不足 OOM， 建议检查内存限制是否已调整"

---

第七章：快速入门指南

7.1 前置条件

开始
Part 1 完成

K8s 集成 + EDOT Collector
数据流入 Elasticsearch
Dashboard 可正常查看
启用 ML 异常检测作业
开始配置 Agentic 能力

7.2 三步启用

Step 1：启用调查工作流（技术预览）

1. 进入 Kibana → Workflows 页面
2. 导入 Kubernetes Crashloop Investigation Workflow
3. （可选）配置为告警规则触发器

Step 2：安装 MCP App

1. 访问 GitHub 仓库：Elastic MCP App for Observability
2. 从 Releases 页面下载
3. 安装并启用附带的 Skills 文件
4. 在 Claude Desktop / VS Code 中配置 MCP Server

Step 3：使用 K8s 调查 Skill

• 如果使用 Agent Builder：Skill 已内置，自动可用
• 如果使用 自定义 Agent ：手动导入 observability-k8s-investigation Skill

7.3 典型使用场景

场景	用户输入	预期输出
健康检查	"what's broken?"	集群健康总览视图
拓扑分析	"show me the topology"	服务依赖图谱
异常调查	"what's anomalous?"	ML 异常详情
实时监控	"watch frontend memory for 10 min"	实时趋势图
风险评估	"what happens if node-X goes down?"	爆炸半径图
告警创建	"alert me if memory > 75MB"	持久化告警规则
根因分析	"why is checkout erroring?"	结构化调查报告

---

第八章：总结与展望

8.1 核心价值总结

Agentic 可观测性
传统可观测性
效率提升 6-12×
人工发现告警
手动查询多数据源
人工关联分析
经验判断根因
平均 MTTR: 30-60 分钟
告警自动触发工作流
AI 并行查询多数据源
结构化推理引擎
置信度校准的报告
平均 MTTR: 5-10 分钟

8.2 关键设计原则

1. 渐进式披露：信息分层展示，不 overwhelm 用户
2. 优雅降级：数据缺失时不中断，明确告知缺失项
3. 可解释性：每个结论附带证据链，避免黑盒
4. 置信度校准：不制造虚假确定性，承认不确定性
5. 上下文内完成：在聊天/IDE 内完成全部操作，无需切换工具

8.3 未来演进方向

方向	描述
自动修复	从"根因报告"扩展到"自动执行修复建议"
预测性告警	基于趋势预测在故障发生前预警
跨集群关联	多集群场景下的全局根因分析
自定义 Skill	允许用户定义自己的调查流程和故障模式

这不是简单的"AI + 监控"，而是一套将资深 SRE 经验编码为可执行协议、通过 MCP 标准化接口让 AI Agent 自主完成调查闭环的工程体系。