Prometheus监控神器（Rules篇）

本章主要对如何使用Prometheus与Alertmanager组件集成配置，以及对警报规则 Rules 的俩种类型及其模板内容进行讲解。node

与Alertmanager集成

Prometheus把产生的警报发给Alertmanager进行处理时，须要在Prometheus使用的配置文件中添加关联Alertmanager的组件的对应配置信息。web

alerting:
  alert_relabel_configs:
    [ - <relabel_config> ... ]
  alertmanagers:
    [ - <alertmanager_config> ... ]
# alertmanagers 为 alertmanager_config 数组，

配置范例：正则表达式

alerting:
  alert_relabel_configs: # 动态修改 alert 属性的规则配置。
    - source_labels: [dc] 
      regex: (.+)\d+
      target_label: dc1
  alertmanagers:
    - static_configs:
        - targets: ['127.0.0.1:9093'] # 单实例配置
        #- targets: ['172.31.10.167:19093','172.31.10.167:29093','172.31.10.167:39093'] # 集群配置
  - job_name: 'Alertmanager'
    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.
    static_configs:
    - targets: ['localhost:19093']

上面的配置中的 alert_relabel_configs是指警报从新标记在发送到Alertmanager以前应用于警报。它具备与目标从新标记相同的配置格式和操做，外部标签标记后应用警报从新标记，主要是针对集群配置。redis

这个设置的用途是确保具备不一样外部label的HA对Prometheus服务端发送相同的警报信息。数组

Alertmanager 能够经过 static_configs 参数静态配置，也可使用其中一种支持的服务发现机制动态发现，咱们上面的配置是静态的单实例，针对集群HA配置，后面会讲。浏览器

此外，relabel_configs 容许从发现的实体中选择 Alertmanager，并对使用的API路径提供高级修改，该路径经过 __alerts_path__ 标签公开。微信

完成以上配置后，重启Prometheus服务，用以加载生效，也可使用前文说过的热加载功能，使其配置生效。而后经过浏览器，访问 http://192.168.1.220:19090/alerts 就能够看 inactive pending firing 三个状态，没有警报信息是由于咱们尚未配置警报规则 rules。app

警报规则

警报规则 rules 使用的是 yaml 格式进行定义，在Prometheus中经过咱们前面讲过的 PromQL 配置实际警报触发条件，Prometheus 会根据设置的警告规则 Ruels 以及配置间隔时间进行周期性计算，当知足触发条件规则会发送警报通知。警报规则加载的是在 prometheus.yml 文件中进行配置，默认的警报规则进行周期运行计算的时间是1分钟，可使用 global 中的 evaluation_interval 来决定时间间隔。curl

范例：编辑器

global:
    evaluation_interval: 15s

警报规则能够指定多个文件，也能够自定到自定义的目录下面，为了管理更为便捷，方便阅读，能够把警报规则拆成多份，用以区分环境，系统，服务等，如：prod，test，dev 等等，而且支持以正则表达式定义。

范例：

rule_files:
    #- "/data/prometheus/rules/*.yml" # 正则表达式，会加在此目录下全部警报规则配置文件
    - "/data/prometheus/rules/ops.yml" # 仅加载ops.yml警报规则文件
    #- "/data/prometheus/rules/prod-*.yml" 
    #- "/data/prometheus/rules/test-*.yml"
    #- "/data/prometheus/rules/dev-*.yml"

如今开始讲警报规则 Rules 的定义，格式为YAML。

groups:
- name: <string>
  rules:
  - alert: <string>
    expr: <string>
    for:  [ <duration> | default 0 ]
    labels:
      [ <lable_name>: <label_value> ]
    annotations:
      [ <lable_name>: <tmpl_string> ]

参数	描述
`- name: <string>`	警报规则组的名称
`- alert: <string>`	警报规则的名称
`expr: <string`	使用PromQL表达式完成的警报触发条件，用于计算是否有知足触发条件
`<lable_name>: <label_value>`	自定义标签，容许自行定义标签附加在警报上，好比`high` `warning`
`annotations: <lable_name>: <tmpl_string>`	用来设置有关警报的一组描述信息，其中包括自定义的标签，以及expr计算后的值。

groups:
- name: operations
  rules:
  - alert: node-down
    expr: up{env="operations"} != 1
    for: 5m
    labels:
      status: High
      team: operations
    annotations:
      description: "Environment: {{ $labels.env }} Instance: {{ $labels.instance }} is Down ! ! !"
      value: '{{ $value }}'
      summary:  "The host node was down 20 minutes ago"

以上就是一个完整 Rules 的配置，若是Prometheus 在周期检测中使用PromQ以env=operations为维度查询，若是当前查询结果中具备标签operations，且返回值都不等于1的时候，发送警报。对于写好的 Rules 能够是经常使用 promtool 来check ruls.yml 的书写格式是否正确。

/usr/local/bin/promtool check rules /data/prometheus/rules/ops.yml
Checking /data/prometheus/rules/ops.yml
  SUCCESS: 7 rules found

对于修改好的rules文件，保存之后，通过检测没有问题，直接从新热加载 Prometheus就能够在页面看到了。对于触发警报规则，比较简单了，直接修改运算值或者去停掉 node-exporter 服务，即可在界面看到警报信息。一个警报在生命周期会有三种状态

状态	描述
`Inactive`	正常状态，未激活警报
`Pending`	已知足触发条件，但没有知足发送时间条件，此条件就是上面rules范例中的 `for 5m` 子句中定义的持续时间
`Firing`	知足条件，且超过了 for 子句中的的指定持续时间5m

带有for子句的警报触发之后首先会先转换成 Pending 状态，而后在转换为 Firing 状态。这里须要俩个周期才能触发警报条件，若是没有设置 for 子句，会直接从 Inactive 状态转换成 Firing状态，而后触发警报，发送给 Receiver 设置的通知人。

在运行过程当中，Prometheus会把Pending或Firing状态的每个警报建立一个 Alerts指标名称，这个能够经过Rules来触发警报测试，直接在UI中Graph查看指标 ALERTS，格式以下：

ALERTS{alertname="alert name",alertstate="pending|firing",<additional alert label>}

当警报处于激活状态 Pending 或者 Firing时候，如上图所示，样本值为1。其余状态为0。则不显示。上图已经触发警报，其警报已经被转发给Alertmanager组件，此时能够在浏览器上经过能够用过9093端口访问，查看警报状态。

如今咱们来讲一下整理下Prometheus从收集监控指标信息到触发警报的过程

状态	描述
`1.定义规则`	在Prometheus配置中，scrape_interval: 15s，默认是1分钟，这个定义是收集监控指标信息的采集周期，同时配置对应的警报规则，能够是全局，也能够单独为某一个metrics定义
`2.周期计算`	对于表达式进行计算时，Prometheus中的配置中配置了 evaluation_interval: 15s，默认也是一分钟，为警报规则的计算周期，`evaluation_interval` 只是全局计算周期值。
`3.1警报状态转换(pending)`	当首次触发警报规则条件成立，表达式为 `true`，而且没有知足警报规则中的for子句中的持续时间时，警报状态切换为 `Pending`
`3.2警报状态转换(firing)`	若下一个计算周期中，表达式仍为 `true`，而且知足警报规则中的for子句的持续时间时，警报状态转换为 `Firing`，即为 `active`，警报会被Prometheus推送到ALertmanager组件
`3.3警报状态转换(period)`	若是在 `evaluation_interval` 的计算周期内，表达式仍是为 `true`，同时知足 for子句的持续时间，持续转发到Alertmanager，这里只是转发状态到Alertmanager，并非直接发送通知到指定通知源
`3.4警报状态转换(resolve)`	只到某个周期，表达式为 `false`，警报状态会变成 `inactive` ，而且会有一个 `resolve`被发送到Alertmanager，用于说明警报故障依解决，发送resolve信息须要本身单独在Alertmanager中定义

Rules类型

Prometheus 支持两种类型的 Rules ，能够对其进行配置，而后按期进行运算：recording rules 记录规则与 alerting rules 警报规则，规则文件的计算频率与警报规则计算频率一致，都是经过全局配置中的 evaluation_interval 定义。

alerting rules

要在Prometheus中使用Rules规则，就必须建立一个包含必要规则语句的文件，并让Prometheus经过Prometheus配置中的rule_files字段加载该文件，前面咱们已经讲过了。其实语法都同样，除了 recording rules 中的收集的指标名称 record: <string> 字段配置方式略有不一样，其余都是同样的。

配置范例：

- alert: ServiceDown
    expr: avg_over_time(up[5m]) * 100 < 50
    annotations:
      description: The service {{ $labels.job }} instance {{ $labels.instance }} is
        not responding for more than 50% of the time for 5 minutes.
      summary: The service {{ $labels.job }} is not responding
  - alert: RedisDown
    expr: avg_over_time(redis_up[5m]) * 100 < 50
    annotations:
      description: The Redis service {{ $labels.job }} instance {{ $labels.instance
        }} is not responding for more than 50% of the time for 5 minutes.
      summary: The Redis service {{ $labels.job }} is not responding
  - alert: PostgresDown
    expr: avg_over_time(pg_up[5m]) * 100 < 50
    annotations:
      description: The Postgres service {{ $labels.job }} instance {{ $labels.instance
        }} is not responding for more than 50% of the time for 5 minutes.
      summary: The Postgres service {{ $labels.job }} is not responding

recording rules

recording rules 是提早设置好一个比较花费大量时间运算或常常运算的表达式，其结果保存成一组新的时间序列数据。当须要查询的时候直接会返回已经计算好的结果，这样会比直接查询快，也减轻了PromQl的计算压力，同时对可视化查询的时候也颇有用，可视化展现每次只须要刷新重复查询相同的表达式便可。

在配置的时候，除却 record: <string> 须要注意，其余的基本上是同样的，一个 groups 下能够包含多条规则 rules ，Recording 和 Rules 保存在 groups 内，Groups 中的规则以规则的配置时间间隔顺序运算，也就是全局中的 evaluation_interval 设置。

配置范例：

groups:
- name: http_requests_total
  rules:
  - record: job:http_requests_total:rate10m
    expr: sum by (job)(rate(http_requests_total[10m]))
    lables:
      team: operations
  - record: job:http_requests_total:rate30m
    expr: sum by (job)(rate(http_requests_total[30m]))
    lables:
      team: operations

上面的规则其实就是根据 record 规则中的定义，Prometheus 会在后台完成 expr 中定义的 PromQL 表达式周期性运算，以 job 为维度使用 sum 聚合运算符计算函数rate 对http_requests_total 指标区间 10m 内的增加率，而且将计算结果保存到新的时间序列 job:http_requests_total:rate10m 中，同时还能够经过 labels 为样本数据添加额外的自定义标签，可是要注意的是这个 Lables 必定存在当前表达式 Metrics 中。

使用模板

模板是在警报中使用时间序列标签和值展现的一种方法，能够用于警报规则中的注释（annotation）与标签（lable）。模板其实使用的go语言的标准模板语法，并公开一些包含时间序列标签和值的变量。这样查询的时候，更具备可读性，也能够执行其余PromQL查询来向警报添加额外内容，ALertmanager Web UI中会根据标签值显示器警报信息。

{{ $lable.<lablename>}} 能够获取当前警报实例中的指定标签值

{{ $value }} 变量能够获取当前PromQL表达式的计算样本值。

groups:
- name: operations
  rules:
# monitor node memory usage
  - alert: node-memory-usage
    expr: (1 - (node_memory_MemAvailable_bytes{env="operations",job!='atlassian'} / (node_memory_MemTotal_bytes{env="operations"})))* 100 > 90
    for: 1m
    labels:
      status: Warning
      team: operations
    annotations:
      description: "Environment: {{ $labels.env }} Instance: {{ $labels.instance }} memory usage above {{ $value }} ! ! !"
      summary:  "node os memory usage status"

调整好rules之后，咱们可使用 curl -XPOST http://localhost:9090/-/reload 或者对Prometheus服务重启，让警报规则生效。

这个时候，咱们能够把阈值调整为 50 来进行故障模拟操做，这时在去访问UI的时候，当持续1分钟知足警报条件，实际警报状态已转换为 Firing，能够在 Annotations中看到模板信息 summary 与 description 已经成功显示。

须要注意的是，一个稳定健壮的Prometheus监控系统中，要尽可能使用模板化，这样会下降性能开销（Debug调试信息等），同时也易于维护。

下面网站收录了当前大部分的rules规则，你们能够对应本身的环境，配置相关服务的Rules。

[Prometheus警报规则收集(https://awesome-prometheus-alerts.grep.to/)

专辑：

监控神器-Prometheus

推荐个大佬讲的Ceph课程，如今正在优惠中~

欢迎关注个人公众号！

本文分享自微信公众号 - Kubernetes技术栈（k8stech）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。