云原生应用可观测性建设

先建立统一的服务与责任模型

容器和实例会频繁变化, 仅按主机组织监控无法解释业务链路。企业应维护服务目录, 记录服务名称、负责人、代码仓库、运行环境、上游下游、数据等级和服务目标。所有遥测数据使用一致的环境、服务、版本和区域标签, 才能跨信号关联。

标签需要控制基数。用户ID、订单号等高基数字段适合进入受控日志或链路属性, 不应直接作为时序指标标签, 否则会造成存储和查询成本失控。

关联指标、日志、链路与变更事件

指标适合发现趋势和触发告警, 日志用于查看离散事实, 分布式链路用于还原跨服务请求, 发布与配置事件则解释系统为何在某一时刻变化。四类信号应共享关联标识, 支持从异常指标跳转到代表性链路, 再定位相关日志与最近变更。

采用统一采集规范可以降低应用对具体后端的耦合, 但采集并非越多越好。应先覆盖关键用户路径、外部依赖、异步任务和资源瓶颈, 再依据排障缺口扩展。

让告警围绕用户影响和可执行动作

CPU短时升高并不一定影响服务, 单个实例重启也可能被平台自动恢复。优先基于请求成功率、关键操作延迟、队列积压和服务目标消耗速度告警, 并在通知中附带影响范围、当前版本、仪表盘和处置手册。

每条告警必须有责任团队和预期动作。长期无人处理、重复触发或仅供观察的告警应降级为仪表盘信号。通过合并同源事件、设置抑制窗口和维护依赖拓扑, 可以减少故障期间的告警风暴。

把故障复盘转化为可观测性需求

复盘不只记录直接原因, 还应回答为什么没有更早发现、哪些上下文缺失、哪个手册无法执行。改进项可以是补充业务指标、增加链路属性、调整告警阈值或自动收集诊断快照。平台团队则持续衡量平均发现时间、平均恢复时间、告警有效率和遥测单位成本。