配置参数及配置文件（=> ALERTING/Configuration）
能够通过 命令行 和 配置文件 指定运行参数。命令行仅能简单配置，而配置文件能够定义继承规则、通知路由、告警接收人等等复杂设置；
visual editor，用于构建路由树；
SIGHUP，http:///-/reload，重新加载配置；
针对配置选项的内容，这里不再展开，在具体应用场景中，我们将再进一步研读；
命令行选项
使用 alertmanager -h 查看全部命令行选项；
指定配置文件：alertmanager –config.file /path/to/alertmanager.yml
增加日志等级：alertmanager –log.level=debug
配置文件结构与语法
我们这里侧重学习配置文件的结构，而不是每个属性及字段的含义。当对配置文件的结构形成整体的认识，在解决具体问题时也会非常清楚该如何解决；
关于官方文档的阅读：
1）[]，表示该参数是可选择
2）占位符（Placeholder），即每个字段的结构及取值类型，是文档的主要内容并且需要我们了解其使用方法；
配置文件采用 YAML 格式。官方提供的示例配置文件：alertmanager/simple.yml at master · prometheus/alertmanager
根据我们学习，我们整理出如下示例配置文件：
# 定义全局配置，还定义某些参数
global:
resolve_timeout: 5m
# 邮箱相关信息
smtp_smarthost: 'smtp.example.com'
smtp_auth_username: 'username'
smtp_auth_password: 'password'
smtp_from: 'k4nz@example.com'
# 在发送通知时，使用的模板文件的路径
templates:
- '/etc/alertmanager/template/*.tmpl'
# 定义消息的方式渠道及相关参数
# 注意，receivers 仅定义告警消息的接收方式，而发送规则需要通过 route 定义
receivers:
# 告警到 Slack 平台
- name: 'slack-notifications'
slack_configs:
- channel: '#alerts'
text: 'https://internal.example.com/wiki/alerts/{{ .GroupLabels.app }}/{{ .GroupLabels.alertname }}'
# 邮件告警到 OP 团队
- name: 'mail-to-op'
email_configs:
- to: 'team-op@example.org'
# 覆盖 global: 中的设置
auth_username: 'username2'
auth_password: 'password2'
# 邮件告警到 DB 团队
- name: 'mail-to-db'
email_configs:
- to: 'team-db-x@example.org'
# 邮件告警到 DB-X 团队
- name: 'mail-to-db-x'
email_configs:
- to: 'team-db-x@example.org'
# 邮件告警到 DB-Z 团队
- name: 'mail-to-db-z'
email_configs:
- to: 'team-db-z@example.org'
# 定义消息该发送给谁
route:
group_by: ['alertname', 'cluster', 'service']
# 默认接收人
receiver: slack-notifications
routes:
- receiver: slack-notifications
match_re:
service: ^(foo1|foo2|baz)$
- receiver: mail-to-op
match:
severity: critical
# 下面是更复杂的规则，将不同类型的数据库告警发送给不同组
- mactch:
service: database
receiver: mail-to-db
routes:
- match:
owner: team-op
receiver: mail-to-db-x
- match:
owner: team-db
receiver: mail-to-db-z
# 消息抑制规则
# 将具有 equal: 这些 label 的消息视为一组，如果出现 severity: 'critical' 告警，则抑制 severity: 'warning' 告警；
inhibit_rules:
- equal: ['alertname', 'cluster', 'service']
source_match:
severity: 'critical'
target_match:
severity: 'warning'
group_wait, group_interval, repeat_interval
这些参数都与时间有关，但是我们对其含义的理解十分模糊，因此整理该部分以记录这些参数的含义；
当最初的告警信息到达时，Alertmanager 根据 group_by 属性来创建消息组，将具有相同 label 的消息”合并“到相同的组中；
在创建消息组后的 group_wait 时间内，任何具有这些 label 的告警消息，都将合并到该消息组中。当到达 group_wait 时间后，这消息组累积的告警消息将被发送；
当该**消息组**的首条告警信息发送成功后，如果再有新的告警消息到达，该消息组会继续等待 group_interval 时间。当到达 group_interval 时间后，该消息组累计的告警信息将被发送；
至此，我们能够看出 group_wait、group_interval 是为了控制消息的聚合；
当告警消息发送之后，每经过 repeat_interval 时间，将重复发送前面已经发送的告警信息，直至告警问题得到解决（解决的标志是：请求包含 EndsAt 字段，或者 resolve_timeout 属性设置的时间。在 Prometheus 中，如果问题得到解决，Prometheus 将会发送 EndsAt 字段）；
但是，在实际实践中，“收到告警的时间”与“预期收到告警的时间”还是存在差异（这个时间差异是固定值，所以不像是告警媒介延迟引起的）
管理接口（=> ALERTING/Management API）
配置文件重载（reload）
向进程发送 SIGHUP 信号。或者发送 HTTP POST 到 /-/reload 地址：
# curl -XPOST http://127.0.0.1:9093/-/reload // 在 Alertmanger 中，命令行日志将输出类似如下内容： level=info ts=2021-04-27T08:35:31.553347364Z caller=main.go:322 msg="Loading configuration file" file=/etc/alertmanager/alertmanager.yml
如果配置文件格式错误，则不会应用配置，并会记录错误。但似乎没有错误原因，因此我们无法得知错误之处；
安全认证（=> ALERTING/HTTPS and authentication）
HTTPS and authentication | Prometheus
Alertmanager 提供 Basic Auth、TLS 认证；
针对认证相关的内容，这里不再展开，在具体应用场景中，我们将再进一步研读；