用途：设计并运营应用可观测性，覆盖指标、日志、链路追踪与告警，适用于 SLO 定义、仪表盘设计、值班手册与事故处理。
输出规范：默认只返回结果、阻塞项与所需证据，省略前言、过程叙述、重复上下文、置信度与后续提议；除必需产物或 schema 外，最多五条要点。
使用前先核查版本，命令保持原样： prometheus --version grafana-server -v jaeger --version tempo -version
核心原则：指标看症状，日志看原因，链路看路径；对症状而非原因告警（如错误率、延迟上升，而非 CPU 越过阈值）；用 SLO 定义可靠性，每个服务有错误预算、SLO 目标及预算耗尽的明确后果；仪表盘用于探索而非告警；可观测性数据视为生产代码，埋点与业务逻辑同等评审。
SLO 模板：服务名、SLI（好事件/总事件比率）、SLO 目标百分比（如 99.9%）、错误预算为 100% 减 SLO（如 0.1% 约每月 43.8 分钟）；告警分快燃尽（1 小时消耗 2% 预算，立即呼叫）与慢燃尽（6 小时消耗 5% 预算，工作时间内呼叫）。SLI 类型含基于请求（good_requests / total_requests）与基于窗口（good_time_windows / total_time_windows）。
埋点方法：服务用 RED（Rate、Errors、Duration，延迟看 p50/p95/p99），资源用 USE（Utilization、Saturation、Errors），另可参考四大黄金信号：延迟、流量、错误、饱和度。
告警规则：仅在需要人工立即行动时呼叫，其余转为工单或仪表盘备注；每条告警都有手册，无手册即无告警；删除无人响应的告警；采用多窗口、多燃尽率告警，单阈值告警噪声大。
反模式与修正：CPU 高于 80% 告警应改为对延迟/错误率告警后查 CPU；不要对每个错误告警，改为错误率；无 SLO 需补齐 SLI/SLO；不以仪表盘做主检测；链路上下文缺失需在所有信号中使用 trace ID；不要全部 INFO 级日志，改为结构化日志、采样调试、问题用 ERROR。
验证清单：每个服务导出 RED 指标；每个服务有含错误预算的 SLO；每条呼叫告警有经验证的手册；告警路由到正确团队；仪表盘能回答已知故障的“发生了什么”与“为什么”；链路跨服务边界并传播上下文；监控日志保留与成本。
限制：资料未给出具体安装步骤、收费、平台支持范围与运行效果数据，暂未提供；上述命令仅用于版本核查，是否可用及具体行为需自行验证。
分类：部署与运维（devops）。