Prometheus 配置告警规则

2023-10-18

字数统计: 2.8k字 | 阅读时长≈ 11分

官方文档: Alerting Rules
Prometheus 中文文档: Prometheus 中文文档

Prometheus 告警处理

告警能力在Prometheus的架构中被划分为两个部分:

在Prometheus Server中定义告警规则以及产生告警;
Alertmanager组件则用于处理这些由Prometheus产生的告警。

Alertmanager 即 Prometheus 体系中告警的统一处理中心。Alertmanager 提供了多种内置第三方告警通知方式，同时还提供了对 Webhook 通知的支持，通过Webhook用户可以完成对告警更多个性化的扩展。

Prometheus 告警简介

在Prometheus中一条告警规则主要由以下几部分组成：

告警名称: 用户需要为告警规则命名，当然对于命名而言，需要能够直接表达出该告警的主要内容
告警规则: 告警规则实际上主要由 PromQL 进行定义，其实际意义是当表达式（PromQL）查询结果持续多长时间（During）后出发告警

在Prometheus中，还可以通过Group（告警组）对一组相关的告警进行统一定义。当然这些定义都是通过YAML文件来统一管理的。

Alertmanager特性

Alertmanager除了提供基本的告警通知能力以外，还主要提供了如：分组、抑制以及静默等告警特性：

分组

分组机制可以将详细的告警信息合并成一个通知。在某些情况下，比如由于系统宕机导致大量的告警被同时触发，在这种情况下分组机制可以将这些被触发的告警合并为一个告警通知，避免一次性接受大量的告警通知，而无法对问题进行快速定位。告警分组，告警时间，以及告警的接受方式可以通过Alertmanager的配置文件进行配置

抑制

抑制是指当某一告警发出后，可以停止重复发送由此告警引发的其它告警的机制。抑制机制同样通过Alertmanager的配置文件进行设置。

静默

静默提供了一个简单的机制可以快速根据标签对告警进行静默处理。如果接收到的告警符合静默的配置，Alertmanager则不会发送告警通知。静默设置需要在Alertmanager的Werb页面上进行设置。

自定义 Prometheus 告警规则

Prometheus中的告警规则允许你基于PromQL表达式定义告警触发条件，Prometheus后端对这些触发规则进行周期性计算，当满足触发条件后则会触发告警通知。默认情况下，用户可以通过Prometheus的Web界面查看这些告警规则以及告警的触发状态。当Promthues与Alertmanager关联之后，可以将告警发送到外部服务如Alertmanager中并通过Alertmanager可以对这些告警进行进一步的处理。

定义告警规则

一条典型的告警规则如下所示：

groups:
- name: example
    rules:
    - alert: HighErrorRate
    expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5
    for: 10m
    labels:
        severity: page
    annotations:
        summary: High request latency
        description: description info

在告警规则文件中，我们可以将一组相关的规则设置定义在一个 groups 下。在每一个 group 中我们可以定义多个告警规则（rule）。

一条告警规则主要由以下几部分组成：

alert: 告警规则的名称；
expr: 基于 PromQL 表达式的告警触发条件，用于计算是否有时间序列满足该条件；
for: 评估等待时间，可选参数。用于表示只有当触发条件持续一段时间后才发送告警。在等待期间新产生告警的状态为 pending；
labels: 自定义标签，允许用户指定要附加到告警上的一组附加标签；
annotations: 用于指定一组附加信息，比如用于描述告警详细信息的文字等，annotations 的内容在告警产生时会一同作为参数发送到 Alertmanager。

为了能够让 Prometheus 能够启用定义的告警规则，我们需要在 Prometheus 全局配置文件中通过 rule_files 指定一组告警规则文件的访问路径，Prometheus 启动后会自动扫描这些路径下规则文件中定义的内容，并且根据这些规则计算是否向外部发送通知

1 2	rule_files: [ - <filepath_glob> ... ]

默认情况下 Prometheus 会每分钟对这些告警规则进行计算，如果用户想定义自己的告警计算周期，则可以通过 evaluation_interval 来覆盖默认的计算周期：

1 2	global: [ evaluation_interval: <duration> \| default = 1m ]

模板化

一般来说，在告警规则文件的 annotations 中使用 summary 描述告警的概要信息，description 用于描述告警的详细信息。同时 Alertmanager 的UI也会根据这两个标签值，显示告警信息。为了让告警信息具有更好的可读性，Prometheus 支持模板化 labels 和 annotations 中标签的值。

通过 $labels.<labelname> 变量可以访问当前告警实例中指定标签的值。$value 则可以获取当前 PromQL 表达式计算的样本值。

# To insert a firing element's label values:
{{ $labels.<labelname> }}
# To insert the numeric expression value of the firing element:
{{ $value }}

例如，可以通过模板化优化 summary 以及 description 的内容以提高可读性：

groups:
- name: example
  rules:

  # Alert for any instance that is unreachable for >5 minutes.
  - alert: InstanceDown
    expr: up == 0
    for: 5m
    labels:
      severity: page
    annotations:
      summary: "Instance {{ $labels.instance }} down"
      description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes."

  # Alert for any instance that has a median request latency >1s.
  - alert: APIHighRequestLatency
    expr: api_http_request_latencies_second{quantile="0.5"} > 1
    for: 10m
    annotations:
      summary: "High request latency on {{ $labels.instance }}"
      description: "{{ $labels.instance }} has a median request latency above 1s (current value: {{ $value }}s)"

查看告警状态

如下所示，用户可以通过Prometheus WEB界面中的Alerts菜单查看当前Prometheus下的所有告警规则，以及其当前所处的活动状态。

同时对于已经 pending 或者 firing 的告警，Prometheus 也会将它们存储到时间序列 ALERTS{} 中。可以通过以下表达式查询告警实例

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

样本值为1表示当前告警处于活动状态（pending或者firing），当告警从活动状态转换为非活动状态时，样本值则为 0。

实例-定义主机监控告警

修改 Prometheus 配置文件 prometheus.yml ,添加以下配置：
1
2
rule_files:
- "rules/host_status.yml"

在目录 /usr/local/prometheus/rules/ 目录下创建告警文件 host_status.yml 文件，内容如下：

groups:
- name: 'Host Status Monitor'
  rules:
  - alert: HostDown
    expr: up == 0
    for: 1m
    labels:
      severity: 'Critical'
    annotations:
      summary: "Host {{ $labels.instance }} down"
      description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 1 minutes."

  - alert: HostCpuUsageAlert
    expr: sum(avg without (cpu)(irate(node_cpu_seconds_total{mode!='idle'}[5m]))) by (instance) > 0.85
    for: 5m
    labels:
      severity: 'Warning'
    annotations:
      summary: "Host {{ $labels.instance }} CPU usage high"
      description: "{{ $labels.instance }} CPU usage above 85% (current value: {{ $value }})"

  - alert: HostMemUsageAlert
    expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes)/node_memory_MemTotal_bytes > 0.85
    for: 5m
    labels:
      serverity: 'Warning'
    annotations:
      summary: "Host {{ $labels.instance }} MEM usage high"
      description: "{{ $labels.instance }} MEM usage above 85% (current value: {{ $value }})"

  - alert: HostDiskUsageAlert
    expr: (node_filesystem_size_bytes - node_filesystem_free_bytes) / node_filesystem_size_bytes > 0.85
    for: 1m
    labels:
      serverity: 'Warning'
    annotations:
      summary: "Host {{ $labels.instance }} Disk partition usage high"
      description: 'Host {{ $labels.instance }} Disk partition "{{ $labels.mountpoint }}" usage above 85% (current value: {{ $value }}).'

重启 Prometheus 服务或者使用以下命令重新加载配置文件
1
curl -X POST http://localhost:9090/-/reload
打开浏览器访问 http://localhost:9090/rules 可以查看当前所有已经加载的规则文件。

切换到 Alerts 标签 http://127.0.0.1:9090/alerts 可以查看当前告警的活动状态。

部署 AlertManager

Alertmanager和Prometheus Server一样均采用Golang实现，并且没有第三方依赖。一般来说我们可以通过以下几种方式来部署Alertmanager：二进制包、容器以及源码方式安装。(此处略…)

创建 alertmanager 配置文件

AlertManager 解压后会包含一个默认的 alertmanager.yml 配置文件，内容如下所示：

global:
  resolve_timeout: 5m

route:
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h
  receiver: 'web.hook'
receivers:
- name: 'web.hook'
  webhook_configs:
  - url: 'http://127.0.0.1:5001/'
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'dev', 'instance']

AlertManager 的配置主要包含两个部分：路由(route)以及接收器(receivers)。所有的告警信息都会从配置中的顶级路由(route)进入路由树，根据路由规则将告警信息发送给相应的接收器。

在 Alertmanager 中可以定义一组接收器，比如可以按照角色(比如系统运维，数据库管理员)来划分多个接收器。接收器可以关联邮件，Slack以及其它方式接收告警信息。当前配置文件中定义了一个默认的接收者 default-receiver 由于这里没有设置接收方式，目前只相当于一个占位符。关于接收器的详细介绍会在后续章节介绍。

在配置文件中使用 route 定义了顶级的路由，路由是一个基于标签匹配规则的树状结构。所有的告警信息从顶级路由开始，根据标签匹配规则进入到不同的子路由，并且根据子路由设置的接收器发送告警。目前配置文件中只设置了一个顶级路由route并且定义的接收器为default-receiver。因此，所有的告警都会发送给default-receiver。关于路由的详细内容会在后续进行详细介绍。

查看 AlertManager 运行状态

Alertmanager 启动后可以通过 http://serverIP:9093 访问，如下

Alerts 菜单下可以查看 Alertmanager 接收到的告警内容。Silences 菜单下则可以通过UI创建静默规则，这部分我们会在后续部分介绍。进入 Status 菜单，可以看到当前系统的运行状态以及配置信息。

关联 Prometheus 与 Alertmanager

在 Prometheus 的架构中被划分成两个独立的部分。Prometheus 负责产生告警，而 Alertmanager 负责告警产生后的后续处理。因此 Alertmanager 部署完成后，需要在Prometheus 中设置 Alertmanager 相关的信息。

编辑 Prometheus 配置文件 prometheus.yml,并添加以下内容

alerting:
  alertmanagers:
    - static_configs:
        - targets: ['localhost:9093']

重启 Prometheus 服务，成功后，可以从 http://192.168.33.10:9090/config 查看 alerting 配置是否生效。

此时，手动关闭被监控节点的 node_exporter 服务，模仿服务器宕机状态：

1	systemctl stop node_exporter

等待 Prometheus 告警进行触发状态：

查看 Alertmanager UI此时可以看到 Alertmanager 接收到的告警信息

目前为止，我们已经成功安装部署了Alertmanager 并且与 Prometheus 关联，能够正常接收来自 Prometheus 的告警信息。