用途：为生产系统设计可观测性方案，回答“如何知道系统坏了、多快知道”。适用于定义测量内容、告警对象、SLO 与跨服务请求追踪；原型或无用户内部工具不必搭建完整栈，健康检查加错误日志即可。
主要能力：三大支柱互补——指标（计数器、仪表、直方图，用于仪表盘、趋势与告警）、日志（带上下文的事件，用于告警后定位具体故障）、追踪（单请求跨服务旅程与各跳耗时，用于定位延迟或错误来源）。测量框架：请求驱动服务用 RED（Rate、Errors、Duration），资源用 USE（Utilization、Saturation、Errors），默认服务仪表盘用四大黄金信号（延迟、流量、错误、饱和度）。健康检查：存活探针判断进程是否存活，失败则重启，应廉价且不查依赖；就绪探针判断实例能否接流量，失败则摘除而非重启。告警：默认基于症状（SLO 燃烧率）触发寻呼，基于原因（资源阈值）只开单或警告。
使用方式：先明确用户视角的“健康”症状、SLO 目标与窗口、请求量与基数、是否多服务路径；再选支柱与框架；设置存活/就绪端点、连续失败阈值、追踪采样率、SLO 与错误预算策略，并预先丢弃高基数标签；最后按压力场景验证遥测异步采样、探针不引发惊群、基数有界、告警按根因分组。默认方案为 Prometheus + Grafana + Loki + Jaeger，由 OpenTelemetry 串联；用户指定云厂商时可查对应 provider 文件。
限制：不要为原型搭建完整栈，不要发明无人维护的 SLO，不要在没有症状与运行手册时接线告警；高基数标签（用户 ID、原始 URL）会撑爆指标存储；存活探针查依赖会导致重启循环；日志高吞吐管道属于 distributed-logging，本技能只决定记录与告警内容，不重建该管道。具体价格、平台与效果资料暂未提供。