1. 基本信息
| 项目 | 内容 | 数据来源 |
|---|---|---|
| 名称 | service-health（SKILL.md 内部标识符为 observability-service-health，正文标题 “APM Service Health”） |
仓库文件 |
| 作者/维护者 | Elastic（elastic/agent-skills 官方仓库） |
GitHub API |
| 来源链接 | https://github.com/elastic/agent-skills/tree/main/skills/observability/service-health | — |
| 许可证 | Apache License 2.0（仓库整体） | GitHub API |
| GitHub Stars / Forks | 所属仓库 545★ / 44 forks（注：该数字属整个技能合集，不代表本技能个体热度，仅供了解所属仓库规模） | GitHub API |
| 最新版本 | SKILL.md 标注 v0.1.0 | 仓库文件 |
| 安装方式 | npx skills add elastic/agent-skills --skill observability-service-health，或 Claude Code / GitHub Copilot 插件市场安装 observability 技能组 |
仓库文档 |
2. 功能介绍与亮点
service-health 是 Elastic 官方出品的 APM 服务健康诊断技能，把“这个服务现在健康吗”这类排查问题固化成一套结构化的 7 步工作流：
- 确认服务与时间范围——从请求中解析目标服务，未指定时间范围则默认最近 1 小时
- 检查 SLO 与告警——调用 Kibana SLO API 取错误预算/燃尽率状态，调用 Alerting API 取当前生效的告警规则
- 检查 ML 异常检测——若已配置异常检测作业，读取延迟/吞吐量/错误率的异常评分
- 用 ES|QL 查询核心指标——吞吐量、延迟（avg/p95/p99）、错误率
- 评估依赖服务健康度——用 ES|QL 聚合或 Kibana 路由取下游依赖的延迟与错误率
- 关联基础设施与日志——内置
apm-correlations.js脚本自动找出与高延迟/失败请求相关的属性（如 pod、host、版本号），再据此过滤基础设施指标（CPU/内存/OOM）与日志 - 汇总结论——给出“健康 / 降级 / 不健康”判断及具体排查建议
亮点：附带两个可直接运行的 Node.js 脚本（apm-correlations.js 约 13KB、辅助库 kibana-client.js 约 7KB，均用原生 fetch()，无需额外 npm install），并非纯文档型技能——关联分析优先走 Kibana 内部 API，不可用时自动降级到 Elasticsearch significant_terms 聚合。SKILL.md 另含 4 个完整实操示例（ES|QL 查询模板、“服务 X 健康吗”、“服务 Y 为什么变慢”、跨 OpenTelemetry 资源属性关联基础设施）。2026-03-16 Elastic Observability Labs 官方博客（作者 Bahubali Shetti）将其列为 observability 技能系列的第四个工作流并专门介绍。与同仓库的 manage-slos（定义 SLO）、logs-search（日志排查）构成互补的可观测性工具组。
3. 适用场景
固定分类：DevOps 与基础设施
- 生产环境出现“这个服务是否健康”疑问时，需要 agent 综合 SLO、告警、ML 异常、延迟、错误率、依赖、基础设施等多信号给出结论的 SRE / DevOps 工程师
- 排查“为什么服务突然变慢或报错变多”、希望 agent 自动关联出可疑属性（host / pod / 版本）而非逐个人工假设排查的运维人员
- 已用 OpenTelemetry（EDOT）或经典 APM Agent 采集数据、并部署了 SLO 与告警规则的团队，想把值班时“人工翻多个仪表盘”的步骤交给 agent 代劳
4. 跨 Agent 兼容性
- Claude Code：原生支持——官方插件市场
claude plugin install observability@elastic-agent-skills - Codex：支持——仓库
npx skills安装工具的“受支持 agent”列表明确列出 codex，对应安装目录.agents/skills - OpenClaw：未验证——官方材料与安装工具支持列表均未提及
- Hermes Agent：未验证——同上，官方材料未提及
5. 推荐理由
排查“服务是不是出问题了”是 SRE 日常最耗时的任务之一——SLO 要看、告警要查、延迟错误率要拉数据，还得猜是不是基础设施或某个依赖在拖累。这个技能把这套多信号综合判断流程连同自带的自动关联脚本一起打包，agent 能直接给出“健康 / 降级 / 不健康”的结论和下一步排查建议，而不是简单转述某一项孤立指标。对已经在用 Elastic Observability 的团队，这是把值班时最常被问到的“这个服务还好吗”交给 agent 处理的现成方案。
6. 评分
| 维度 | 分数 | 说明 |
|---|---|---|
| 受欢迎程度 | 8 | Elastic 为可观测性与安全领域一线上市公司（NYSE: ESTC）官方出品；2026-03-16 Elastic Observability Labs 官方博客（作者 Bahubali Shetti）专文介绍该技能“通过整合 APM、基础设施指标、日志、SLO 和告警等信号，提供服务健康的统一视图”；Elastic 官方文档站点亦收录其所属的 observability 技能分类 |
| 可用性 | 8 | SKILL.md（约 15KB）含完整 7 步工作流表格与 4 个实操示例；配套脚本用原生 fetch() 实现，无第三方 npm 依赖，无需额外安装步骤；但需自行配置 KIBANA_URL/KIBANA_API_KEY 等连接凭据，且要求 Elastic 部署已启用 APM/SLO/告警等前置数据，非单文件复制即用；所属仓库最近一次提交 2026-07-22，整体活跃维护 |
| 安全性 | 8 | 见下方安全检查清单 |
| 综合评分 | 8.0 | 三项均值 |
安全检查清单：
| 检查项 | 结果 |
|---|---|
| ① Shell 命令执行 | 有代码执行：运行 node apm-correlations.js 脚本，功能范围明确限定在只读的 Kibana/Elasticsearch API 查询，不涉及通用 shell 权限或写操作 |
| ② 运行时联网外发 | 仅连接用户自己配置的 KIBANA_URL/ELASTICSEARCH_URL，不向未声明的第三方外发数据 |
| ③ API key/凭据 | 需要 KIBANA_API_KEY（或用户名密码），ELASTICSEARCH_API_KEY 作脚本内部降级兜底，均通过环境变量传入，脚本本身不落盘存储 |
| ④ 可疑指令 | 通读 SKILL.md 与两个脚本源码，未见混淆代码、prompt injection 或隐蔽外发逻辑 |
| ⑤ 作者/组织信誉 | Elastic 官方（elastic.co，纽交所上市公司 ESTC） |
| ⑥ License | 仓库整体 Apache License 2.0，GitHub API 确认，口径清晰 |
| ⑦ 维护时间 | 该子技能自 2026-03-13 首次发布后功能未再变更（仍为 v0.1.0），但所属仓库最近一次提交为 2026-07-22，整体仍处于活跃维护状态 |
7. 跟同类 Skills 相比的优势
| 项目 | 定位 | 差异点 |
|---|---|---|
| service-health（本推荐） | Elastic 官方：综合 SLO、告警、ML 异常、延迟错误率、依赖、日志多信号，直接给出健康结论与排查建议 | 唯一“读取已有信号、输出诊断结论”的技能；内置脚本自动定位与异常请求相关的可疑属性 |
| manage-slos（elastic/agent-skills，同仓库） | 定义与管理 SLO 本身——SLI 类型、错误预算、生命周期 | 负责设定“健康的度量目标”，是 service-health 读取的数据源之一，二者互补而非竞争 |
| dd-apm（datadog-labs/agent-skills） | Datadog 官方 APM 技能，聚焦分布式追踪埋点与环境适配路由（K8s/Linux 埋点选型、反模式警告） | 解决“怎么把埋点做对”，属于数据采集层；不做基于已有信号的健康诊断结论 |
| alerting-irm（grafana/skills） | Grafana 官方告警路由、on-call 排班与 SLO 燃尽率告警技能 | 负责“告警怎么发、谁值班”，属于响应调度层；不做多信号综合诊断 |
差异化总结：可观测性工具链上，dd-apm 负责埋点采集、alerting-irm 负责告警路由与排班、manage-slos 负责定义度量目标，三者产生原始信号和规则；而 service-health 是唯一站在“信号已经都有了，服务到底健不健康”这一步、直接综合多个已有信号给出诊断结论和下一步建议的技能。
8. 用户评价
Elastic Observability Labs 官方博客（2026-03-16，作者 Bahubali Shetti）在介绍该技能时称，其“通过整合 APM、基础设施指标、日志、SLO 和告警等信号，提供服务健康的统一视图”。该技能目前在第三方平台尚无经证实的独立用户评价。
9. 其他补充
同仓库的 manage-slos 可用于先定义服务的 SLO 与错误预算，logs-search 可在本技能定位到问题后做进一步的日志细节排查，三者组合可覆盖“定目标 → 查健康 → 挖细节”的完整链路。
10. 安装使用方式
- 方式一（推荐，精确安装单个技能）：
npx skills add elastic/agent-skills --skill observability-service-health - 方式二（Claude Code 插件市场，安装整组可观测性技能）：先执行
claude plugin marketplace add https://github.com/elastic/agent-skills，再执行claude plugin install observability@elastic-agent-skills - 方式三（GitHub Copilot CLI）：
copilot plugin marketplace add elastic/agent-skills，再copilot plugin install observability@elastic-agent-skills - 方式四（手动）：clone 仓库后把
skills/observability/service-health子目录复制到自己项目的技能目录，脚本无第三方依赖，无需额外npm install - 使用前需设置环境变量
KIBANA_URL与KIBANA_API_KEY（或KIBANA_USERNAME/KIBANA_PASSWORD），指向已部署的 Elastic Observability 环境；如需脚本降级兜底另设ELASTICSEARCH_URL/ELASTICSEARCH_API_KEY - 安装后建议重启 Claude Code 会话使插件生效
11. 注意事项
- 依赖 Elastic 部署已启用 APM/OTel 埋点、SLO、告警规则等前置配置，技能本身不提供环境搭建指引
- ES|QL 功能要求 Elasticsearch 8.11+（GA 于 8.14），Serverless Complete tier 始终可用；纯 OpenTelemetry 场景下的
TS时间序列命令需 Elasticsearch 9.3+ apm-correlations脚本优先调用 Kibana 内部 API，不可用时才降级到 Elasticsearchsignificant_terms聚合，两种模式下结果口径可能略有差异- 与 OpenClaw、Hermes Agent 的兼容性未经官方验证，建议自行测试