mirror of
https://github.com/alibaba/canal.git
synced 2026-11-04 00:30:15 +08:00
Updated Canal prometheus (markdown)
@@ -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
|
||||||
|

|
||||||
```
|
```
|
||||||
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)
|
||||||
|

|
||||||
```
|
```
|
||||||
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)
|
||||||
|

|
||||||
```
|
```
|
||||||
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)
|
||||||
|
|||||||
Reference in New Issue
Block a user