用途
该技能用于对出现性能下降或可疑的服务进行端到端排查与分诊：判断服务是健康、降级还是不健康，并说明原因。分诊按照信号层级而非清单进行：SLO 与告警定义服务是否未履行约定，从追踪数据推导的金色信号描述其如何失败，依赖与基础设施解释失败来自哪里，日志提供写入事件响应通道的说明。沿着层级向下调查，直到证据足以支持结论为止。
主要能力
- 回答“服务 X 是否健康？”并给出结论与证据。
- 回答“服务 X 为什么慢/报错/安静？”，将变化定位到服务本身、某个依赖或其基础设施。
- 在事件期间读取 SLO 状态、燃烧率与剩余错误预算。
- 确定当前哪些告警规则适用于某服务，包括全服务规则。
- 将嘈杂日志流收敛为解释性能下降的失败。
- 识别是哪个属性（版本、主机、Pod、区域、路由）区分出失败或缓慢的子群体。
- 区分健康服务与没有遥测数据的服务。
使用方式与环境
该技能通过 elastic CLI 执行 Elasticsearch 操作。如果未安装 elastic CLI，应告知用户其用途，不应猜测凭据、直接调用 HTTP API 或尝试其他绕过方式。技能中的操作以 HTTP 简写形式引用（如 GET /、GET /_cat/indices、POST /_query），操作表将每个简写映射为等价的 elastic CLI 命令，应使用 CLI 而非直接调用 HTTP API。
所有分析以 ES|QL（POST /_query）或 Kibana Observability API 表达。不使用 Query DSL，也不使用 ES|QL 的 KQL 搜索函数，谓词应原生表达（如 WHERE service.name == "checkout"）。
当用户已在问题中提供证据（指标值、计数、状态原因、日志行、告警负载、配置）时，可直接根据该证据推理并给出结论。若确实需要用户未提供的数据，仍应说明会检查什么以及如何检查——指出能解决该问题的具体查询、索引与字段——然后请求进行 CLI 设置。
信号层级
信号之间经常冲突，该层级决定哪个信号优先：
- SLO 状态与燃烧率：当存在 SLO 时具有权威性，它们编码了该服务“良好”的约定定义。
- 活跃告警规则：当没有覆盖症状的 SLO 时具有权威性，来源于 Alerting API。
- 错误率、延迟、吞吐量：描述降级情况，仅当以上都不存在时具有决定性。
- 依赖健康：定位上游或下游原因，本身不设定结论。
- 机器学习异常：相对于学习基线的偏差，而非相对于目标，用于佐证并限定时间范围。
- 基础设施（CPU、内存、OOM）：解释机制。金色信号健康的饱和 Pod 是风险，不是故障。
- 日志：用于解释，从不用于决策。日志量不等于健康。
冲突规则包括：SLO 健康但延迟升高则视为预算内的降级，结论跟随 SLO；SLO 被违反但当前窗口指标正常则信任 SLO 并检查其窗口；告警触发但未定义 SLO 则告警即为结论；日志嘈杂但金色信号平稳则不算降级；吞吐量崩溃但错误率平稳则先看上游；任何查询返回零行即为数据缺失，绝不能将沉默转换为健康。
数据来源
该技能主要面向 OTel 原生数据流：追踪（traces-.otel-）、日志（logs-.otel-）、原始指标（metrics-.otel-）、服务清单（metrics-service_summary.1m.otel-*）、事务汇总、依赖汇总、Kubernetes 相关指标以及主机指标。service.name 在追踪、指标与日志上都有值，因此是三者之间的连接键。classic Elastic APM agent 使用不同字段名，相关配方对其返回零行，此时应报告实际摄取路径，而不能从沉默中得出结论。
部分 ES|QL 功能（FORK、CATEGORIZE、TS）在不同部署类型与版本上可用性不同，应根据 GET / 结果判断，并在功能不可用时说明并采用回退方案，而不是报告“无数据”。CATEGORIZE 需要 Platinum 许可。
排查流程
- 固定服务与时间窗口，通过 POST /_query 确认服务确实存在于遥测中。
- 读取 SLO 状态与燃烧率，判断是否存在约定契约以及是否被违反。
- 获取适用的告警规则及其执行状态，注意全服务规则。
- 若存在机器学习作业，检查异常并利用其时间窗口缩小后续调查范围。
- 测量金色信号，对比当前窗口与等长的前一窗口。
- 依次定位依赖、子群体与基础设施，并检查近期变更（如部署注解）。
- 当 Kubernetes 分支显示饱和、重启或 OOM 时，机制已确立，进一步诊断（如 Pod 为何被杀死、节点是否有压力、发布是否卡住）应交由 observability-k8s-investigation 技能处理。
- 用日志解释原因，按 service.name 或 trace.id 限定范围。
输出纪律
提交证据最支持的结论，不要为显得谨慎而降低置信度。结论必须为健康、降级或不健康三者之一，并给出原因。置信度只在结论中陈述一次。不得超出证据进行推测，未测量到的机制不应出现在答案中。数据缺失应作为缺失报告，零行不代表健康。不要赘述、不要重复问题，不要以“需要我继续深挖吗”之类的问题结尾，可执行的后续事项应作为建议列出。
适用场景与限制
适用于使用 Elastic 可观测性数据（OTel 原生流、APM、Kibana Observability API）并对服务进行 SRE 分诊的场景。该技能只读取 SLO 与告警状态，编写和调优 SLO 定义、燃烧率规则与告警阈值应使用 observability-service-reliability 技能。它检查 Kubernetes 托管服务是否饱和，但不诊断其背后的 Pod 或节点为何失败。若未安装 elastic CLI，则无法查询集群，但仍可在已有证据基础上进行分析。