基于 Prometheus 监控告警

Table of Contents

1 监控告警组件

prom.png

1.1 上报

Prometheus 提供了各种 exporter,除了业务之外的组件(Node,Redis,MySQL等)基本已经支持,业务自身的需要对接 Prometheus Client API。

1.2 metrics 收集

Prometheus 中包含 TSDB(时间序列 DB),用作数据存储。Prometheus 采用的是 pull 的方案,配置之后会按照规则定时获取 metrics 并存储到 TSDB 中,TSDB 可以序列化到本地(SSD 比较好)。

1.3 UI 显示

Promethues 有自己的 Web UI,但是比较简陋。业内的做法是对接 Grafana 显示数据。Grafana 提供了丰富的 Dashboards,直接导入即可。

1.4 告警

Grafana 自身是支持告警的,但是比较蛋疼的点在于告警规则不支持模板变量,那就约等于没有了···

业内常用的做法是使用 Alertmanager,它提供了多种告警策略,甚至包含了 Webhook 的方式(自定义告警、对接自有的告警系统)。

2 Prometheus

2.1 查询

2.1.1 函数(Functions)

2.1.1.1 irate 与 rate

irate(v range-vector) 计算范围内时间序列的 每秒 瞬时增加率,是 基于最后两个点 计算的。数值中断(比如机器重启,计数器重置)会自动调整。

rate(v range-vector) 计算范围内事件序列的 平均每秒 的增长率,是 基于所有数据点的

irate 和 rate 都只能和计数器(Counter)一起使用。因为两个计算的算法不同,所以使用场景略微不同:

  • irate 适用于快速变化计数器
  • rate 适用于告警以及计数器缓慢变化的计数场景下的图形展示

不管是 irate 还是 rate 最终的结果是速率,不是增长的值,这一点很重要。有如下样本数据:

2201 @1570868068.053
2204 @1570868083.053
2205 @1570868098.053
2216 @1570868113.053

irate 的计算方法为:

(2216-2205)/(1570868113.053-1570868098.053) = 0.7333333333333333

rate 的计算方法为:

(2216-2205)/(1570868113.053-1570868098.053) = 0.7333333333333333
(2205-2204)/(1570868098.053-1570868083.053) = 0.06666666666666667
(2204-2201)/(1570868083.053-1570868068.053) = 0.2
(0.7333333333333333 + 0.06666666666666667 + 0.2) / 3 = 0.3333333333333333

一开始对 TSDB 不是很了解的情况下,不自己算一下还是不是很好理解的。

根据上面的计算方法也可以看出:

  • 对于 irate 时间段的选择 [1m] 还是 [5m] ,只要有数据,就没区别; 而 rate 的区别就很大,时间越长越平滑;
  • rate 不会把数值中的毛刺直接暴露出来,通过平均值计算潜在的问题就是会有 长尾问题

选择 irate 还是 rate 视业务场景而定。