Alertmanager- 服务管理、服务维护

配置参数及配置文件（=> ALERTING/Configuration）

Configuration | Prometheus

能够通过命令行和配置文件指定运行参数。命令行仅能简单配置，而配置文件能够定义继承规则、通知路由、告警接收人等等复杂设置；

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）

Management API | Prometheus

配置文件重载（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 认证；

针对认证相关的内容，这里不再展开，在具体应用场景中，我们将再进一步研读；