Prometheus-alertmanager组件使用

警报管理

Alertmanager工作过程

? Alertmanager处理从客户端（通常是Prometheus服务器或其它工具的警报）发来的警报，然后Alertmanager对警报进行去重、分组，然后路由到不同的接收器，如电子邮件、短信或SaaS服务（PagerDuty等）。还可以使用Alertmanager管理维护警报。

• 先在Prometheus服务器上编写警报规则，这些规则将使用（exporter）收集的指标并在指定的阈值或标准上触发警报。当指标达到阈值或标准时，生成一个警报并将其推送到alertmanger。告警在Alertmanger上的HTTP端点上接收。
• 收到警报后，alertmanager会处理警报并根据其标签进行路由。一旦路径确定，他们将由Alertmanager发送到外部目的地。如电子邮件、短信等工具。

alertmanager安装配置

详见文档

配置alertmanager

Alertmanager配置也是基于YAML的配置文件，主要由global,route,receivers这三部分组成。

简单样例(alertmanager.yml)

通过电子邮件发送任何收到的警报到另一个邮箱地址。

global:
  smtp_from: ‘localhost:25‘
  smtp_smarthost: ‘alertmanager@example.com‘
  smtp_require_tls: false

route:
  receiver: ‘email‘

receivers:
-name: ‘email‘
  email_configs:
  - to: ‘alerts@example.com‘

templates:
- ‘/ups/app/monitor/alertmanager/template/*.tmpl‘

• global: 全局配置，为其它块设置默认值
• template: 包含保存警报模板的目录列表。由于alertmanager可以发送到各种目的地，因此需要能够自定义警报的外观及其包含的数据
• route: 它告知alertmanager如何处理特定的传入警报。警报根据规则进行匹配然后采取相应的操作。
• receivers（接收器）：指定警报的目的地。每个接收器都有一个名称和相关配置

在Prometheus中配置alertmanager

在Prometheus中配置，告诉Prometheus关于Alertmanager的信息。在alerting块中配置alertmanger相关信息。

# Alertmanager configuration
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      - progs:9093  # 对应启动的altermanager节点的9093端口

? alerting块包含允许Prometheus识别一个或多个Alertmanager的配置。为此，Prometheus使用与查找抓取目标时相同的发现机制，在默认配置中是static_configs。与监控作业一样，它指定目标列表，此处是主机名progs加端口9093（Alertmanager默认端口）的形式。该列表假定你的Prometheus服务器可以解析progs主机名为IP地址，并且Alertmanager在该主机的端口9093上运行。

监控alertmanager

Alertmanager可以暴露了自身的相关指标作为被监控对象。创建一个作业来监控alertmanager

  - job_name: ‘alertmanager‘
    static_configs:
    - targets: [‘localhost:9093‘]

? 这将从http://localhost:9093/metrics收集指标并抓取一系列以alertmanager_为前缀的时间序列数据。这些数据包括按状态分类的警报计数、按接收器分类的成功和失败通知的计数、还可以包含Alertmanager集群状态指标。

添加警报规则

与记录规则一样，警报规则也是在Prometheus服务器中配置加载的规则文件（使用YAML语句定义）。现在rules目录中创建一个新文件node_alerts.yml，以保存节点警报规则为例子进行说明。

在prometheus.yml配置文件中的rule_files块配置加载的规则文件

# Load rules once and periodically evaluate them according to the global ‘evaluation_interval‘.
rule_files:
  - "rules/*_rules.yml"
  - "rules/*_alerts.yml"

当前使用通配符加载该目录中以_rules.yml或_alerts.yml结尾的所有文件。

添加警报规则

vi rules/node_alerts.yml

groups:
- name: node_alerts
  rules:
  - alert: InstanceDown
    expr: up{job="node_exporter"} == 0
    for: 10s
    labels:
      severity: critical
    annotations:
      summary: Host {{ $labels.instance }} is down!

• 上面指定一个组名为node_alerts的警报规则，该组中的规则包含在rules的块中。

• 每个规则通过alert子句指定它的名称，并且每个警报组中的警报名称必须唯一。

• 触发警报表达式使用expr子句指定。

• for子句控制在触发警报之前必须为true的时间长度。在这个示例中，指标up{job="node_exporter"}需要在触发警报之前的10秒中内等于0.这限制了警报误报或暂时状态的可能。

• 使用标签（labels）装饰警报，指定要附加到警报的其它标签，这里添加了一个值为critical的severity的标签。警报上的标签与警报的名称组合构成警报的标识

• 注解（annotations）装饰警报，用于展现更多的信息的标签，如描述、处理说明等。这里添加一个名为summary的标签来描述警报

重启Prometheus服务启用新的警报规则

打开web界面查看http://progs:9090/alerts

警报触发

Prometheus以固定时间间隔（由参数evaluation_interval控制）评估所有的规则。默认值1分钟。在每个评估周期内，Prometheus运行每个警报规则中定义的表达式并更新警报状态。

警报状态

• Inactive：警报未激活
• Pending：警报已满足测试表达式条件，但仍在等待for子句指定的持续时间
• Firing：警报已满足测试表达式条件，并且Pending的时间已超过for子句的持续时间

Pending到Firing的转换可以确保警报更有效，且不会来回浮动。没有for子句的警报会自动从Inactive转换为Firing，只需要一个评估周期（evaluation_interval）即可触发。带有for子句的警报将首先转换为Pending，然后转换为Firing，因此至少需要两个评估周期才能触发。

警报的生命周期

• 节点的可能不断变化，每隔一段由scrape_interval定义的时间被Prometheus抓取一次，对我们来说是15秒。
• 根据每个evaluation_interval的指标来评估警报规则，对我们来说还是15秒。
• 当警报表达式为true时（对于上面示例来说节点发生down），会创建一个警报并转换到Pending状态，执行for子句。
• 在下一个评估周期中，如果警报测试表达式仍然为true，则检查for的持续时间。如果超过了持续时间，则警报将转换为Firing，生成通知并将其推送到Alertmanager。
• 如果警报测试表达式不再为true，则Prometheus会将警报规则的状态从Pending更改为Inactive。

alertmanager的警报

通过http://progs:9090/alerts Web界面查看警报及其状态

处于Firing状态的警报已经推送到alertmanager，可以在alertmanager API(http://progs:9093/api/v1/alerts)查看

[root@progs config]# curl http://progs:9093/api/v1/alerts| python -m json.tool
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1004  100  1004    0     0   172k      0 --:--:-- --:--:-- --:--:--  196k
{
    "data": [
        {
            "annotations": {
                "summary": "Host 192.168.10.181:9100 is down!"
            },
            "endsAt": "2020-08-08T02:37:48.046283806Z",
            "fingerprint": "2c28fee95b3f434c",
            "generatorURL": "http://progs:9090/graph?g0.expr=up%7Bjob%3D%22node_exporter%22%7D+%3D%3D+0&g0.tab=1",
            "labels": {
                "alertname": "InstanceDown",
                "hostname": "192.168.10.181",
                "instance": "192.168.10.181:9100",
                "job": "node_exporter",
                "severity": "critical"
            },
            "receivers": [
                "wechat"
            ],
            "startsAt": "2020-08-08T02:28:48.046283806Z",
            "status": {
                "inhibitedBy": [],
                "silencedBy": [],
                "state": "active"
            }
        },
        {
            "annotations": {
                "summary": "Host  is down!"
            },
            "endsAt": "2020-08-08T02:37:48.046283806Z",
            "fingerprint": "550e18fea3ef4d3d",
            "generatorURL": "http://progs:9090/graph?g0.expr=avg+by%28job%29+%28up%7Bjob%3D%22node_exporter%22%7D%29+%3C+0.75&g0.tab=1",
            "labels": {
                "alertname": "InstancesDown",
                "job": "node_exporter",
                "severity": "critical"
            },
            "receivers": [
                "wechat"
            ],
            "startsAt": "2020-08-08T02:28:48.046283806Z",
            "status": {
                "inhibitedBy": [],
                "silencedBy": [],
                "state": "active"
            }
        }
    ],
    "status": "success"
}
[root@progs config]# 

Prometheus为Pending和Firing状态中的每个警报创建指标（ALERT），如下：

添加模板

模板（template）是一种在警报中使用时间序列数据的标签和值的方法，可用于注解和标签。模板使用标准的Go模板语法，并暴露一些包含时间序列的标签和值的变量。标签以变量$labels形式表示，指标的值则是变量$value。

引用时间序列的值

• summary注解中引用instance标签，使用{{$labels.instance}}
• 引用时间序列的值，使用{{$value}}
• 使用humanize函数，它使用指标前缀将数字转换为更易于阅读的形式

路由

将不同属性的警报路由到不同的目的地。默认使用后序遍历路由

下面在alertmanager.yml文件中添加一些路由配置

global:
  smtp_from: ‘localhost:25‘
  smtp_smarthost: ‘alertmanager@example.com‘
  smtp_require_tls: false

route:
  group_by: [‘instance‘]
  group_wait: 30s
  
  group_interval: 5m
  repeat_interval: 3h
  receiver: ‘email‘
  routes:
  - match:
      severity: critical
    receiver: pager
  - match_re:
      severity: ^(warning|critical)$
    receiver: support_team

receivers:
- name: ‘email‘
  email_configs:
  - to: ‘alerts@example.com‘
- name: ‘support_team‘
  email_configs:
  - to: ‘support@example.com‘
- name: ‘pager‘
  email_configs:
  - to: ‘pager@example.com‘

templates:
- ‘/ups/app/monitor/alertmanager/template/*.tmpl‘

• group_by: 控制Alertmanager分组警报的方式。默认所有警报分成一组
  • 示例指定标签instance对警报分组，意味着来自特定实例的所有警报分在一起
  • 分组会改变alertmanager的处理行为，当触发新警报时，等待group_wait中指定时间段，以便在触发警报之前是否收到改组的其它警报
• group_interval：在发出警报后，如果收到该分组的下一次评估新警报，alertmanager等待group_interval指定的时间段，再发送新警报。防止警报分组的警报泛滥
• repeat_interval：仅作用于单个警报，等待重新发送相同警报的时间段。不适用警报组

路由表

routes子句列出分支路由。通过标签匹配或正则表达式匹配将警报发送到指定的目的地。路由都是分支，可以继续设置分支路由。

标签匹配

  - match:
      severity: critical
    receiver: pager

将所有severity标签与critical值匹配，并将它们发送到pager接收器。

路由分支

新routes块嵌套已有的routes块中。

  routes:
  - match:
      severity: critical
    receiver: pager
    routes:
      - match:
        service: application
      receiver: support_team

当新警报severity标签为critical且service标签application都成功匹配时，将警报发送到接收器support_team。

正则表达式匹配

  - match_re:
      severity: ^(warning|critical)$
    receiver: support_team

它匹配severity标签中的warning或critical值。

路由遍历顺序

默认使用后序遍历路由，可以使用continue选项控制路由遍历顺序，该选项控制警报是否先序遍历路由，然后再返回已遍历路由树。continue默认选项为false，即后序遍历路由树。

延申知识点

• 前序遍历（先序）：前序遍历可以记为根左右，若二叉树为空，则结束返回。
• 后序遍历：后序遍历可以记为左右根，也就是说在二叉树的遍历过程中，首先按照后序遍历的规则遍历左子树，接着按照后序遍历的规则遍历右子树，最后访问根节点。若二叉树为空，则结束返回。

  routes:
  - match:
      severity: critical
    receiver: pager
    continue: true

continue: true时，则警报将在此路由中触发（如果匹配），并继续执行下一个相邻路由。

接收器

指定接收警报的目的地。

receivers:
- name: ‘pager‘
  email_configs:
  - to: ‘pager@example.com‘
  slack_configs:
  - api_url: https://hooks.slack.com/service/ABC123/ABC123/EXAMPLE
    channel: ‘#monitoring‘

添加Slack接收器，它会消息发送到Slack实例。示例中任何向pager接收器发送警报的路由都将被发送到Slack的#monitoring频道，并通过电子邮件发送到pager@example.com。

通知模板

使用Go template函数来引用外部模板，从而避免在配置文件中嵌入较长且复杂的字符串。

创建模板文件

cat > /ups/app/monitor/alertmanager/template/slack.tmpl <<-EOF
{{ define "slack.example.text" }}{{ .CommonAnnotations.summary }}{{ end}}
EOF

使用define函数定义了一个新模板，以end结尾，并取名为slack.example.text，然后在模板内的text中复制内容。

引用模板

  slack_configs:
  - api_url: https://hooks.slack.com/service/ABC123/ABC123/EXAMPLE
    channel: ‘#monitoring‘
    text: ‘{{ template "slack.example.text" . }}‘

使用了template选项来指定模板的名称。使用模板通知来填充text字段。

silence和维护

silence: 警报静音。当明确知道停止服务以进行维护作业时，并不希望触发警报。这种场景需要用到silence，设定特定时间段内屏蔽触发警报规则。

设置silence的方法

• alertmanager Web控制台
• amtool命令行工具

silence配置过程

alertmanager Web控制台设置silence

新建silence

配置相关属性

amtool工具设置silence

用法

usage: amtool [<flags>] <command> [<args> ...]

View and modify the current Alertmanager state.

Config File: The alertmanager tool will read a config file in YAML format from one of two default config locations:
$HOME/.config/amtool/config.yml or /etc/amtool/config.yml

All flags can be given in the config file, but the following are the suited for static configuration:

  alertmanager.url
  	Set a default alertmanager url for each request

  author
  	Set a default author value for new silences. If this argument is not
  	specified then the username will be used

  require-comment
  	Bool, whether to require a comment on silence creation. Defaults to true

  output
  	Set a default output type. Options are (simple, extended, json)

  date.format
  	Sets the output format for dates. Defaults to "2006-01-02 15:04:05 MST"

Flags:
  -h, --help           Show context-sensitive help (also try --help-long and --help-man).
      --date.format="2006-01-02 15:04:05 MST"  
                       Format of date output
  -v, --verbose        Verbose running information
      --alertmanager.url=ALERTMANAGER.URL  
                       Alertmanager to talk to
  -o, --output=simple  Output formatter (simple, extended, json)
      --timeout=30s    Timeout for the executed command
      --version        Show application version.

Commands:
  help [<command>...]
  alert
    query* [<flags>] [<matcher-groups>...]
    add [<flags>] [<labels>...]
  silence
    add [<flags>] [<matcher-groups>...]
    expire [<silence-ids>...]
    import [<flags>] [<input-file>]
    query* [<flags>] [<matcher-groups>...]
    update [<flags>] [<update-ids>...]
  check-config [<check-files>...]
  cluster
    show*
  config
    show*
    routes [<flags>]
      show*
      test [<flags>] [<labels>...]

amtool配置文件

默认配置文件路径``$HOME/.config/amtool/config.ymlor/etc/amtool/config.yml`

# Define the path that `amtool` can find your `alertmanager` instance
alertmanager.url: "http://progs:9093"

# Override the default author. (unset defaults to your username)
author: me@example.com

# Force amtool to give you an error if you don‘t include a comment on a silence
comment_required: true
comment: default

# Set a default output format. (unset defaults to simple)
output: extended

新建silence

将在Alertmanager的http://progs:9093上添加一个新silence，它将警报与两个标签匹配：自动填充包含警报名称的alertname标签和service标签。并返回一个silence ID

/ups/app/monitor/alertmanager/bin/amtool --comment=testing --alertmanager.url=http://progs:9093 silence add alertname=InstancesGone service=application

• 使用默认config.yml文件添加silence

/ups/app/monitor/alertmanager/bin/amtool silence add alertname=InstancesGone 

查询当前的silence列表

/ups/app/monitor/alertmanager/bin/amtool --alertmanager.url=http://progs:9093 silence query

Prometheus-alertmanager组件使用

原文：https://www.cnblogs.com/binliubiao/p/13465140.html