生产监控先看用户是否受影响，再追到指标、日志和链路

先确认四个可观测性条件

先确定适用边界，不把所有数据都叫作监控

这份指南适合已经承载真实业务、由一个或多个应用与基础服务组成的 Web、APP、小程序后台和企业系统。它关注服务可用性与故障响应，不替代安全审计、隐私合规、业务经营分析或基础设施容量规划；这些领域可以共用部分数据，但目标、权限、留存和响应流程不同。

单体应用同样需要可观测性，只是可以先从少量关键路径、统一结构化日志和基础告警开始。没有夜间值班的小团队不应假装具备全天响应能力，应明确服务时段、紧急联系人和不可用时的业务降级办法。涉及医疗、金融或其他强监管场景时，还需由对应专业人员补充审计与留存要求。

• 列出系统所有者、服务时段、关键依赖、可接受中断范围和发生故障时的业务兜底方式。
• 区分面向即时处置的监控、面向审计的记录和面向经营分析的数据，分别控制访问与留存。
• 确定本期只覆盖哪些环境和服务；开发测试数据不要与生产告警混在同一通知通道。

从关键用户路径反推要监控的结果

先挑选一旦失败就会影响收入、履约、生产或客户信任的路径，例如登录、提交订单、完成支付、审批流转、设备上报和批量同步。每条路径都要从用户或业务结果定义成功，而不是只检查某个接口返回了 200。

一条路径可能跨越多个步骤。支付页面打开正常，不代表扣款、回调、订单入账和通知都成功；定时同步任务进程仍在，也不代表数据没有持续积压。为每条路径画出入口、关键节点、外部依赖和最终落库或状态变化，再决定成功率、延迟、处理量、积压时间或数据新鲜度中哪些能代表真实结果。

• 为每条关键路径指定业务负责人和技术负责人，并写清失败会影响哪些用户与后续流程。
• 定义计算口径、时间窗口、排除条件和数据来源，避免不同仪表盘对同一成功率给出不同答案。
• 保留少量端到端合成检查，从外部入口验证 DNS、证书、页面、接口与关键依赖能否协同工作。

让指标看范围、日志还原事件、链路串起一次请求

三类信号解决的问题不同。指标适合聚合观察错误、延迟、流量与资源饱和趋势；日志适合记录带时间和上下文的离散事件；分布式链路适合查看一次请求经过哪些服务、各阶段耗时以及错误出现在哪里。项目不必一次把三者做满，但要知道缺少哪类证据会让哪些问题无法回答。

采集计划应从排障问题出发：如果登录失败，能否区分输入错误、身份服务超时和数据库异常；如果订单变慢，能否看到是应用处理、外部接口还是存储等待。无法支持任何决策或排障问题的数据，应降低采样、缩短留存或暂不采集。

• 指标优先覆盖请求量、错误、延迟、队列积压与关键资源，并同时观察关键业务结果。
• 日志采用结构化字段和明确级别，记录错误类型与处理阶段，不在正文或标签中写入密码、令牌和不必要的个人信息。
• 链路采样策略兼顾成本与证据完整性，确保错误和高延迟请求有合理机会被保留，并记录采样规则。

统一资源与请求上下文，避免三套数据互相找不到

可观测性最常见的失败不是没有数据，而是同一个服务在不同工具里使用不同名称，或者日志里没有请求标识。应先制定一份小而稳定的字段约定，使告警能跳到相同服务、环境、版本和时间窗口的指标、日志与链路。

服务名、部署环境、地区、版本和租户类型等低基数维度适合用于筛选；用户 ID、订单号、完整 URL、异常正文等高基数或敏感值不应直接成为指标标签。它们可以在权限受控的日志或链路属性中按需查询，并根据隐私与排障需要做脱敏和留存控制。

• 统一 service、environment、version、region、trace_id 与 request_id 的命名、格式和传播规则。
• 发布系统写入版本与发布时间标记，仪表盘能把错误或延迟变化与发布事件对齐。
• 为指标标签建立允许清单与基数预算，上线前检查是否误用了用户、订单或原始路径等无限增长字段。

告警优先报告用户症状，原因信号留给定位

需要立即通知人的告警，应优先对应持续的用户失败、高延迟或关键任务积压，而不是任意一次异常或单台机器的瞬时波动。CPU、内存、连接数和依赖状态仍然重要，但更适合作为诊断上下文，或在明确预示容量耗尽且有处置动作时单独告警。

每条规则都要说明为什么触发、覆盖多长窗口、短暂抖动是否等待、恢复后何时关闭，以及缺少数据代表正常、采集故障还是服务消失。阈值不应来自网上模板；先观察正常基线，再结合用户容忍度、业务峰谷和响应时间确定，并在事故复盘后调整。

• 把通知分为需要立即处置、工作时间处理和仅供趋势观察，避免所有事件都进入同一高优先级渠道。
• 按服务与故障影响聚合重复通知，对已知维护设置有时限和负责人的静默，防止告警风暴。
• 告警内容至少包含影响范围、当前值与窗口、仪表盘或查询入口、运行手册、负责人和升级路径。

把值班响应写成可以接手的运行手册

通知发出只是开始。接收人需要快速判断是否真实、影响多大、先止损还是继续定位。运行手册应围绕第一轮处置编写，而不是复制完整系统文档；遇到没有权限、依赖方失联或首个动作失败时，还要明确升级给谁。

处置过程中保留时间线：首次异常、告警触发、人员确认、采取动作、业务恢复和后续观察。紧急变更仍要记录执行人和结果。恢复后再讨论根因与长期修复，避免为了追根因延误降级、回退、限流或切换依赖等止损动作。

• 每条高优先级告警指定主责团队、备援联系人、确认时限和跨团队升级方式。
• 运行手册写明三到五个首查入口、安全的止损动作、不可执行条件和恢复验证步骤。
• 建立交接规则，未解除的告警、临时静默和未完成风险必须在换班或工作日开始时明确转交。

同时管理采集成本、查询性能和数据权限

日志量、链路采样率、指标维度和留存周期都会影响成本与查询速度。更长留存并不自动带来更好排障；应根据故障发现周期、复盘需要、法规要求和预算为不同数据分层，而不是给所有信号设置相同策略。

先估算每日数据量与高峰写入，再逐项确认采集端失败是否会拖慢业务请求。监控后端、采集器和通知渠道本身也会故障，因此关键链路要有独立健康检查，并为遥测积压、丢弃和规则评估失败保留可见信号。

• 按服务与信号记录采集量、标签基数、采样率、留存、月度成本和主要查询延迟。
• 对敏感日志实施最小权限、脱敏、访问审计和到期删除，排障方便不能成为无限留存理由。
• 为采集器阻塞、导出失败、数据延迟和告警规则失效设计降级，避免可观测系统反向拖垮业务。

用受控演练验收从异常到恢复的完整链路

上线前与重大调整后，应在隔离环境或可控范围内制造已知异常，例如合成探测失败、测试队列积压、测试服务返回错误或暂停一条非关键采集链路。演练目标不是证明某个图表会变红，而是验证信号出现、规则计算、通知送达、人员确认、手册可用和恢复关闭都符合预期。

不要在没有保护措施时直接破坏生产关键路径。每次演练要写明范围、观察人、停止条件和恢复动作；无法安全注入故障时，可以回放测试信号或在预发布环境验证，再把尚未覆盖的生产差异列为已知风险。

• 记录异常开始、首次可见、告警触发、通知送达、人员确认和业务恢复时间，定位链路中最慢的一段。
• 验证重复通知能聚合、维护静默会到期、负责人不可用时能够升级，恢复后告警不会长期悬挂。
• 每季度或在服务拓扑、值班表、通知工具发生重要变化后复核规则与运行手册，删除无人使用的监控项。