Debezium 监控指标是什么
Debezium 以 Kafka Connect 连接器的形式运行，指标通过 Connect 的 JMX 暴露：MilliSecondsBehindSource 反映事件时间与当前处理时间之间的滞后，TotalNumberOfEventsSeen 统计已处理事件总量，NumberOfEventsFiltered 反映过滤规则命中的情况。监控的重点是滞后持续上升与事件速率骤降这两类信号——它们分别对应「追不上」与「链路断了」，而不是简单的任务是否在运行。
基本信息
| MilliSecondsBehindSource | 源端事件时间到当前处理时刻的滞后毫秒数 |
|---|---|
| TotalNumberOfEventsSeen | 连接器累计处理的事件数 |
| NumberOfEventsFiltered | 被过滤掉的事件数，用于确认白名单是否按预期生效 |
| 暴露方式 | Kafka Connect 的 JMX 指标，按 connector 维度区分 |
| 采集方式 | JMX 抓取或指标导出后接入监控系统 |
| 版本差异 | 指标名与可用性随连接器版本略有差异，接入前先确认指标存在 |
典型使用场景
- 滞后告警：滞后持续上升说明消费追不上写入，需要扩容或优化
- 链路存活检查：事件数长时间不增长，说明源端无变更或链路已断
- 过滤规则验证：过滤计数变化可确认白名单调整是否生效
- 容量评估：结合事件速率与滞后判断是否需要增加任务实例
- 故障复盘：用滞后曲线与事件速率曲线还原故障发生与恢复时刻
用 JMX 工具查看连接器指标
用 JMX 工具查看连接器指标
# 连接器维度的指标：关注滞后与累计事件数
kafka-run-class.sh kafka.tools.JmxTool \
--object-name kafka.connect:type=connector-metrics,connector=mysql-cdc-orders
# 任务维度的指标：定位是哪个任务（分区级）出现滞后
kafka-run-class.sh kafka.tools.JmxTool \
--object-name kafka.connect:type=connector-task-metrics,connector=mysql-cdc-orders,task=0指标读法
| 指标 | 含义 | 异常提示 |
|---|---|---|
| MilliSecondsBehindSource | 处理进度落后源端的毫秒数 | 持续上升说明追不上写入，需扩容或排查下游 |
| TotalNumberOfEventsSeen | 累计处理事件数 | 长时间不变说明源端无变更或链路中断 |
| NumberOfEventsFiltered | 被过滤的事件数 | 与预期不符说明过滤规则配置有误 |
| 任务级滞后 | 单个任务的进度 | 仅个别任务滞后，通常是分区倾斜 |
只看 Kafka 消费位移滞后（lag）是不够的：它反映的是消息积压，而 MilliSecondsBehindSource 反映的是数据从发生到现在的时间差，后者才更接近业务真正感知的数据延迟。
告警不要只按平均值阈值：短时毛刺会掩盖持续的大延迟，用持续时长条件（如连续 10 分钟超阈值）或分位数更贴近真实影响。