Alertmanager 使用指南：配置、集成与通知定制

1. amtool 子命令操作

amtool 提供了多个实用的子命令，用于管理和配置 Alertmanager。

1.1 silence 子命令

silence 子命令用于管理静默规则，常见操作步骤如下：
- 查询可用的静默规则 ：

vagrant@alertmanager02:~$ amtool silence --alertmanager.url http://alertmanager02:9093

该命令默认执行查询操作，等价于 amtool silence query --alertmanager.url http://alertmanager02:9093 。
- 创建新的静默规则 ：

vagrant@alertmanager02:~$ amtool silence add 'example="amtool"' --comment "ups" --alertmanager.url http://alertmanager02:9093

创建后再次查询，可看到新添加的静默规则。
- 验证静默规则生效 ：

vagrant@alertmanager02:~$ amtool alert --alertmanager.url http://alertmanager02:9093

若静默规则生效，相关警报将从当前警报列表中消失。
- 移除静默规则 ：

vagrant@alertmanager02:~$ amtool silence expire 1afa55af-306a-408e-b85c-95b1af0d7169 --alertmanager.url http://alertmanager02:9093

移除后再次查询当前警报列表，相关警报将再次出现。

1.2 check-config 子命令

该子命令用于验证 Alertmanager 配置文件和引用的模板文件的语法和架构，操作步骤如下：

vagrant@alertmanager02:~$ amtool check-config /etc/alertmanager/alertmanager.yml 

此验证操作易于自动化，应在任何配置更改后、重新加载 Alertmanager 实例之前进行，以防止大多数配置问题。

1.3 config 子命令

config 子命令可用于查看运行中的 Alertmanager 实例的内部配置，包括所有可配置字段，即使是配置文件中未明确列出的字段。
- 查看内部配置 ：

vagrant@alertmanager02:~$ amtool config --alertmanager.url http://alertmanager02:9093

该命令默认执行显示操作，等价于 amtool config show --alertmanager.url http://alertmanager02:9093 。
- 生成路由树可视化 ：

vagrant@alertmanager02:~$ amtool config routes --alertmanager.url http://alertmanager02:9093

此命令可针对运行中的 Alertmanager 实例或本地配置文件运行。
- 验证路由树 ：

vagrant@alertmanager02:~$ amtool config routes test 'job="checkoutService"' --config.file /etc/alertmanager/alertmanager.yml 

通过提供标签来验证触发的接收器。

2. Kubernetes 环境下的 Alertmanager 配置

在 Kubernetes 环境中使用 Alertmanager，可按以下步骤进行配置：

2.1 准备 Kubernetes 测试环境

graph LR
    A[验证无其他 Kubernetes 环境运行] --> B[启动空的 Kubernetes 环境]
    B --> C[添加 Prometheus Operator 组件并跟进部署]
    C --> D[添加新的 Prometheus 集群并确保成功]
    D --> E[添加所有目标到 Prometheus 并列出]

具体操作步骤如下：
1. 验证无其他 Kubernetes 环境运行：

minikube status
minikube delete

2. 启动空的 Kubernetes 环境：

minikube start \
  --cpus=2 \
  --memory=3072 \
  --kubernetes-version="v1.14.0" \
  --vm-driver=virtualbox

3. 添加 Prometheus Operator 组件并跟进部署：

kubectl apply -f ./bootstrap/
kubectl rollout status deployment/prometheus-operator -n monitoring

4. 添加新的 Prometheus 集群并确保成功：

kubectl apply -f ./prometheus/
kubectl rollout status statefulset/prometheus-k8s -n monitoring

5. 添加所有目标到 Prometheus 并列出：

kubectl apply -f ./services/
kubectl get servicemonitors --all-namespaces

2.2 Alertmanager 特定配置

• 创建 ServiceAccount：

kubectl apply -f ./alertmanager/alertmanager-serviceaccount.yaml

• 部署 Alertmanager 配置：

kubectl apply -f ./alertmanager/alertmanager-configuration.yaml

最小配置示例如下：

global:
route:
  receiver: "null"
  group_by:
    - job
  group_interval: 3m
  repeat_interval: 3h
  routes:
    - match:
        alertname: deadmanswitch
      receiver: "null"
receivers:
  - name: "null"

• 部署 Alertmanager 集群：

kubectl apply -f ./alertmanager/alertmanager-deploy.yaml

跟进部署状态：

kubectl rollout status statefulset/alertmanager-k8s -n monitoring

• 添加 Service 和 ServiceMonitor：

kubectl apply -f ./alertmanager/alertmanager-service.yaml
kubectl apply -f ./alertmanager/alertmanager-servicemonitor.yaml

• 添加警报规则：

kubectl apply -f ./alertmanager/alerting-rules.yaml

示例规则如下：

kind: PrometheusRule
spec:
  groups:
  - name: exporter-down
    rules:
    - alert: AlertmanagerDown
      annotations:
        description: Alertmanager is not being scraped.
        troubleshooting: https://github.com/kubernetes-monitoring/kubernetes-mixin/blob/master/runbook.md
      expr: |
        absent(up{job="alertmanager-service",namespace="monitoring"} == 1)
      for: 5m
      labels:
        severity: page

• 访问 Web 界面验证配置：

minikube service alertmanager-service -n monitoring
minikube service prometheus-service -n monitoring

• 测试完成后删除环境：

minikube delete

3. 常见 Alertmanager 通知集成

Alertmanager 提供了多种通知集成选项，以满足不同用户和组织的需求。

3.1 通用配置注意事项

所有通知器都有一个通用的配置键 send_resolved ，它接受布尔值（true 或 false），用于声明警报解决时是否发送通知。

集成类型	send_resolved 默认值
PagerDuty、Opsgenie、VictorOps、Pushover、Webhook	true
其他通知器	false

3.2 电子邮件集成

使用 Google Gmail 的 SMTP 进行配置示例：

global:
  smtp_smarthost: 'smtp.gmail.com:587'
  smtp_from: 'alertmanager@example.com'
  smtp_auth_username: 'alertmanager@example.com'
  smtp_auth_identity: 'alertmanager@example.com'
  smtp_auth_password: '<generated_token>'
route: 
  receiver: 'default'
receivers:
- name: 'default'
  email_configs:
  - to: 'squad@example.com'

需启用两步验证并生成应用密码用于 smtp_auth_password 字段。

3.3 聊天集成

以 Slack 集成为例：

global:
  slack_api_url: 'https://hooks.slack.com/services/TOKEN'
route:
  receiver: 'default'
receivers:
- name: 'default'
  slack_configs:
  - channel: '#alerting'

slack_api_url 应指向 Slack 传入 Webhook URL。

3.4 寻呼机集成

以 PagerDuty 集成为例：

global:
  pagerduty_url: 'https://events.pagerduty.com/v2/enqueue'
route:
  receiver: 'default'
receivers:
- name: 'default'
  pagerduty_configs:
  - service_key: 'PAGERDUTYSQUADTOKENEXAMPLE'

3.5 Webhook 集成

global:
route:
  receiver: 'default'
receivers:
- name: 'default'
  webhook_configs:
  - url: 'http://127.0.0.1:5001'

此配置将 Alertmanager 收到的每个警报原样发送到指定的 Webhook 端点。

3.6 null 集成

用于丢弃通知：

global:
route:
  receiver: 'null'
receivers:
- name: 'null'

4. 自定义警报通知

Alertmanager 为每个可用的集成提供了内置的通知模板，但可根据用户和组织的特定需求进行定制。以 Slack 集成为例，了解默认消息格式的生成方式。

4.1 默认消息格式示例

警报规则示例：

- alert: deadmanswitch
  expr: vector(42)

警报负载示例：

{
    "labels": {
        "alertname": "deadmanswitch",
        "dc": "dc1"
    },
    "annotations": {},
    "startsAt": "2019-04-02T19:11:30.04754979Z",
    "endsAt": "2019-04-02T19:14:30.04754979Z",
    "generatorURL": "http://prometheus:9090/graph?g0.expr=vector%2842%29&g0.tab=1"
}

Alertmanager 配置示例：

global:
  slack_api_url: 'https://hooks.slack.com/services/TOKEN'
route:
  receiver: 'default'
receivers:
- name: 'default'
  slack_configs:
  - channel: '#alerting'

运行时配置示例：

receivers:
- name: default
  slack_configs:
  - send_resolved: false
    http_config: {}
    api_url: <secret>
    channel: '#alerting'
    username: '{{ template "slack.default.username" . }}'
    color: '{{ if eq .Status "firing" }}danger{{ else }}good{{ end }}'
    title: '{{ template "slack.default.title" . }}'
    title_link: '{{ template "slack.default.titlelink" . }}'
    pretext: '{{ template "slack.default.pretext" . }}'
    text: '{{ template "slack.default.text" . }}'

通过查看 templates/default.tmpl 文件（当前版本链接：https://github.com/prometheus/alertmanager/blob/v0.16.2/template/default.tmpl），可了解默认模板的定义。例如， slack.default.username 模板定义如下：

{{ define "slack.default.username" }}{{ template "__alertmanager" . }}{{ end }}

__alertmanager 模板定义如下：

{{ define "__alertmanager" }}AlertManager{{ end }}

这解释了 Slack 通知中 AlertManager 名称的由来。后续可学习如何创建自己的模板来定制警报通知。

Alertmanager 使用指南：配置、集成与通知定制

5. 深入定制警报通知模板

5.1 模板定制基础

Alertmanager 使用 Go 模板语言进行通知模板的定制。要定制模板，首先需要了解模板文件的结构和语法。模板文件通常包含多个模板定义，每个定义使用 {{ define "template_name" }} 开头，以 {{ end }} 结尾。

例如，我们可以创建一个自定义的 Slack 用户名模板：

{{ define "slack.custom.username" }}MyCustomAlertManager{{ end }}

然后在 Alertmanager 配置中引用这个模板：

receivers:
- name: default
  slack_configs:
  - username: '{{ template "slack.custom.username" . }}'

5.2 模板变量和函数

在模板中，可以使用变量和函数来动态生成内容。常见的变量包括警报的标签、注释、开始时间、结束时间等。例如，我们可以在 Slack 通知的标题中显示警报的名称：

{{ define "slack.custom.title" }}{{ .Labels.alertname }}{{ end }}

同时，Go 模板语言还提供了许多内置函数，如字符串处理、日期格式化等。例如，格式化警报的开始时间：

{{ define "slack.custom.text" }}Alert started at {{ .StartsAt.Format "2006-01-02 15:04:05" }}{{ end }}

5.3 模板的嵌套使用

模板可以嵌套使用，以实现更复杂的逻辑。例如，我们可以定义一个通用的警报标题模板，然后在其他模板中引用它：

{{ define "alert.title" }}{{ .Labels.alertname }}{{ end }}
{{ define "slack.custom.title" }}{{ template "alert.title" . }}{{ end }}

6. 高级 Alertmanager 配置技巧

6.1 抑制规则配置

抑制规则用于在某些条件下抑制警报的通知。例如，当一个高优先级的警报触发时，抑制低优先级的相关警报。配置示例如下：

inhibit_rules:
- source_match:
    severity: 'critical'
  target_match:
    severity: 'warning'
  equal: ['alertname', 'job']

上述配置表示，当 severity 为 critical 的警报触发时，抑制 severity 为 warning 且 alertname 和 job 相同的警报。

6.2 分组规则优化

分组规则用于将相关的警报分组，以便更清晰地展示和处理。可以根据标签进行分组，例如按 job 和 instance 分组：

route:
  group_by: ['job', 'instance']
  group_interval: 5m
  repeat_interval: 3h

group_interval 表示分组的时间间隔， repeat_interval 表示重复通知的时间间隔。

6.3 路由规则的动态调整

路由规则决定了警报如何被路由到不同的接收器。可以根据警报的标签动态调整路由规则。例如，根据 severity 标签将警报路由到不同的接收器：

route:
  receiver: 'default'
  routes:
  - match:
      severity: 'critical'
    receiver: 'critical-receiver'
  - match:
      severity: 'warning'
    receiver: 'warning-receiver'

7. Alertmanager 监控与故障排查

7.1 监控指标

Alertmanager 提供了一系列监控指标，可用于监控其运行状态。重要的指标包括：
| 指标名称 | 描述 |
| ---- | ---- |
| alertmanager_notifications_failed_total | 记录每个集成的通知失败次数 |
| alertmanager_alerts | 记录当前的警报数量 |
| alertmanager_silences | 记录当前的静默规则数量 |

可以使用 Prometheus 来收集和监控这些指标，并设置相应的警报规则。

7.2 故障排查步骤

当 Alertmanager 出现问题时，可以按照以下步骤进行排查：

graph LR
    A[检查配置文件] --> B[验证语法和架构]
    B --> C{是否通过验证}
    C -- 是 --> D[检查监控指标]
    C -- 否 --> E[修复配置文件错误]
    D --> F{是否有异常指标}
    F -- 是 --> G[分析异常指标原因]
    F -- 否 --> H[检查通知集成配置]
    G --> I[解决问题]
    H --> J{是否配置正确}
    J -- 是 --> K[检查网络连接]
    J -- 否 --> L[修复集成配置错误]
    K --> M{是否连接正常}
    M -- 是 --> N[检查 Alertmanager 日志]
    M -- 否 --> O[解决网络问题]
    N --> P[分析日志找出问题]
    P --> I

具体步骤如下：
1. 检查配置文件：确保配置文件的语法和架构正确。

amtool check-config /etc/alertmanager/alertmanager.yml 

2. 检查监控指标：查看是否有异常的指标，如通知失败次数过多。
3. 检查通知集成配置：确保每个集成的配置正确，如 API 密钥、URL 等。
4. 检查网络连接：确保 Alertmanager 可以正常访问通知集成的服务。
5. 检查 Alertmanager 日志：查看日志文件，找出可能的错误信息。

8. Alertmanager 与其他系统的集成扩展

8.1 与 Grafana 集成

Grafana 是一个流行的可视化工具，可以与 Alertmanager 集成，实现警报的可视化和管理。集成步骤如下：
1. 在 Grafana 中添加 Alertmanager 数据源。
2. 创建仪表板，展示 Alertmanager 的监控指标。
3. 设置 Grafana 的警报规则，与 Alertmanager 协同工作。

8.2 与 CI/CD 流程集成

将 Alertmanager 集成到 CI/CD 流程中，可以在部署过程中及时发现和处理问题。例如，在部署前验证 Alertmanager 配置文件的正确性：

amtool check-config /etc/alertmanager/alertmanager.yml 

在部署后检查 Alertmanager 的运行状态，确保服务正常。

8.3 与自动化运维工具集成

可以将 Alertmanager 与自动化运维工具（如 Ansible、SaltStack 等）集成，实现自动化的故障处理。例如，当警报触发时，自动执行脚本进行故障修复。

9. 总结与最佳实践

9.1 总结

通过本文，我们学习了 Alertmanager 的基本配置、常见通知集成、警报通知模板的定制以及高级配置技巧和故障排查方法。掌握这些知识，可以更好地使用 Alertmanager 来管理和处理警报。

9.2 最佳实践

• 定期验证配置文件：使用 amtool check-config 命令定期验证 Alertmanager 配置文件的正确性，避免配置错误导致的问题。
• 合理配置分组和路由规则：根据实际需求合理配置分组和路由规则，确保警报能够准确地被分组和路由到相应的接收器。
• 定制通知模板：根据组织的需求定制通知模板，突出重要信息，提高警报通知的可读性和实用性。
• 监控和故障排查：定期监控 Alertmanager 的运行状态，及时发现和处理问题，确保服务的稳定性。

通过遵循这些最佳实践，可以提高 Alertmanager 的使用效率和可靠性，更好地应对各种警报场景。