8.3 prometheus alertmanager

通过scrape_configs 相关的配置我们知道了kubernetes如何配置job刮取数据，数据刮取完成后根据报警规则发送警告到alertmanager

+-------------------+  send alert   +--------------+     +--------+
| prometheus server | ------------> |              | --> | email  |
+-------------------+               |              |     +--------+
  |                                 |              |
  | get metrics                     | alertmanager |
  v                                 |              |
+-------------------+               |              |     +--------+
|  metrics server   |               |              | --> | wechat |
+-------------------+               +--------------+     +--------+

graph-easy code ``` [prometheus server] - get metrics -> [metrics server] [prometheus server] - send alert -> [alertmanager]{rows: 4} [alertmanager] -> [email] [alertmanager] -> [wechat] ```

根据上面的简单图解我们需要知道两个信息： 1. 报警通过什么介质发送？ 2. 哪些需要发送告警？ 3. 报警发送的频率怎么控制？

alertmanager的主要功能如下：

管理警报的重复提醒时机与消除后消除通知的发送；
根据标签定义警报路由，实现警报的优先级、接收人划分，并针对不同的优先级和接收人定制不同的发送策略；
将同类型警报打包成一条通知发送出去，降低警报通知的频率；
支持静默规则: 用户可以定义一条静默规则，在一段时间内停止发送部分特定的警报，比如已经确认是搜索集群问题，在修复搜索集群时，先静默掉搜索集群相关警报；
支持”抑制”规则(Inhibition Rule): 用户可以定义一条”抑制”规则，规定在某种警报发生时，不发送另一种警报，比如在”A 机房网络故障”这条警报发生时，不发送所有”A 机房中的警报”；

1. 安装和配置AlertManger

因为使用helm安装了alertmanager， alertmanager的启动参数如下：

/bin/alertmanager \
  --config.file=/etc/config/alertmanager.yml  \
  --storage.path=/data

--config.file来指定相应的配置文件

--storage.path指定了数存储目录

1.1 alertmanager.yml

可以查看官方文档来了解alertmanager的更多配置内容

altermanager的内部工作机制为:

+ - - - - - - - - - - +                       + - - - - - - - - - - - - - - - - -+
' prometheus server   '                       ' alertmanager                     '
'                     '                       '                                  '
' +-----------------+ '  send alert message   ' +------------+     +-----------+ '
' |   alert rule    | ' --------------------> ' |   route    | --> | receivers | '
' +-----------------+ '                       ' +------------+     +-----------+ '
'                     '                       '                                  '
+ - - - - - - - - - - +                       + - - - - - - - - - - - - - - - - -+

_$ graph-easy graph.txt_ ``` (prometheus server [alert rule] - send alert message -> [route]) (alertmanager [route] -> [receivers]) ```

1.1.1 完整配置文件

global:
  .....

templates:
  ....

route: 
  ....

receivers:
  ....

inhibit_rules:
  ....

Alertmanager配置中一般会包含以下几个主要部分：

全局配置（global）：用于定义一些全局的公共参数，如全局的SMTP配置，Slack配置等内容；
模板（templates）：用于定义告警通知时的模板，如HTML模板，邮件模板等；
告警路由（route）：根据标签匹配，确定当前告警应该如何处理；
接收人（receivers）：接收人是一个抽象的概念，它可以是一个邮箱也可以是微信，Slack或者Webhook等，接收人一般配合告警路由使用；
抑制规则（inhibit_rules）：合理设置抑制规则可以减少垃圾告警的产生

配置例子

global:
  smtp_smarthost: 'smtp.exmail.qq.com' 
  smtp_from: '[email protected]' 
  smtp_auth_username: '[email protected]' 
  smtp_auth_password: ''
  smtp_require_tls: false
  resolve_timeout: 5m
route: 
  receiver: mail
receivers:
- name: 'mail'
  email_configs:
  - to: '[email protected]'

在全局配置中需要注意的是resolve_timeout，该参数定义了当Alertmanager持续多长时间未接收到告警后标记告警状态为resolved（已解决）。该参数的定义可能会影响到告警恢复通知的接收时间，读者可根据自己的实际场景进行定义，其默认值为5分钟。

1.2 route 配置

在Alertmanager的配置中会定义一个基于标签匹配规则的告警路由树，以确定在接收到告警后Alertmanager需要如何对其进行处理.

而在route部分主要定义了告警的路由匹配规则， Alertmanager需要将匹配到的告警发送给哪一个receiver，配置格式如下：

# receivers段配置的报警方式或报警分组
[ receiver: <string> ]
# 根据label匹配报警分组 
[ group_by: '[' <labelname>, ... ']' ]

# 告警是否去继续路由子节点
[ continue: <boolean> | default = false ]

# 通过标签去匹配这次告警是否符合这个路由节点
match:
  [ <labelname>: <labelvalue>, ... ]

# 使用正则表达式的方式匹配接受到的报警label是否符合这个路由节点
match_re:
  [ <labelname>: <regex>, ... ]

# 组内等待时间，同一分组内收到第一个告警等待多久开始发送，目标是为了同组消息同时发送，不占用告警信息，默认30s
[ group_wait: <duration> | default = 30s ]

# 当组内已经发送过一个告警，组内若有新增告警需要等待的时间，默认为5m,
[ group_interval: <duration> | default = 5m ]

# 告警已经发送，且无新增告警，若重复告警需要间隔多久 默认4h 属于重复告警，时间间隔应根据告警的严重程度来设置
[ repeat_interval: <duration> | default = 4h ]

# 路由子节点配置信息跟主节点的路由信息一致
routes:
  [ - <route> ... ]

官方文档例子

route:
  # 根节点的警报会发送给默认的接收组
  # 该节点中的警报会按’cluster’和’alertname’做 Group，每个分组中最多每5分钟发送一条警报，同样的警报最多4小时发送一次
  receiver:’default-receiver’
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  group_by: [cluster, alertname]
  # 没有匹配到子节点的警报，会默认匹配到根节点上
  # 接下来是子节点的配置：
  routes:
    # 所有 service 字段为 mysql 或 cassandra 的警报，会发送到’database-pager’这个接收组
    # 由于继承逻辑，这个节点中的警报仍然是按’cluster’和’alertname’做 Group 的
  - receiver:’database-pager’
    group_wait: 10s
    match_re:
    service: mysql|cassandra
    # 所有 team 字段为 fronted 的警报，会发送到’frontend-pager’这个接收组
    # 很重要的一点是，这个组中的警报是按’product’和’environment’做分组的，因为’frontend’面向用户，更关心哪个’产品’的什么’环境’出问题了
  - receiver:’frontend-pager’
    group_by: [product, environment]
    match:
    team: frontend

2. 配置Prometheus来和AlertManager通信

配置文件如下：

# Alerting specifies settings related to the Alertmanager.
alerting:
  alert_relabel_configs:
    [ - <relabel_config> ... ]
  alertmanagers:
    [ - <alertmanager_config> ... ]

alert_relabel_configs相关的配置参考2.1 relabel_configs，将警报从新标记以后发送到Alertmanager
alertmanagers Prometheus服务器将警报发送到的Alertmanager实例。可以通过static_configs参数静态配置，也可以使用受支持的服务发现机制之一动态发现。

2.1 使用kubernetes_sd_configs发现机制

alertmanagers:
- kubernetes_sd_configs:
  - role: pod
tls_config:
  ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
relabel_configs:
- source_labels: [__meta_kubernetes_namespace]
  regex: devops
  action: keep
- source_labels: [__meta_kubernetes_pod_label_app]
  regex: prometheus
  action: keep
- source_labels: [__meta_kubernetes_pod_label_component]
  regex: alertmanager
  action: keep
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_probe]
  regex: .*
  action: keep
- source_labels: [__meta_kubernetes_pod_container_port_number]
  regex:
  action: drop

2.2 使用static_config

alerting:
  alertmanagers:
  - static_configs:
    - targets:
      - localhost:9093

这里的localhost根据实际情况进行修改，可以修改为kubernetes中service

3. alert_rule的相关的配置

站在巨人的肩膀上请访问https://awesome-prometheus-alerts.grep.to/rules#host-and-hardware 查看别人定义好的规则

3.2.1 prometheus报警规则配置

需要在prometheus的配置文件中添加如下内容

rule_files:
    - /etc/prometheus/rules.yml

其中rule_files就是用来指定报警规则的, 其中rules.yml中主要内容如下

告警规则尊许如下风格

ALERT <alert name>
  IF <expression>
    [ FOR <duration> ]
      [ LABELS <label set> ]
        [ ANNOTATIONS <label set> ]

例子

groups:    # 配置多个分组来区分不同的用途， 如POD、Node等
- name: example
  rules:   # 配置多个报警规则实现不同指标指标阀值的报警
  - alert: HighRequestLatency 
    expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5  
    for: 10m
    labels:
      severity: page
    annotations:
      summary: High request latency

expr promQL表达式，如果满足该条件发送报警

for子句

没有该FOR子句（或设置为0）的警报将立即转换为firing。
带有该FOR子句的警报将首先转换为pending，等待for的时间后再转换为firing。

labels子句允许指定一组附加标签来附加到警报. 任何现有的冲突标签都将被覆盖. 标签值可以模板化.

annotations子句指定一组信息标签，这些标签可用于存储更长的附加信息，例如警报描述或运行手册链接. 注释值可以模板化.

参考链接

https://aleiwu.com/post/alertmanager/

上一页8.3 prometheus 配置文件详解下一页9.0 kubernetes配置管理篇

最后更新于5年前

这有帮助吗？