用途：依据 Elastic Observability 数据评估 APM 服务健康度，回答“服务 X 是否健康”“服务 Y 为什么慢”等问题，并给出证据与后续行动建议。
主要能力：
- 通过 SLOs API 获取 SLO 定义、状态（healthy/degrading/violated）、燃烧率与错误预算；通过 Alerting API 列出并管理告警规则与告警。检查单个服务时需同时考虑 params.serviceName 匹配该服务的规则和未指定 serviceName 的全服务规则；判断当前活跃告警不要查询 .alerts* 索引。
- 使用 ES|QL 查询 tracesapm、tracesotel、metricsapm、metricsotel，统计吞吐量、延迟（avg/p95/p99）、错误率与依赖聚合。ES|QL 自 8.11+ 可用（技术预览，8.14 GA），Serverless Complete 层始终可用。查询时用 service.name（必要时加 service.environment）和 @timestamp 范围过滤，加 LIMIT 控制行数与 token，趋势分析优先用较粗 BUCKET。
- 检查 ML 异常检测结果（延迟、吞吐、错误率），用异常时间窗缩小排查范围。
- 依据 trace 中的 k8s.pod.name、container.id、host.name 等资源属性，用 ES|QL 或 Elasticsearch 查询基础设施/指标索引，排查 CPU、内存、OOM 与 CPU 限流。
- 用 ES|QL 或 Elasticsearch 按 service.name 或 trace.id 过滤日志，解释行为与根因。
- 当仅部分事务受影响时，运行 apm-correlations 脚本找出与高延迟或失败相关的属性，先尝试 Kibana 内部 APM correlations API，失败后回退到 Elasticsearch significant_terms。
必要用法： 运行相关性分析：node skills/observability/service-health/scripts/apm-correlations.js latency-correlations --service-name <name> [--start <iso>] [--end <iso>] [--last-minutes 60] [--json]；failed-correlations 同理；test 子命令检测 Kibana 连接。环境变量：Kibana 用 KIBANA_URL 和 KIBANA_API_KEY（或 KIBANA_USERNAME/KIBANA_PASSWORD）；回退用 ELASTICSEARCH_URL 和 ELASTICSEARCH_API_KEY。
工作流：确认服务与时间范围 → 查 SLO 与活跃告警 → 查 ML 异常 → 看吞吐、延迟、错误率 → 评估依赖健康 → 关联基础设施与日志 → 汇总健康结论并建议。未提供时间范围时默认最近一小时；SLO 存在时以 SLO 状态与燃烧率为锚点，否则依赖告警、异常、指标与依赖。
适用场景：APM 服务健康检查、性能劣化排查、错误率上升定位、依赖故障归因、SLO 与告警符合性核查。
限制：ES|QL 需 Elasticsearch 8.11+ 或 Serverless；TS 命令需 9.3+ 或 Serverless。全文未提供定价、平台覆盖范围或其他收费信息。