1. 告警概述

prometheus的告警管理分为两部分。通过在prometheus服务端设置告警规则， Prometheus服务器端产生告警向Alertmanager发送告警。 然后，Alertmanager管理这些告警，包括静默，抑制，聚合以及通过电子邮件，PagerDuty和HipChat等方法发送通知。

设置警报和通知的主要步骤如下：

• 设置并配置Alertmanager；
• 配置Prometheus对Alertmanager访问；
• 在普罗米修斯创建警报规则；

2. 告警管理模块 ALERTMANAGER

Alertmanager处理客户端应用程序（如Prometheus服务器）发送的告警。 它负责对它们进行重复数据删除，分组和路由，以及正确的接收器集成，例如电子邮件，PagerDuty或OpsGenie。 它还负责警报的静默和抑制。

以下描述了Alertmanager实现的核心概念。 请参阅配置文档以了解如何更详细地使用它们。

分组(Grouping)

分组将类似性质的告警分类为单个通知。 这在大型中断期间尤其有用，因为许多系统一次失败，并且可能同时发射数百到数千个警报。

示例：

发生网络分区时，群集中正在运行数十或数百个服务实例。 一半的服务实例无法再访问数据库。 Prometheus中的告警规则配置为在每个服务实例无法与数据库通信时发送告警。 结果，数百个告警被发送到Alertmanager。

作为用户，只能想要获得单个页面，同时仍能够确切地看到哪些服务实例受到影响。 因此，可以将Alertmanager配置为按群集和alertname对警报进行分组，以便发送单个紧凑通知。

这些通知的接收器通过配置文件中的路由树配置告警的分组，定时的进行分组通知。

抑制(Inhibition)

如果某些特定的告警已经触发，则某些告警需要被抑制。

示例：

如果某个告警触发，通知无法访问整个集群。 Alertmanager可以配置为在该特定告警触发时将与该集群有关的所有其他告警静音。 这可以防止通知数百或数千个与实际问题无关的告警触发。

静默(SILENCES)

静默是在给定时间内简单地静音告警的方法。 基于匹配器配置静默，就像路由树一样。 检查告警是否匹配或者正则表达式匹配静默。 如果匹配，则不会发送该告警的通知。

在Alertmanager的Web界面中可以配置静默。

客户端行为(Client behavior)

Alertmanager对其客户的行为有特殊要求。 这些仅适用于不使用Prometheus发送警报的高级用例。

3. 配置

Alertmanager通过命令行标志和配置文件进行配置。 命令行标志配置不可变系统参数，而配置文件定义禁止规则，通知路由和通知接收器。
要查看所有可用的命令行标志，请运行alertmanager -h。
Alertmanager可以在运行时重新加载其配置。 如果新配置格式不正确，则不会应用更改并记录错误。 通过向进程发送SIGHUP或向/ - / reload端点发送HTTP POST请求来触发配置重新加载。发送HTTP POST的方式比较常用，我们更改过配置文件之后，reload一下即可重启Alertmanager模块使新配置的规则生效。

配置文件

要指定要加载的配置文件，请使用--config.file。

./alertmanager --config.file=simple.yml

global: # The smarthost and SMTP sender used for mail notifications. smtp_smarthost: 'localhost:25' smtp_from: '' smtp_auth_username: 'alertmanager' smtp_auth_password: 'password' # The auth token for Hipchat. hipchat_auth_token: '' # Alternative host for Hipchat. hipchat_api_url: 'https://hipchat.foobar.org/' # The directory from which notification templates are read. templates: - '/etc/alertmanager/template/*.tmpl' # The root route on which each incoming alert enters. route: # The labels by which incoming alerts are grouped together. For example, # multiple alerts coming in for cluster=A and alertname=LatencyHigh would # be batched into a single group. group_by: ['alertname', 'cluster', 'service'] # When a new group of alerts is created by an incoming alert, wait at # least 'group_wait' to send the initial notification. # This way ensures that you get multiple alerts for the same group that start # firing shortly after another are batched together on the first # notification. group_wait: 30s # When the first notification was sent, wait 'group_interval' to send a batch # of new alerts that started firing for that group. group_interval: 5m # If an alert has successfully been sent, wait 'repeat_interval' to # resend them. repeat_interval: 3h # A default receiver receiver: team-X-mails # All the above attributes are inherited by all child routes and can # overwritten on each. # The child route trees. routes: # This routes performs a regular expression match on alert labels to # catch alerts that are related to a list of services. - match_re: service: ^(foo1|foo2|baz)$ receiver: team-X-mails # The service has a sub-route for critical alerts, any alerts # that do not match, i.e. severity != critical, fall-back to the # parent node and are sent to 'team-X-mails' routes: - match: severity: critical receiver: team-X-pager - match: service: files receiver: team-Y-mails routes: - match: severity: critical receiver: team-Y-pager # This route handles all alerts coming from a database service. If there's # no team to handle it, it defaults to the DB team. - match: service: database receiver: team-DB-pager # Also group alerts by affected database. group_by: [alertname, cluster, database] routes: - match: owner: team-X receiver: team-X-pager continue: true - match: owner: team-Y receiver: team-Y-pager # Inhibition rules allow to mute a set of alerts given that another alert is # firing. # We use this to mute any warning-level notifications if the same alert is # already critical. inhibit_rules: - source_match: severity: 'critical' target_match: severity: 'warning' # Apply inhibition if the alertname is the same. equal: ['alertname', 'cluster', 'service'] receivers: - name: 'team-X-mails' email_configs: - to: '' - name: 'team-X-pager' email_configs: - to: '' pagerduty_configs: - service_key: <team-X-key> - name: 'team-Y-mails' email_configs: - to: '' - name: 'team-Y-pager' pagerduty_configs: - service_key: <team-Y-key> - name: 'team-DB-pager' pagerduty_configs: - service_key: <team-DB-key> - name: 'team-X-hipchat' hipchat_configs: - auth_token: <auth_token> room_id: 85 message_format: html notify: true

全局配置

（global）指定在所有其他配置上下文中有效的参数。 它们还可用作其他配置节的默认值。

路由

路由块定义路由树中的节点及其子节点。 如果未设置，其可选配置参数将从其父节点继承。

每个告警配置的顶级路由中进入路由树，该路由必须匹配所有告警（即没有任何已配置的匹配器）。 然后它遍历子节点。 如果将continue设置为false，则在第一个匹配的子项后停止。 如果匹配节点上的continue为true，则告警将继续与后续兄弟节点匹配。 如果告警与节点的任何子节点都不匹配（没有匹配的子节点，或者不存在），则根据当前节点的配置参数处理告警。

抑制规则(inhibit_rule)

后面会详细介绍下Altermanager的抑制规则使用。

receiver

4. 发送告警

Prometheus会自动负责发送由其配置的告警规则生成的告警。 强烈建议根据时间序列数据在Prometheus中配置告警规则，而不是实现直接客户端。

Alertmanager在/ api / v1 / alerts上侦听API端点上的告警。 只要客户仍处于活动状态（通常为30秒至3分钟），客户就会不断重新发送告警。 客户端可以通过以下格式的POST请求将警报列表推送到该端点：

[ { "labels": { "<labelname>": "<labelvalue>", ... }, "annotations": { "<labelname>": "<labelvalue>", }, "startsAt": "<rfc3339>", "endsAt": "<rfc3339>", "generatorURL": "<generator_url>" }, ... ]

标签用于标识告警相同的实例并执行重复数据删除。 注释始终设置为最近收到的注释，并且不识别告警。

两个时间戳都是可选的。 如果省略startsAt，则当前时间由Alertmanager分配。 endsAt仅在已知警报结束时间时设置。 否则，它将设置为自上次收到告警以来的可配置超时时间。

generatorURL字段是唯一的反向链接，用于标识客户端中此告警的生成实体。

Alertmanager还支持/ api / alerts上的旧版端点，该端点与Prometheus版本0.16.2及更低版本兼容。