位点滞后怎么监控
很多团队只看下游 Kafka 的消费 lag，但同步链路的哪一段掉了都可能导致数据停更。更可靠的做法是同时采集两端位点：源端当前 binlog 位点（文件序号与偏移）与工具已确认的消费位点，两者相减换算出落后字节数与估算时间，再记录源写入速率与消费速率两条曲线。两个专门的判据最有用——位点长时间不推进，说明消费停滞；binlog 保留余量不足，说明一旦消费中断就可能永久丢失可回溯范围。
基本信息
| 源端位点 | binlog 文件名与偏移（MySQL 用 SHOW MASTER STATUS，8.4 起改用 SHOW BINARY LOG STATUS） |
|---|---|
| 消费位点 | 工具位点表或连接器 offset（Canal、Debezium、Flink CDC 各不同） |
| 换算指标 | 落后字节数、估算落后时间、保留余量 |
| 观测频率 | 通常 1 到 5 分钟一次，与告警时限匹配 |
| 常见告警 | 位点 15 分钟未推进、保留余量不足 2 个文件 |
典型使用场景
- 大促或批量写入高峰前确认同步链路余量，评估是否会被追上
- 故障后确认位点已恢复到正常推进速度，而不是只看进程是否存活
- 排查报表停更：判断是源端没数据还是消费端停滞
- 容量评估：根据写入速率与消费速率差决定是否扩容消费线程
- 变更窗口前检查 binlog 保留策略与备份策略是否满足回溯要求
采集与换算
采集与换算
-- 源端：当前写入位点与所有 binlog 文件（含最早的，用于算保留余量）
SHOW MASTER STATUS; -- MySQL 8.4 起为 SHOW BINARY LOG STATUS
SHOW BINARY LOGS;
-- 消费端：以工具位点表为例，取已确认位点
SELECT source_name, binlog_file, binlog_pos, update_time
FROM cdc_position_table WHERE source_name = 'order_db';
# 换算（脚本侧完成）
# 落后字节 ≈ (源文件序号 - 消费文件序号) × 平均文件大小 + 偏移差
# 保留余量 = 最早 binlog 文件序号 - 消费位点文件序号（单位：个文件）
# 告警：位点 15 分钟未推进；保留余量 < 2 个文件监控项与判据
| 监控项 | 数据来源 | 异常判据 | 含义 |
|---|---|---|---|
| 位点推进 | 消费位点表按时间对比 | 15 分钟内无变化 | 消费停滞或任务挂了 |
| 落后字节 | 源位点减消费位点 | 持续增长且无回落 | 消费跟不上写入 |
| 保留余量 | SHOW BINARY LOGS 最早文件 | 小于 2 个文件 | 中断后可能无法续读 |
| 消费速率 | 消费条数按分钟统计 | 显著低于源写入速率 | 解析或写入成为瓶颈 |
源端位点与消费位点要同时留存历史：复盘时才能区分是写入突增（源曲线陡升）还是消费停滞（消费曲线走平），两者的处置完全不同。
被监控机器的时钟与数据库服务器不同步时，换算出的滞后时间会失真；采集脚本里的时间统一取数据库时间或做时钟校正。
只监控 Kafka lag 会漏掉链路其他段的问题：文件未上传、连接器未提交位点、目标端写入变慢，都可能表现为下游 lag 正常但数据不完整。