观测平台自身健康：六项巡检指标

结论先行：观测平台一旦自身出问题，通常是"没人发现"——因为监控它的指标不在同一张看板里。建议按采集端在线率、上报延迟、写入积压、存储水位、查询耗时、链路完整率六项做日常巡检，每项定阈值、责任人与处置动作，并且每半年做一次"平台停摆"推演，确认平台不可用时团队还有没有兜底手段。

为什么观测平台需要被观测

平台每天告诉业务系统哪里慢、哪里错，但它自己的健康状态常常只有一个"服务在运行"的进程检查。等到用户发现查不到链路、告警不响了，往往已经持续了一段时间。

更要紧的是失效方式是静默的：采集端掉线，看板上显示的是"这段时间没有异常"，而不是"这段时间没有数据"。这两种状态在界面上长得几乎一样，只能靠覆盖率类指标区分。

六项巡检指标

每项指标都要配一个明确动作，而不是只画曲线。比如采集端在线率低于阈值时，动作为"导出掉线清单、按业务域派发补装任务"；存储水位超线时，动作为"缩短明细留存期或调整采样率"。

巡检节奏：日、周、月

• 每日：看采集端在线率与上报延迟两项，异常即建单。这两项变化最快，也最能反映当天是否有变更引入问题。
• 每周：看写入积压、存储水位、查询耗时，判断容量是否需要调整，并清理上周未闭环的告警。
• 每月：看链路完整率与采集覆盖率，核对新上线服务是否接入，输出一份简短的健康月报。

一次推演：平台不可用时怎么办

建议每半年做一次纸面推演，回答三个问题：平台完全不可用时，业务侧是否有独立的健康检查能先发现故障；排障时还能不能拿到原始数据（应用日志、网关日志、数据库慢日志）；恢复后缺失窗口内的数据能不能补采或至少留下记录。

推演不需要真的停机，重点是确认兜底手段是否还在、是否有人知道怎么用。很多团队做完推演才发现，原始日志的保留期在上了观测平台之后被悄悄缩短了。

落地清单

• 把六项指标做成一张独立看板，不要混在业务看板里，避免被业务指标淹没。
• 每项指标绑定责任人与处置动作，出现告警时不用临时讨论"该谁管"。
• 采集端掉线清单按业务域导出，纳入周会材料而不是只在平台内查看。
• 记录每次容量调整的时点与原因，作为后续扩容的参考依据。
• 保留原始日志的独立留存能力，作为平台故障期间的兜底手段。

三个常见坑

• 只监控进程存活，不监控数据链路——进程在跑但没有数据，界面上仍显示"正常"。
• 存储水位只在告警时处理，没有提前规划留存期与降级策略，扩容需要停机窗口。
• 平台自身的巡检没人负责，默认"厂商会管"，实际上厂商看不到内部变更引入的问题。

如果您正在规划相关建设，欢迎预约咨询，奇摩技术团队可结合现网情况给出可落地的清单与口径建议。