【Prometheus监控 运维必备】四、Prometheus 告警管理

一、Prometheus 告警管理概述

1.1 告警管理的重要性

在现代的 IT 系统中，监控是保障系统稳定运行的关键环节。然而，仅仅收集和展示监控数据是不够的，当系统出现异常或潜在问题时，需要及时通知相关人员进行处理。Prometheus 的告警管理功能就是为了解决这个问题，它能够根据预设的规则自动检测监控数据中的异常情况，并触发相应的告警通知，帮助运维人员快速响应和解决问题，减少系统故障对业务的影响。

1.2 Prometheus 告警管理的架构

Prometheus 的告警管理主要涉及两个核心组件：Prometheus Server 和 Alertmanager。

• Prometheus Server：负责收集和存储监控数据，并根据配置的告警规则对数据进行评估。当满足告警规则的条件时，Prometheus Server 会将告警信息发送给 Alertmanager。
• Alertmanager：是一个独立的组件，负责接收 Prometheus Server 发送的告警信息，并进行分组、抑制、静默等处理，最后将处理后的告警信息通过各种通知渠道（如邮件、短信、Slack 等）发送给相关人员。

二、告警规则配置

2.1 告警规则文件格式

Prometheus 的告警规则使用 YAML 格式进行配置。一个典型的告警规则文件包含多个告警规则，每个规则由 groups 部分组成，每个 group 又包含多个 rules。以下是一个简单的告警规则文件示例：

groups:
  - name: example-rules
    rules:
      - alert: HighCPUUsage
        expr: avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) < 0.2
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "High CPU usage on {{ $labels.instance }}"
          description: "The CPU usage on {{ $labels.instance }} has been above 80% for the last 5 minutes."

注释：

 

• name：规则组的名称，用于组织和管理告警规则。
• alert：告警的名称，用于标识该告警。
• expr：告警规则的表达式，使用 PromQL 编写。在这个例子中，avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) < 0.2 表示计算每个实例在过去 5 分钟内的平均空闲 CPU 时间占比，如果小于 0.2（即 CPU 使用率高于 80%），则触发告警。
• for：告警持续时间，即当满足告警规则的条件持续 5 分钟后，才会真正触发告警。这可以避免一些短暂的波动导致的误告警。
• labels：为告警添加标签，用于分类和过滤告警。severity 标签表示告警的严重程度。
• annotations：为告警添加详细的描述信息，包括摘要和详细描述。{{ $labels.instance }} 是一个模板变量，用于引用告警的实例标签。

2.2 常见的告警规则示例

2.2.1 内存使用率告警

groups:
  - name: memory-rules
    rules:
      - alert: HighMemoryUsage
        expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes > 0.9
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "High memory usage on {{ $labels.instance }}"
          description: "The memory usage on {{ $labels.instance }} has been above 90% for the last 10 minutes."

这个规则监控每个实例的内存使用率，如果内存使用率超过 90% 并持续 10 分钟，则触发告警。

2.2.2 磁盘空间不足告警

groups:
  - name: disk-rules
    rules:
      - alert: LowDiskSpace
        expr: node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} < 0.1
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "Low disk space on {{ $labels.instance }}"
          description: "The available disk space on {{ $labels.instance }} has been below 10% for the last 15 minutes."

该规则监控根目录（/）的磁盘空间使用率，如果可用磁盘空间低于 10% 并持续 15 分钟，则触发告警。

2.3 告警规则的加载和验证

在 Prometheus 中，可以通过在 prometheus.yml 配置文件中指定告警规则文件的路径来加载告警规则。例如：

rule_files:
  - "rules/*.yml"

这表示加载 rules 目录下所有以 .yml 结尾的告警规则文件。

可以使用 promtool 工具来验证告警规则文件的语法是否正确。例如：

promtool check rules rules/example-rules.yml

如果规则文件语法正确，promtool 会输出验证通过的信息；如果有错误，会显示具体的错误信息。

三、Alertmanager 配置与使用

3.1 Alertmanager 安装与启动

可以从 Prometheus 的官方网站（Download | Prometheus）下载 Alertmanager 的二进制文件，然后解压并启动。以下是在 Linux 系统上的安装和启动步骤：

# 下载 Alertmanager
wget https://github.com/prometheus/alertmanager/releases/download/v0.25.0/alertmanager-0.25.0.linux-amd64.tar.gz
# 解压文件
tar -zxvf alertmanager-0.25.0.linux-amd64.tar.gz
# 进入解压后的目录
cd alertmanager-0.25.0.linux-amd64
# 启动 Alertmanager
./alertmanager --config.file=alertmanager.yml

上述代码下载并解压 Alertmanager，然后使用 --config.file 参数指定配置文件的路径，启动 Alertmanager。默认情况下，Alertmanager 会监听 9093 端口。

3.2 Alertmanager 配置文件详解

Alertmanager 的配置文件也是使用 YAML 格式。以下是一个简单的配置文件示例：

global:
  resolve_timeout: 5m
  smtp_smarthost: 'smtp.example.com:587'
  smtp_from: 'alertmanager@example.com'
  smtp_auth_username: 'alertmanager'
  smtp_auth_password: 'password'

route:
  group_by: ['alertname', 'cluster', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'email'

receivers:
  - name: 'email'
    email_configs:
      - to: 'admin@example.com'

注释：

 

• global：全局配置部分，定义了一些通用的参数。
  • resolve_timeout：告警解决的超时时间，即当告警不再满足触发条件后，经过 5 分钟才会标记为已解决。
  • smtp_smarthost：SMTP 服务器的地址和端口。
  • smtp_from：发送邮件的邮箱地址。
  • smtp_auth_username 和 smtp_auth_password：SMTP 认证的用户名和密码。
• route：路由配置部分，定义了告警信息的处理规则。
  • group_by：指定告警分组的标签，将具有相同标签的告警分组在一起。
  • group_wait：分组等待时间，即当接收到第一个告警后，等待 30 秒再发送通知，以便将同一组的告警合并。
  • group_interval：分组间隔时间，即两次发送同一组告警通知的最小间隔时间为 5 分钟。
  • repeat_interval：重复通知间隔时间，即当告警持续存在时，每隔 4 小时重复发送通知。
  • receiver：指定默认的接收者，这里是 email。
• receivers：接收者配置部分，定义了不同的接收者及其通知方式。这里定义了一个名为 email 的接收者，使用邮件通知，收件人是 admin@example.com。

3.3 Alertmanager 的高级功能

3.3.1 分组与抑制

分组功能可以将相关的告警合并为一个通知，减少通知的数量。例如，当多个服务器同时出现 CPU 使用率过高的告警时，可以将这些告警分组为一个通知发送给运维人员。抑制功能可以根据规则抑制某些告警的通知。例如，当一个服务器的主电源故障告警触发时，可以抑制该服务器的其他次要告警，避免过多的干扰信息。

3.3.2 静默管理

静默管理允许用户在特定的时间段内暂停接收某些告警通知。例如，在进行系统维护时，可以设置静默规则，暂停接收与维护服务器相关的告警通知，避免在维护期间收到不必要的告警。

3.3.3 告警模板

Alertmanager 支持使用模板来定制告警通知的内容和格式。可以使用 Go 模板语言编写模板文件，然后在配置文件中引用这些模板。例如：

templates:
  - 'templates/*.tmpl'

receivers:
  - name: 'email'
    email_configs:
      - to: 'admin@example.com'
        html: '{{ template "email.html.tmpl" . }}'

上述配置中，templates 指定了模板文件的路径，html 指定了使用 email.html.tmpl 模板来生成邮件的 HTML 内容。

四、告警通知渠道配置

4.1 邮件通知

邮件是最常用的告警通知渠道之一。在 Alertmanager 配置文件中，可以配置邮件通知的相关参数，如 SMTP 服务器地址、发件人、收件人等。以下是一个完整的邮件通知配置示例：

global:
  resolve_timeout: 5m
  smtp_smarthost: 'smtp.example.com:587'
  smtp_from: 'alertmanager@example.com'
  smtp_auth_username: 'alertmanager'
  smtp_auth_password: 'password'

route:
  group_by: ['alertname', 'cluster', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'email'

receivers:
  - name: 'email'
    email_configs:
      - to: 'admin@example.com'
        subject: '[{{ .Status | toUpper }}{{ if eq .Status "firing" }}:{{ .Alerts.Firing | len }}{{ end }}] {{ .GroupLabels.SortedPairs.Values | join " " }}'
        html: |
          <html>
            <body>
              <h2>{{ if eq .Status "firing" }}Firing{{ else }}Resolved{{ end }} Alerts</h2>
              <ul>
                {{ range .Alerts }}
                  <li>
                    <p><strong>Alertname:</strong> {{ .Labels.alertname }}</p>
                    <p><strong>Instance:</strong> {{ .Labels.instance }}</p>
                    <p><strong>Severity:</strong> {{ .Labels.severity }}</p>
                    <p><strong>Summary:</strong> {{ .Annotations.summary }}</p>
                    <p><strong>Description:</strong> {{ .Annotations.description }}</p>
                  </li>
                {{ end }}
              </ul>
            </body>
          </html>

这个配置示例中，详细配置了邮件通知的相关参数，包括 SMTP 服务器信息、发件人、收件人、邮件主题和 HTML 内容。邮件主题和 HTML 内容使用了 Go 模板语言，动态显示告警的状态、数量和详细信息。

4.2 Slack 通知

要使用 Slack 作为告警通知渠道，需要在 Slack 中创建一个 Webhook URL，并在 Alertmanager 配置文件中进行配置。以下是一个 Slack 通知的配置示例：

receivers:
  - name: 'slack'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/XXXXXX/XXXXXX/XXXXXX'
        channel: '#alerts'
        text: |
          {{ if eq .Status "firing" }}:fire:{{ else }}:white_check_mark:{{ end }}
          **{{ .GroupLabels.SortedPairs.Values | join " " }}**
          {{ range .Alerts }}
            - {{ .Labels.alertname }} on {{ .Labels.instance }} ({{ .Labels.severity }})
              - Summary: {{ .Annotations.summary }}
              - Description: {{ .Annotations.description }}
          {{ end }}

api_url 是 Slack 的 Webhook URL，channel 指定了告警通知要发送到的 Slack 频道，text 使用 Go 模板语言定义了通知的文本内容。

4.3 其他通知渠道

除了邮件和 Slack，Alertmanager 还支持其他多种通知渠道，如 PagerDuty、Telegram、微信等。每种通知渠道的配置方式略有不同，但基本原理都是通过调用相应的 API 或 Webhook 来发送告警通知。

五、告警管理的最佳实践

5.1 合理设置告警规则

• 避免过度告警：设置合理的阈值和持续时间，避免因短暂的波动或正常的业务高峰触发过多的告警。
• 分层告警：根据告警的严重程度和影响范围，将告警分为不同的层级，如 critical、warning、info 等，方便运维人员快速判断和处理。
• 关联告警：将相关的告警进行关联，当一个告警触发时，同时检查是否有其他相关的告警，以便更全面地了解问题的本质。

5.2 定期维护和优化告警配置

• 清理无用规则：定期检查告警规则，删除不再使用或无效的规则，减少系统的负担。
• 优化规则表达式：随着系统的变化和业务的发展，可能需要对告警规则的表达式进行优化，以提高告警的准确性。
• 调整通知策略：根据实际情况调整告警通知的分组、抑制和重复通知间隔等策略，避免过多的重复通知。

5.3 与团队协作和沟通

• 明确责任分工：明确不同告警的处理责任人，确保在告警触发时能够及时响应。
• 共享告警信息：将告警信息及时共享给相关的团队成员，促进团队之间的协作和沟通。
• 总结经验教训：在处理完告警后，及时总结经验教训，不断完善告警管理策略。

Prometheus 的告警管理功能为 IT 系统的稳定运行提供了有力的保障。通过合理配置告警规则、使用 Alertmanager 进行告警处理和通知，以及选择合适的通知渠道，可以及时发现和解决系统中的问题。