关于prometheus:Prometheus监控神器Rules篇

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

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

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 之前利用于警报。它具备与指标从新标记雷同的配置格局和操作，内部标签标记后利用警报从新标记，次要是针对集群配置。

这个设置的用处是确保具备不同内部 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。

警报规定 rules 应用的是 yaml 格局进行定义，在 Prometheus 中通过咱们后面讲过的 PromQL 配置理论警报触发条件，Prometheus 会依据设置的正告规定 Ruels 以及配置间隔时间进行周期性计算，当满足触发条件规定会发送警报告诉。
警报规定加载的是在 prometheus.yml 文件中进行配置，默认的警报规定进行周期运行计算的工夫是 1 分钟，能够应用 global 中的 evaluation_interval 来决定工夫距离。

范例：

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>]

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 服务，便可在界面看到警报信息。一个告警在生命周期会有三种状态

带有 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 中定义 |

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

要在 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 是提前设置好一个比拟破费大量工夫运算或常常运算的表达式，其后果保留成一组新的工夫序列数据。当须要查问的时候间接会返回曾经计算好的后果，这样会比间接查问快，同时也加重了 PromQl 的计算压力，同时对可视化查问的时候也很有用，可视化展现每次只须要刷新反复查问雷同的表达式即可。

在配置的时候，除却 record: <string> 须要留神，其余的基本上是一样的，一个 groups 下能够蕴含多条规定 rules，Recording 和 Rules 保留在 group 内，Group 中的规定以规定的配置工夫距离程序运算，也就是全局中的 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-al…

关于prometheus:Prometheus监控神器Rules篇

与 Alertmanager 集成

警报规定

Rules 类型

alerting rules

recording rules

应用模板