通过 相关的配置我们知道了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
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: 'jiankong@exmail.qq.com'
smtp_auth_username: 'jiankong@exmail.qq.com'
smtp_auth_password: ''
smtp_require_tls: false
resolve_timeout: 5m
route:
receiver: mail
receivers:
- name: 'mail'
email_configs:
- to: 'gongxiude888@163.com'
在全局配置中需要注意的是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> ... ]
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的相关的配置
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子句指定一组信息标签，这些标签可用于存储更长的附加信息，例如警报描述或运行手册链接. 注释值可以模板化.
参考链接