最终一致性系统要监控哪些指标？
简化版
最终一致系统最重要的不是“消息是否消费”，而是业务状态多久收敛。 应监控未一致对象数量、年龄分布、最老年龄、各阶段延迟、重试和死信、版本水位差、对账差异与补偿吞吐。 指标必须按业务类型和风险分层，并能从业务 ID 追踪源提交、事件、消费、落库和修复全过程。
详细版
端到端指标包括 P50/P95/P99 convergence latency、out-of-sync count、oldest inconsistency age 和超窗数量。 链路指标包括 outbox backlog、MQ lag、消费失败、下游写入冲突、补偿积压与对账覆盖率。
只看队列 lag 会漏掉消费成功但业务写失败、错误数据被 ACK 或事件根本未发布。 用 reconciliation 作为独立验证面。 告警同时考虑数量、年龄和业务金额，避免一条高额资金差异被平均数掩盖。
完整版教学
一、定义“收敛完成”
先为每类流程定义源状态与目标状态。 例如订单 PAID 后，账务凭证存在且金额、版本匹配才算收敛。 消费者返回 200 不代表业务一致。
可观测性必须围绕业务不变量，而不是只围绕中间件健康。
二、黄金指标
| 指标 | 含义 |
|---|---|
| out_of_sync_count | 当前不一致对象数 |
| oldest_age | 最老不一致持续时间 |
| convergence_latency | 从源提交到目标确认 |
| over_window_count | 超过 SLO 的对象 |
| repair_rate | 单位时间修复数 |
同时按业务类型、风险等级和状态聚合。
三、分段延迟
source commit
-> event published
-> broker available
-> consumer received
-> target committed
-> reconciliation verified为每段记录时间与 correlationId。 端到端慢时才能判断是 outbox、队列、消费还是目标库。
四、积压与净吞吐
队列每分钟新增 10 万、消费 12 万，净清理 2 万。 积压 100 万至少需要约 50 分钟，且前提是新增和消费速率保持稳定、净清理能力不再恶化。 恢复 ETA 要按净吞吐计算。 监控分区不均，平均 lag 会掩盖热点分区。
五、失败与重试
统计瞬时错误、业务拒绝、版本冲突、解析错误和永久失败。 观察 attempt 分布、next retry age、dead-letter 数与人工队列。 成功率 99.9% 在亿级事件下仍可能每天十万失败。 必须结合绝对数量和影响金额。
六、独立对账
对账不依赖同一事件链路，否则共同故障会同时失明。 按共同水位比较 count、金额、状态和哈希。 监控扫描覆盖率、上次成功时间、差异发现到修复时间。 修复后再次对账确认闭环。
七、追踪与基数
单个业务 ID 用日志/Trace 查询，不全部作为时序标签。 时序指标使用业务类型、区域、错误类等有限维度。 采样 Trace 不能替代全量计数与对账。 敏感数据进入日志前脱敏，correlationId 不含用户秘密。
八、常见误区与追问
- 误区：MQ 无积压就一致。 业务写错后消息也可能已 ACK。
- 误区：只看平均收敛时间。 尾部对象决定违约与风险。
- 误区：重试成功率高就安全。 永久失败绝对数量仍可能很大。
- 误区：Trace 抽样能替代对账。 抽样无法证明全量不变量。
- 追问：最重要的告警是什么？ 超窗数量与最老不一致年龄。
- 追问：如何估算恢复时间？ backlog 除以净处理吞吐。
- 追问：如何定位单笔？ 用业务键串起源、事件、消费、目标和补偿记录。
九、加强记忆
- 先定义业务何时算一致。
- 看数量、年龄、尾延迟和超窗。
- 分段观测发布、队列、消费与目标写入。
- 用净吞吐估算积压恢复。
- 独立对账验证全链路，Trace 负责单笔定位。