From a39d5d32e60168d5e09ad33b31c19d29b8c0ac5b Mon Sep 17 00:00:00 2001 From: lcybo Date: Sat, 18 Aug 2018 11:26:57 +0800 Subject: [PATCH] Updated Canal prometheus (markdown) --- Canal-prometheus.md | 41 +++++++++++++++++------------------------ 1 file changed, 17 insertions(+), 24 deletions(-) diff --git a/Canal-prometheus.md b/Canal-prometheus.md index bc25e83..b8a9db6 100644 --- a/Canal-prometheus.md +++ b/Canal-prometheus.md @@ -51,31 +51,26 @@ Canal server 性能指标监控基于prometheus的实现。 详见：[prometheus/client_java](https://github.com/prometheus/client_java) -## Prometheus expression 与相应 use case -_单表达式示例图为prometheus自带展示层工具，最终dashboard效果图请看grafana章节_ +## 监控指标详述与应用场景 -* Sink线程空闲比 +##### Idle +![Image text](https://raw.githubusercontent.com/lcybo/canal/master/images/idle.PNG) ``` clamp_max(rate(canal_instance_sink_blocking_time{destination="example"}[2m]), 1000) / 10 ``` **sink线程idle时间片比例(向store中put events时)。若idle占比很高，则store总体上处于满的状态，client的consume速度低于server的produce速度** - -_简单说明一下range-vector,通俗来说表达式会用时间点前range-vector period内的所有samples参与运算。_ -_range-vector值如果太小，图会碎片化；反之，实时性会比较差，不能及时反应变化。请结合scrape_interval设定合理的值。_ - - -* Dump线程空闲比 ``` clamp_max(rate(canal_instance_publish_blocking_time{destination="example"}[2m]), 1000) / 10 ``` **dump线程idle时间片比例(仅parallel mode, dump线程向disruptor发布event时)。若idle占比较高：** -**1. Sinking idle ratio也很高，则总体还是因为client的consume速度相对较慢。** +**1. Sinking idle ratio也很高，则瓶颈是因为client的consume速度相对较慢。** **2. Sinking idle ratio较低，那么server端parser是性能瓶颈，可参考[Performance](https://github.com/alibaba/canal/wiki/Performance)进行tuning.** -* Delay(seconds) +##### Delay(seconds) +![Image text](https://raw.githubusercontent.com/lcybo/canal/master/images/delay.PNG) ``` canal_instance_traffic_delay / 1000 ``` @@ -86,27 +81,25 @@ canal_instance_traffic_delay / 1000 **2. Limitations: 如果store满了(恰好store中的数据包含最新的position，且MySQL binlog停止更新)，且client暂停消费，那么delay会不断增长。当然，满足这些条件的概率极低。** -* Binlog接收带宽(KB/s) +##### 网络带宽(KB/s) +![Image text](https://github.com/lcybo/canal/blob/master/images/network.PNG?raw=true) ``` rate(canal_instance_received_binlog_bytes{destination="example"}[2m]) / 1024 ``` -**'Sink线程空闲比'与'Dump线程空闲比'都很低，delay还是很高的情况，请查看binlog接收速率是否符合预期。** - - -* TPS(Binlog events) -``` -rate(canal_instance_store_consume_seq{destination="example"}[2m]) -``` -**Canal instance client消费TPS(以binlog event为单位)，即canal instance最终的整体性能。** - - -* Client消费带宽(KB/s) +**Dump线程接受binlog所占用带宽。当'Sink线程空闲比'与'Dump线程空闲比'都很低，delay却比较高的情况，请查看binlog接收速率是否符合预期。** ``` rate(canal_instance_client_bytes{destination="example"}[2m]) / 1024 ``` **Instance client订阅后消费所占用的带宽。** -**注意：client在binlog无更新时busy poll，所占用的带宽也是颇为可观的，如上图。** + + +##### TPS(Binlog events) + +``` +rate(canal_instance_store_consume_seq{destination="example"}[2m]) +``` +**Canal instance client消费TPS(以binlog event为单位)，即canal instance最终的整体性能。** * TPS(MySQL transaction)