云监控入门

1 为什么方案里要单独谈「云监控入门」

零售系统的大促开始后，首页仍能打开，订单 API 的容器也都显示运行中，客服却不断收到“提交后转圈”的反馈。此时，“服务器在线”无法回答真正的问题：顾客是否成功下单，失败集中在哪个入口，影响从何时开始，继续扩容能否缓解。云监控要把这些问题变成可观察、可比较、可行动的证据。它既服务于故障处理，也用于容量规划、发布评估和日常成本判断。

本课采用固定场景：顾客点击提交订单，请求经网关进入订单服务，订单服务校验商品与价格，调用库存服务预占库存，再将订单写入数据库，最后返回订单编号。支付在后续流程完成，因此本课的“下单成功”指订单创建成功，不等于支付成功。若方案没有先写明这个边界，业务人员看到的支付转化率与运维看到的接口成功率可能同时正确，却无法互相解释。

监控方案要从用户结果倒推。先说明要保护的结果，例如有效提交在 2 秒内获得确定答复，再说明在哪里测量、怎样判断异常、异常后由谁处理。接着才选择采集组件、看板和通知渠道。只列“部署监控平台、接入日志、配置告警”，无法证明系统具备发现故障的能力，因为采集成功并不代表数据覆盖了关键路径，也不代表有人能够据此采取行动。

云环境让资源数量与位置持续变化。实例可能因伸缩被替换，服务可能跨可用区部署，基础设施指标也可能由托管平台提供。监控对象因此应同时包含资源和逻辑服务：资源视角解释某台实例的状态，服务视角解释整个订单接口的表现。若只盯固定实例编号，新实例可能没有被采集；若只看服务平均值，某个可用区的局部故障又可能被掩盖。

监控也不是“提前知道所有故障”的承诺。它是在约定范围内缩短发现、定位和恢复所需时间的工程能力。未埋点的业务分支、采集链路中断、错误的成功定义，都可能形成盲区。因此方案必须交代监控自身的健康状态，并安排定期演练：真实触发可控异常，确认数据、告警、值班响应能够连成闭环。

2 核心概念与边界

指标是按时间记录的数值，适合回答“发生了多少、持续多久、影响多大”。订单请求总数是计数器，通常随进程运行递增；队列当前长度是仪表值，可以上升也可以下降；请求耗时通常使用直方图，在多个耗时区间记录请求数量。看到计数器重启后变小，不应解释为请求量突然下降，应由查询系统结合重置情况计算增量或速率。

日志是离散事件记录，适合回答“某次操作发生了什么”。订单服务可以在库存预占失败时记录事件名称、错误类别、依赖耗时和请求标识。结构化日志为这些信息分配固定字段，方便过滤和聚合。日志不是越详细越好：记录完整请求体可能泄露地址和手机号，也可能迅速消耗存储。应按排障需要选字段，对敏感内容做删除、脱敏和访问控制。

追踪把同次请求跨服务的操作连接起来。整条请求形成 trace，其中每段操作是 span，例如订单服务处理、库存调用、数据库写入。父子关系与时间范围帮助判断耗时发生在哪段。trace_id 用于关联整条链路，span_id 标识某段操作。跨网络调用时，需要传播追踪上下文；只有入口产生标识、下游没有继续传递，得到的将是多个断开的局部视图。

这 3 类数据各有取舍。指标成本相对可控，适合持续看趋势与触发告警；日志提供事件细节；追踪呈现调用结构与耗时分布。它们应通过时间、服务名、版本、可用区和关联标识互相定位。trace_id 适合放入日志和追踪，通常不适合成为时序指标标签，否则每次请求都可能产生新的时间序列，使查询与存储成本失控。

SLI 是服务质量的实际测量，例如“在 2 秒内成功完成的有效下单请求占比”。SLO 是目标，例如滚动 30 天该占比至少为 99.9%。SLA 则是对外约定，可能包含责任和补偿条件，不能把内部目标直接当作合同承诺。错误预算是目标允许的未达标空间；它帮助团队讨论发布与可靠性的取舍，也需要明确时间窗口和计算口径。

分母尤其容易引发误判。库存售罄、参数缺失、鉴权失败是否算服务不可用，应结合用户旅程逐项约定，不能只凭 HTTP 状态码决定。网关未能转发的请求不会出现在应用统计里，应用返回成功但数据库没有持久化也不能算业务成功。可同时保留入口技术指标与订单业务结果指标，通过差异发现测量盲区，而不是强行把它们合成单个“健康分”。

监控主要负责测量与发现，排障需要进一步解释原因，自动修复需要执行有边界的动作。告警触发不意味着已经证明根因；CPU 高也不必然要求扩容。对权限、数据保留、通知和自动操作分别设定边界，可以避免让观察工具意外拥有过大的生产修改能力。

3 关键机制

从采集到行动，监控通常经过埋点、收集、传输、存储、查询、规则计算与通知。应用在请求结束时更新计数和耗时，采集器定期拉取或接收数据，后端按时间保存，告警规则按固定周期执行。任何环节都可能增加延迟。采集间隔为 15 秒、规则持续条件为 2 分钟时，用户出问题到通知送达不会只有 15 秒，还要考虑窗口、计算与通知排队。

请求数与错误数应尽量在同个边界计量。假设最近 5 分钟网关接收 12000 次有效提交，其中 120 次返回系统错误，则该窗口错误率为 1%。若用应用错误数除以网关全部请求数，却没有处理网关拒绝、重试和过滤口径，数值就可能失真。对外层用户请求和内部调用分别命名，避免把库存重试 3 次当成顾客下单 3 次。

延迟要看分布。p95 为 800 毫秒，表示在当前统计范围内约 95% 的请求不超过该值；它不能说明剩余请求最多多慢，也不是 95% 的时间服务都健康。不同实例的 p95 不能直接求平均得到服务 p95。若需要跨实例聚合，可先合并兼容的直方图桶计数，再计算分位数；桶边界也应覆盖业务关心的 2 秒门槛。

时间窗口改变了观察结果。1 分钟窗口反应快，容易受小样本影响；30 分钟窗口较平滑，却可能稀释短时尖峰。请求只有 2 次且失败 1 次时，50% 错误率不能与每分钟 10000 次请求下的 50% 等同处理。告警可同时要求错误比例、最小请求量和持续时间，对低流量服务再补充合成探测，避免真实不可用因“没有足够请求”而静默。

标签把同种指标切成可比较的维度，例如 service、route、status_class、zone、version。route 应使用归一化模板，如 /orders/{id}，不要直接使用包含订单编号的实际路径。每个标签的取值组合都会扩展序列数量，多个维度还会相乘。保留能支持决策的维度，将用户编号、订单编号和请求标识留给受控的事件查询。

缺失数据必须单独处理。曲线断开可能是服务退出，也可能是采集器异常、网络阻断或查询范围错误；缺失不能自动补成 0 后宣布错误率正常。应同时观察最近成功采集时间、目标发现数量、采集器丢弃计数和通知通道状态。对于订单量突然归零，还要交叉检查入口流量与业务时段，区分“没有顾客”与“顾客进不来”。

追踪采样用于控制开销。按固定比例在请求开始时决定是否记录，能限制数据量，却可能漏掉少见故障；按完成结果保留慢请求或错误请求，需要缓存与协调，也可能在压力过大时丢弃。方案应写明采样规则与丢弃指标，并提醒使用者：没有找到某次 trace 不能证明该请求没有发生，采样数据也不能随意代替全量成功率统计。

4 落到订单链路的关键点

先为订单路径画出责任边界。网关负责记录入口量、响应码和总体耗时；订单服务记录校验、库存调用和数据库写入结果；库存服务记录预占结果与依赖耗时；数据库侧提供连接、锁等待和资源指标。每层都需要明确维护人。若某个依赖由其他团队负责，仍应在调用方测量该依赖，因为用户感受到的是完整路径，不能等待对方看板才确认影响。

订单创建还有“结果不确定”的状态。客户端等待超时，但数据库写入可能已经成功；客户端重试后，幂等机制应返回已有订单或确定结果。监控要分别记录用户请求、处理尝试和实际新增订单，观察重复提交、幂等命中和超时后的结果确认。否则请求总数上升可能被误认为业务增长，而实际新增订单没有增加，顾客只是不断重试。

服务的 4 类常用信号是流量、错误、延迟与饱和度。流量说明负载，错误说明失败，延迟说明体验，饱和度说明剩余处理空间。订单服务的饱和度不仅是 CPU，还可能是工作队列、线程池、连接池或并发限制。CPU 只有 30% 时，数据库连接池也可能已经耗尽，所有新请求都在等待连接。资源空闲与服务有余量并不是同个结论。

数据库与库存往往是共享瓶颈。若订单实例从 10 个扩到 20 个，每个实例保持 30 个数据库连接，潜在连接需求就从 300 增至 600。应用吞吐能力可能增加，数据库却更拥挤。监控应把实例数量、连接上限、等待队列和数据库处理时间放在可对照的位置，扩容决策才不会把压力继续推向下游。重试次数与超时预算也要纳入同张因果图。

版本与可用区是定位局部异常的重要维度。发布后总体错误率可能仍低于阈值，但新版本已明显劣化；某个可用区的流量较少，其高延迟也可能被全局平均掩盖。可以先看全局影响，再按版本、区域和入口逐层切分。切分维度应事先规划，临时故障时才发现没有版本标签，通常无法准确补回历史数据。

业务核对提供额外约束。例如比较入口有效提交量、创建成功事件量与数据库新增订单量，并考虑异步落库、统计延迟和取消流程。它们不必在每秒都相等，但应在约定延迟内满足解释规则。出现长期差异时，既可能是业务链路问题，也可能是重复上报或采集丢失。指标用于提出疑问，核对记录用于检验疑问，不能看到差值就直接宣布订单丢失。

5 动手：控制台/命令直觉

练习从测试环境开始。准备带固定测试标识的下单请求，覆盖成功、库存不足和依赖超时 3 种结果；测试账号与商品要能够清理，避免把演练订单计入真实经营报表。先写下预期：成功路径产生订单编号，库存不足得到明确业务反馈，超时路径能够关联到具体依赖。然后逐条发起请求，观察入口、应用和数据库记录是否符合预期。

控制台中的操作顺序可以固定为：选择订单服务，确认环境与时间范围，查看请求量、错误率和延迟分布，再按版本或可用区切分，最后进入相关日志和追踪。进入看板先确认时区与时间选择器，避免把本地时间的客服反馈与 UTC 事件直接对齐。比较发布前后时，也要考虑流量差异，不能把低峰与高峰的延迟变化全部归因于代码。

下面的命令只用于理解观察边界，地址和令牌均需替换为测试环境配置。不要把生产凭据写进共享脚本、截图或日志。-w 展示的是这次客户端请求的总耗时，其中可能包含连接建立和网络等待；它与应用内部处理时间应对照解释。

curl -sS -o /dev/null \
  -w 'status=%{http_code} total=%{time_total}s\n' \
  https://orders.test.example/health/ready

就绪接口只能说明实例愿意接收流量，并不能证明真实下单路径成功。合成探测应使用受控商品和账号完成关键路径，按设计清理测试数据，并区分测试流量与真实流量。探测频率也要受限，避免监控本身持续占用稀缺库存。若只探测静态健康地址，数据库不可写时仍可能得到正常结果。

查询时先理解计算，再映射到所用系统的语法。下面是 PromQL 风格的示意，表示最近 5 分钟系统错误请求速率除以全部请求速率，实际指标名与过滤条件应与埋点约定对应。没有流量时，结果可能为空或不可计算，需要另设缺失和可用性规则。

sum(rate(order_requests_total{outcome="system_error"}[5m]))
/
sum(rate(order_requests_total[5m]))

接着取某次测试请求的关联标识，查找同个 trace_id 的日志，再打开对应追踪，核对库存调用与数据库写入的顺序。若缺少下游 span，检查上下文传播、采样决策与导出状态。不要立即认定下游没有收到请求。最后触发可控超时，记录异常发生、数据可见、规则触发、通知收到和恢复各个时刻，以实测结果确认发现延迟。

6 观测字段与告警

字段首先要能回答问题。服务与环境用于确定观察对象，时间与关联标识用于连接事件，结果与错误类别用于判断失败性质，版本与可用区用于缩小范围。字段名称、单位和枚举应统一：duration_ms 与 duration_seconds 不能混用，timeout 与 inventory_empty 也不应混成通用 failure。清晰的字段协议比事后增加更多自由文本更容易支撑稳定查询。

告警应说明影响、条件、持续时间、责任人和处理入口。例如：“生产订单有效请求最近 5 分钟系统错误率超过 2%，且请求数超过 500，持续 2 分钟，通知订单值班”。这只是教学起点，阈值要依据真实基线、业务目标和响应能力调整。通知内容还应包含当前值、起止时间、受影响范围、看板链接和操作手册，减少接警后反复寻找上下文的时间。

用户症状适合触发紧急响应，资源趋势适合提前安排处理。订单无法创建应及时叫醒负责人；磁盘预计数天后耗尽可以进入工作队列。若所有资源波动都按紧急等级通知，值班人员很快无法区分真正影响。多条告警由同个事件引起时，可按服务与故障范围分组，同时保留不同症状的证据，避免通知风暴淹没关键变化。

阈值还要兼顾发现速度与误报。提高持续时间可以过滤短时抖动，也会延迟发现；缩短窗口能更快响应，也可能放大小样本噪声。恢复条件可与触发条件保持适当间隔，并要求稳定恢复，减少边缘值反复触发。静默必须限定对象、原因和到期时间，发布期间也要保留必要的业务症状监测，不能把“计划变更”视为故障不会发生的证据。

有了 SLO 后，还可以观察错误预算消耗速度。若允许失败比例为 0.1%，某窗口实际失败比例为 1%，该窗口的消耗速度约为允许速度的 10 倍。短窗口帮助发现急剧恶化，长窗口帮助识别持续问题，两者结合可减少偶发尖峰造成的误判。窗口长短、触发倍数和低流量处理必须明确，不能只在规则里留下无人解释的公式。

7 常见坑

常见的第 1 个坑是把“采到了”当作“监控完成了”。看板上有 CPU 曲线，却没有订单成功与否的口径；日志持续增长，却无法用请求标识串起服务。改进方式是为每个关键问题指定证据来源，并从真实测试请求走完查询流程。能否在限定时间内回答“谁受影响、从何时开始、哪个环节慢”，比图表数量更能说明覆盖程度。

第 2 个坑是把平均值当作用户体验。大多数请求在 100 毫秒内完成，少量请求等待 8 秒，平均值仍可能看起来不错。应查看分位数、超时数与超过业务门槛的请求比例，并按重要入口切分。分位数也不能代替全部判断：如果整体请求少，p99 会很不稳定；如果只采到成功请求，耗时分布会遗漏最差体验。

第 3 个坑是让数据无限增长。把订单编号加入指标标签、对每次循环输出日志、长期保留所有追踪，都可能造成成本和性能问题。采集预算要覆盖写入量、序列数量、保留周期和查询成本。高价值错误事件可保留更久，常规调试日志可短期保存；调整采样与保留前，要确认是否仍能满足排障和业务核对需求。

第 4 个坑是把告警名称写成根因判断。例如规则只观察到库存调用超时，却通知“库存数据库故障”，会引导团队过早收窄调查范围。告警应准确描述已观察到的现象，根因作为待验证假设。网络丢包、调用方连接池耗尽、库存服务排队，都可能表现为同样的调用超时，需要额外证据区分。

第 5 个坑是直接对指标执行自动修复。看到延迟上升就重启，可能清除现场并使剩余实例更拥挤；看到 CPU 高就无限扩容，可能耗尽数据库连接。自动动作应有前置条件、作用范围、速率限制、停止条件和审计记录。对于结果不确定的订单请求，重试必须建立在幂等与重试预算之上，否则监控触发的动作也可能放大事故。

第 6 个坑是忽略时间与权限。时钟偏差会让跨服务事件顺序难以解释，延迟到达的数据会改变最近窗口的结果；过宽的日志权限则可能暴露顾客信息。应使用统一时间基准，保留事件时间与必要的接收时间，并按职责授权查询。故障结束后回收临时权限，保留必要审计，使排障便利与数据保护同时可持续。

8 案例：大促或故障

某次大促在 20:00 开始，订单入口从每秒 200 次升至 900 次。最初 1 分钟，成功率仍达标，但 p95 从 300 毫秒升至 1.8 秒，数据库连接等待同步上升，CPU 约为 45%。若只看 CPU，团队可能认为容量充足；若直接扩容订单实例，则可能进一步增加连接竞争。此时应把用户延迟与资源等待放在同条时间线上观察。

20:02，连接池等待超过请求超时预算，部分请求返回系统错误。客户端开始重试，入口流量继续上升，但新增订单没有同比增加。追踪显示慢请求主要等待数据库连接，真正执行写入的耗时变化较小；日志中 connection_acquire_timeout 增多。证据支持“连接获取成为瓶颈”的判断，仍需检查连接为何长期占用，不能把池大小直接当作根因。

值班人员依据预案限制非关键批量查询，控制订单入口并发，并收紧无节制的重试，让数据库获得恢复空间。随后检查发现，大促查询新增了较长事务，部分连接被占用过久。团队对照发布记录与慢事务证据，回退相关变更。所有动作都有负责人和观察窗口，避免同时修改连接池、实例数量和超时配置，使恢复原因无法判断。

恢复不能只看错误告警是否消失。应确认成功比例与延迟恢复、等待队列开始下降、数据库连接占用回落，并核对超时请求的最终订单结果。部分顾客可能已经成功创建订单但未及时收到响应，需依靠幂等查询与订单状态确认，防止引导重复购买。业务恢复与技术指标恢复之间的差距，应在事故记录中单独说明。

复盘后，团队把连接等待纳入容量看板，给新增查询增加耗时与事务约束，在压测中模拟相似流量和重试行为，并演练限流措施。这里的改进目标不是消除所有波动，而是让关键风险更早暴露、处置动作有证据支持。阈值调整也应依据此次事件和后续基线，而不是简单提高阈值以减少通知。

9 排查案例：证据链

再看另次故障：客服在 14:06 报告部分顾客提交缓慢。排查先明确时间范围、受影响入口与错误表现，保留发布和配置变化记录。网关数据显示请求量正常，订单 p95 上升，系统错误主要是超时；按可用区切分后，异常集中在 B 区。此时已经获得影响范围，却还没有证明是 B 区应用、网络还是依赖的问题。

第 1 步检查测量可信度。网关与应用的趋势接近，采集器最近上报正常，B 区合成下单也出现延迟，因此不能仅用“看板坏了”解释现象。第 2 步比较相同版本在其他可用区的表现，发现其他区域正常，而 B 区新旧版本都变慢。这降低了单次应用发布导致故障的可能性，但尚不能完全排除配置与流量分配差异。

第 3 步从慢请求中选取多个样本，追踪显示时间主要消耗在调用库存服务的客户端 span。库存服务收到请求后的处理耗时却较稳定，数据库锁等待与连接占用也未显著变化。两侧时间差提示，应检查连接建立、网络传输和请求进入服务前的等待。由于追踪存在采样，必须用调用方依赖指标和服务端入口量补充验证，避免把单个样本推广为整体事实。

第 4 步查看 B 区到库存入口的连接失败和重传指标，并对照网络配置变更时间。发现异常与某条网络策略调整重合，受控连接测试也复现了部分连接超时。时间重合本身仍是相关性；更强的证据来自限制范围内恢复旧策略后，连接失败下降、依赖耗时恢复，其他条件保持可比。随后按变更流程恢复受影响配置，并持续观察。

最终记录应区分事实、假设、验证动作和结论。事实是 B 区依赖调用变慢，假设是网络路径异常，验证包括双侧耗时对照、连接指标与受控恢复，结论由多项证据共同支持。不要把最早猜测复制为根因，也不要因恢复成功就跳过订单核对。对未采到的请求、无法复现的细节，应明确保留不确定性。

排查完成后还要修补发现过程：若最初告警只看全局错误率，应补充必要的区域视角；若跨服务标识断开，应修复传播；若值班人员找不到网络负责人，应完善责任映射。每项改进都应对应本次证据链中的缺口，并通过测试或演练确认有效。这样监控才能从事后的图表集合，逐渐成为可重复使用的判断与响应能力。

放进方案里

本方案以零售订单创建链路为监控范围，覆盖网关、订单服务、库存依赖、数据库及采集链路。下单成功定义为有效提交完成库存预占并持久化订单，支付结果另行度量。由网关统计入口结果，应用记录业务完成事件，并定期与新增订单核对。示例目标为滚动 30 天内，至少 99.9% 的有效提交在 2 秒内得到成功结果；请求范围、业务拒绝与客户端取消的处理口径须在上线前由业务和技术负责人确认。

监控持续采集请求量、错误比例、耗时直方图、连接等待、队列长度及依赖调用结果，按环境、服务、版本和可用区聚合。日志采用结构化字段并携带追踪标识，跨服务传播上下文。订单编号仅用于受控事件查询，顾客敏感信息不进入普通日志。追踪按预算采样并观察丢弃情况，日志和追踪的保留期限依据排障需求与费用预算确定。

告警以订单失败和持续高延迟为紧急症状，结合请求量、持续窗口和错误预算消耗设置规则；容量趋势进入工作队列。通知包含影响范围、当前值、看板、责任人与操作手册，按事件分组并明确升级路径。订单团队负责入口和业务结果，依赖团队负责各自服务，值班负责人协调跨团队处置。采集缺失与通知失败设置独立监测，避免无数据被解释为正常。

上线前以成功、售罄、依赖超时和采集中断验证观测闭环，记录发现与通知延迟；通过受控压测确认连接、并发和重试边界。故障优先依据证据执行限流、回退等预案，恢复后核对不确定订单。验收材料包括字段约定、看板、告警规则、演练记录和责任表；后续依据事故复盘与实际基线调整，监控采集量及存储费用纳入月度评审。

10 小结：检查清单

• 能否用清晰的分子、分母、窗口和门槛定义订单服务质量？
• 是否同时覆盖入口结果、业务完成、依赖表现与资源饱和度？
• 能否用时间、版本、可用区和 trace_id 连接指标、日志与追踪？
• 是否正确处理计数器重置、低流量、缺失数据与采样偏差？
• 是否避免订单编号等高基数字段成为指标标签，并控制敏感信息？
• 每条紧急告警是否有明确影响、责任人、处理入口和恢复判断？
• 扩容、重试与自动操作是否考虑下游容量、幂等和停止条件？
• 是否真实演练过从异常发生到通知、处置和订单核对的完整过程？

能回答这些问题，才说明方案中的监控已经具备可执行的内容。遇到新故障时，继续沿着“用户影响、测量可信度、范围切分、依赖证据、受控验证”的顺序推进，并把每次发现的盲区变成下次可检查的约束。