Alertmanager 告警详解

监控告警

• 部署Alertmanager

• 配置Prometheus与Alertmanager通信

• 在Prometheus中创建告警规则

• 告警状态

Alertmanager如何工作

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

我们将在Prometheus服务器上编写警报规则，这些规则将使用我们收集的指标并在指定的阈值或标准上触发警报。我们还将看到如何为警报添加一些上下文。当指标达到阈值或标准时，会生成一个警报并将其推送到Alertmanager。警报在Alertmanager上的HTTP端点上接收。一个或多个Prometheus 服务器可以将警报定向到单个Alertmanager，或者你可以创建一个高可用的Alertmanager集群。

收到警报后，Alertmanager会处理警报并根据其标签进行路由。一旦路径确定，它们将由Alertmanager发送到外部目的地，如电子邮件、短信或聊天工具。

部署Alertmanager

要实现告警通过altermanager这个组件完成的，必须告诉普罗米修斯altermanager是谁，到时候评估高级规则里面触发了阈值好把告警事件推送给altermanager，然后进入其自己内部的处理逻辑，处理完之后发送到接收人。

在altermanager里面还需要配置接收人，分组，收敛

[root@localhost system]# pwd
/usr/lib/systemd/system
[root@localhost ~]# tar xf alertmanager-0.21.0.linux-amd64.tar.gz
[root@localhost ~]# mv alertmanager-0.21.0.linux-amd64 /usr/local/alertmanager[root@localhost system]# systemctl daemon-reload
[root@localhost system]# systemctl start alertmanager.service
[root@localhost system]# cat alertmanager.service
# vi /usr/lib/systemd/system/grafana.service
[Unit]
Description=alertmanager[Service]
ExecStart=/usr/local/alertmanager/alertmanager --config.file=/usr/local/alertmanager/alertmanager.yml
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure[Install]
WantedBy=multi-user.target

配置Prometheus与Alertmanager通信

alerting:alertmanagers:- static_configs:- targets:- 127.0.0.1:9093

配置告警规则也是在普罗米修斯这里进行配置

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

配置Alertmanager

一个简单的alertmanager.yml配置文件

此配置文件包含一个基本设置，用于处理警报并通过电子邮件将其发送到一个地址。让我们依次看一下每个块的具体内容。

第一个块global包含Alertmanager的全局配置。这些选项为所有其他块设置默认值，并在这些块中作为覆盖生效。在示例中，我们只是配置一些电子邮件和SMTP设置：发送电子邮件的邮件服务器、发送电子邮件的地址，并且我们禁用自动使用TLS的要求

接下来，我们看看route块，它会告诉Alertmanager如何处理特定的传入警报。警报根据规则进行匹配然后采取相应的操作。你可以把路由想象成有树枝的树，每个警报都从树的根（基本路由或基本节点）进入（如图所示）。除了基本节点之外，每个路由都有匹配的标准，这些标准应该匹配所有警报。然后，你可以定义子路由或子节点，它们是树的分支，对某些特定的警报感兴趣，或者会采取某些特定的操作。例如，来自特定集群的所有警报可能由特定的子路由处理。

在当前的配置中，我们只定义了基本路由，即树的根节点。在本章后面，我们将利用路由来确保警报具有正确的容量、频率和目的地。

我们只定义了一个参数receiver。这是我们警报的默认目的地，在示例中是email电子邮件。接下来我们将定义该接收器。

最后一个块receivers指定警报目的地。你可以通过电子邮件发送警报，或者发送到PagerDuty和 VictorOps等服务，以及Slack和HipChat等聊天工具。这里我们只定义了一个目的地：一个电子邮件地址。

每个接收器都有一个名称和相关配置。这里我们已经命名了接收器email。然后，我们为特定类型的接收器提供配置。

对于电子邮件警报，我们使用email_configs块来指定电子邮件选项，例如接收警报的地址。我们还可以指定SMTP设置（这将覆盖全局设置），并添加其他条目（例如邮件标头）。

修改altermanager的配置文件

分组的概念：将类似的指标分组，比如说监控linux服务器会监控其负载，资源负载就是一个分组，这个分组下面会有cpu的指标，内存的指标。

 rules.yml: |groups:- name: kubernetesrules:- alert: KubernetesNodeReadyexpr: kube_node_status_condition{condition="Ready",status="true"} == 1for: 30slabels:severity: criticalannotations:summary: Kubernetes Node ready (instance {{ $labels.instance }})description: "Node {{ $labels.node }} has been unready for a long time\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"- name: examplerules:- alert: InstanceDownexpr: up == 0for: 30slabels:severity: criticalannotations:summary: "{{ $labels.instance }} stop"description: "{{ $labels.instance }}:job{{ $labels.job }} stop"

每个告警也不是每个人都需要收到，这个时候就需要根据指标当中的不同标签发送给不同的人，这下面加了一个routes节点，在这下面有两块的接收人，根据不同的标签发给不同的项目组的人，总之就是通过标签去匹配。Altermanager根据指标当中的标签匹配发送到不同的收件人。

一个是对告警进行分组，一个routes根据标签发送给不同的人。

    route:group_by: [alertname]group_wait: 10sgroup_interval: 10srepeat_interval: 100mreceiver: defaultroutes:- receiver: emailgroup_wait: 15smatch:job: pushgatewayreceivers:- name: 'default'webhook_configs:- url: 'http://192.168.100.5:8060/dingtalk/cluster1/send'send_resolved: true- name: 'email'email_configs:- to: '1239683670@qq.com'send_resolved: true
~

[root@localhost ~]# cat /usr/local/alertmanager/alertmanager.yml
global:resolve_timeout: 5msmtp_smarthost: 'smtp.163.com:25'smtp_from: 'luleihhh@163.com'smtp_auth_username: 'luleihhh@163.com'smtp_auth_password: 'xxxxxxxxxxxxxxx' smtp_require_tls: falseroute:group_by: ['alertname']group_wait: 10sgroup_interval: 10srepeat_interval: 10mreceiver: 'mail'
receivers:
- name: 'mail'email_configs:- to: 'luleihhh@163.com'- to: '1239683670@qq.com'

产生告警之后等待10s，同一个组还有报警，那就和其他告警一起发出去，产生告警不会立刻发出去，等待这个组内其他告警产生，然后一起发出去。

    route:  #用于配置告警分发策略group_by: [alertname] # 采用哪个标签来作为分组依据group_wait: 10s       # 组告警等待时间。也就是告警产生后等待10s，如果有同组告警一起发出group_interval: 10s   # 如果有不同的组，两组告警的间隔时间repeat_interval: 10m    # 重复告警的间隔时间，减少相同邮件的发送频率receiver: default-receiver  # 设置默认接收人

普罗米修斯启用告警配置

这个目录就是一个相对路径

rule_files:- "rules/*.yml"

创建告警规则，这个是在分组下面创建告警规则，up为1代表正常 up为0代表不正常

只要采集目标端up指标等于0那么普罗米修斯评估到触发阈值了，然后将其发向latermanager

1m钟之内，只要处于处于条件为真的状态up==0那么就触发

自定义标签，也就是自定义，让你收到告警的时候对标签更加清晰，附加信息说明告警

[root@localhost ~]# mkdir -p /usr/local/prometheus/rules[root@localhost ~]# cat /usr/local/prometheus/rules/node.yml
groups:
- name: example rules:- alert: InstanceDown expr: up == 0 # 基于PromQL的触发条件for: 1m # 等待评估时间labels: # 自定义标签severity: pageannotations: # 指定附加信息summary: " {{ $labels.instance }} 停止工作"description: "{{ $labels.instance }}:job{{ $labels.job }} 已经停止5分钟以上."

这里可以写多个分组，如果还要分组- name

只要采集的指标当中有的指标都可以在告警描述当中引用

每个被监控端都有up这个标签，up为1代表服务正常，如果等于0代表服务不正常。所以可以通过up获取所有的被监控端状态

查看告警规则是否生效

告警状态

• Inactive：这里什么都没有发生。

• Pending：已触发阈值，但未满足告警持续时间，也就是for字段

• Firing：已触发阈值且满足告警持续时间。警报发送给接受者。

被监控端一个主机down了，查看告警，可以看到告警处于pending的状态，进入for循环评估当中

在评估期内满足条件告警状态触发了，此时状态为Firing

这里可以在告警规则里面定义一些标签，方面后期的处理，主要是在altermanager里面体现

最后邮箱查看，记住，同一个组下面的多个告警触发，在发送的时候会合并为一封邮件！

最后一点我想说的是， repeat_interval: 10m # 重复告警间隔发送时间，可以看到相同的告警再次触发需要间隔十分钟，建议配置为1m钟

Kubernetes Node ready

Node {{ $labels.node }} has been unready for a long time

  - alert: KubernetesNodeReadyexpr: kube_node_status_condition{condition="Ready",status="true"} == 0for: 10mlabels:severity: criticalannotations:summary: Kubernetes Node ready (instance {{ $labels.instance }})description: "Node {{ $labels.node }} has been unready for a long time\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

Prometheus一条告警怎么触发的？

Prometheus scrape_interval: 15s：采集的时间间隔是15s，也就是默认每隔15s采集一次指标，也就是有一个实例宕掉了，正好前一秒刚好采集完，那么还要等15s才能采集到这个指标，普罗米修斯才能感知到。

Prometheus evaluation_interval: 1m：告警评估周期，也就是每隔多长时间对采集的指标做个评估

Prometheus for: 30s 评估时间

Alertmanager group_wait: 10s 还需要分组，所以告警在这还会等待

所以告警触发了并不是马上就可以通知到你，需要经历上面的阶段。