Updated Canal prometheus (markdown)

lcybo
2018-08-18 11:26:57 +08:00
parent 256b1624f0
commit a39d5d32e6

@@ -51,31 +51,26 @@ Canal server 性能指标监控基于prometheus的实现。
详见:[prometheus/client_java](https://github.com/prometheus/client_java) 详见:[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 clamp_max(rate(canal_instance_sink_blocking_time{destination="example"}[2m]), 1000) / 10
``` ```
**sink线程idle时间片比例(向store中put events时)。若idle占比很高,则store总体上处于满的状态,client的consume速度低于server的produce速度** **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 clamp_max(rate(canal_instance_publish_blocking_time{destination="example"}[2m]), 1000) / 10
``` ```
**dump线程idle时间片比例(仅parallel mode, dump线程向disruptor发布event时)。若idle占比较高:** **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.** **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 canal_instance_traffic_delay / 1000
``` ```
@@ -86,27 +81,25 @@ canal_instance_traffic_delay / 1000
**2. Limitations: 如果store满了(恰好store中的数据包含最新的position,且MySQL binlog停止更新),且client暂停消费,那么delay会不断增长。当然,满足这些条件的概率极低。** **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 rate(canal_instance_received_binlog_bytes{destination="example"}[2m]) / 1024
``` ```
**'Sink线程空闲比'与'Dump线程空闲比'都很低,delay还是很高的情况,请查看binlog接收速率是否符合预期。** **Dump线程接受binlog所占用带宽。当'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)
``` ```
rate(canal_instance_client_bytes{destination="example"}[2m]) / 1024 rate(canal_instance_client_bytes{destination="example"}[2m]) / 1024
``` ```
**Instance client订阅后消费所占用的带宽。** **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) * TPS(MySQL transaction)