通过promethous监控canal的一些实战

今年写过几篇canal的文章，作为基于mysql binlog的消息订阅和消费工具，非常具有生产力，今天从监控的角度理解下canal，监控可以从两个维度考虑，一方面是内部组件监控，比如dump、slink等过程的运行情况，另外就是从消费角度考虑。

canal本身就暴露了promethous的端点服务，所以在promethous上安装一个dashborard就能完成。

添加canal job：

- job_name: 'canal'
    static_configs:
    - targets: ['localhost:11112']

端口配置即为canal.properties中的canal.metrics.pull.port。

首先理解下exporter关键指标，比如canal_instance_traffic_delay查询canal server和master的延时时间；canal_instance_put_delay表示store put操作events的延时；canal_instance_ack_delay表示client的消费情况。

举个例子理解下canal内部组件的工作过程，canal_instance_publish_blocking_time 如果长时间空闲，有两种情况：

• 如果Sinking blocking比例也很高，则瓶颈是因为client的消费速度相对较慢。

• 如果Sinking blocking比例较低，那么server端parser是性能瓶颈，这时候可能需要启多个cpu。

仔细理解下，看看我们的截图：

为什么client信息没有呢，自己认为client代表python这样的客户端，canal后面对接的kafka不算。

接下去看看报警情况，主要两个报警：

1：canal和master dump的情况

比如超过5s就报警，不过上图也看出超过5s的情况很多，这不代表有问题，具体可以参考https://github.com/alibaba/canal/issues/3310

2：canal 消费速度

由于对接的是kafka，所以基本没有延时，那为啥要监控？比如kafka挂了呢，当然业务消费的监控可以看kafka topic长度。

注意这里面配置的destination是canal的instance的名字，而不是kafka topic名字，如果配置的时候遇到问题，我习惯去prometheus graph上看，见下图，注意特殊符号：

总体来说，理解promethous上canal的业务指标，对于理解canal的工作原理很有帮助。