运维别卷系列 - 云原生监控平台之 05.prometheus alertManager 实践-编程知识

文章目录

@[toc]
Alertmanager 简介
Alertmanager 实现的核心概念
Grouping
Inhibition
Silences
Client behavior
High Availability

Alertmanager 配置文件
global
templates
route
inhibit_rules
receivers

Alertmanager 部署
创建 cm
创建 svc
创建 sts
Prometheus 配置告警
Prometheus 配置文件增加 Alertmanager 配置
Prometheus 增加告警规则

Alertmanager 简介

ALERTMANAGER

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

Alertmanager 实现的核心概念

Grouping

Grouping categorizes alerts of similar nature into a single notification. This is especially useful during larger outages when many systems fail at once and hundreds to thousands of alerts may be firing simultaneously.
分组将类似性质的警报分类到单个通知中。这在较大规模的中断期间特别有用，因为许多系统同时发生故障，并且可能同时触发数百到数千个警报。

Inhibition

Inhibition is a concept of suppressing notifications for certain alerts if certain other alerts are already firing.
抑制是一个概念，用于在已触发某些其他警报时抑制某些警报的通知。

Silences

Silences are a straightforward way to simply mute alerts for a given time. A silence is configured based on matchers, just like the routing tree. Incoming alerts are checked whether they match all the equality or regular expression matchers of an active silence. If they do, no notifications will be sent out for that alert.
静默是一种在给定时间内简单地将警报静默的简单方法。静默是基于匹配器配置的，就像路由树一样。检查传入警报是否与活动静默的所有相等或正则表达式匹配器匹配。如果他们这样做，则不会针对该警报发送任何通知。

Client behavior

The Alertmanager has special requirements for behavior of its client. Those are only relevant for advanced use cases where Prometheus is not used to send alerts.
Alertmanager 对其客户端的行为有特殊要求。这些仅与不使用 Prometheus 发送警报的高级用例相关。

High Availability

Alertmanager supports configuration to create a cluster for high availability. This can be configured using the --cluster-* flags.

Alertmanager 支持配置以创建集群以实现高可用性。这可以使用 --cluster-* 标志进行配置。

It’s important not to load balance traffic between Prometheus and its Alertmanagers, but instead, point Prometheus to a list of all Alertmanagers.

重要的是不要在 Prometheus 及其 Alertmanager 之间对流量进行负载均衡，而是将 Prometheus 指向所有 Alertmanager 的列表。

Alertmanager 配置文件

CONFIGURATION

和 Prometheus 一样，Alertmanager 也支持 post 请求来 reload 配置文件，也是 /-/reload

github 上的配置文件示例

global

全局配置

global:# 定义邮件服务器smtp_smarthost: 'localhost:25'# 发送邮件的邮件地址smtp_from: 'alertmanager@example.org'# 发件人名字（具体以邮件服务器为准）smtp_auth_username: 'alertmanager'# 基于 SMTP 身份验证的，不是平常使用的明文密码，需要从邮箱里面申请smtp_auth_password: 'password'# SMTP 是否是 tlssmtp_require_tls: false

templates

邮件报警的内容模板

templates:- '/etc/alertmanager/template/*.tmpl'

route

与路由相关的设置允许根据时间配置警报的路由、聚合、限制和静音方式。

route:# 依据 label 做分组，例如：cluster=A 和 alertname=LatencyHigh 的多个警报将被批处理到一个组中。# 这有效地完全禁用了聚合，按原样传递所有警报。这不太可能是您想要的，除非您的警报量非常低，或者您的上游通知系统执行自己的分组。group_by: ['alertname', 'cluster', 'service']# 当传入警报创建新的警报组时，请至少等待 "group_wait" 以发送初始通知。# 这种方式可以确保您获得同一组的多个警报，这些警报在第一次通知中将另一个警报批处理在一起后不久就开始触发。group_wait: 30s# 发送第一个通知时，请等待 "group_interval" 以发送一批已开始为该组启动的新警报。group_interval: 5m# 如果警报已成功发送，请等待 "repeat_interval" 重新发送警报。repeat_interval: 3h# 默认的接收器receiver: team-X-mails# 以上所有属性都由所有子路由继承，并且可以在每条路由上进行覆盖。# 子路由routes:# 此路由对警报标签执行正则表达式匹配，以捕获与服务列表相关的警报。- matchers:- service=~"foo1|foo2|baz"receiver: team-X-mails# 该服务有一个关键警报的子路由，任何不匹配的警报，即不等于 critical 的，回退到父节点并发送到 "team-X-mails"routes:- matchers:- severity="critical"receiver: team-X-pager- matchers:- service="files"receiver: team-Y-mailsroutes:- matchers:- severity="critical"receiver: team-Y-pager# 此路由处理来自数据库服务的所有警报。如果没有团队来处理，则默认由 DB 团队处理。- matchers:- service="database"receiver: team-DB-pager# 按受影响的数据库对警报进行分组。group_by: [alertname, cluster, database]routes:- matchers:- owner="team-X"receiver: team-X-pagercontinue: true- matchers:- owner="team-Y"receiver: team-Y-pager

inhibit_rules

当存在与另一组匹配器匹配的警报（源）时，禁止规则会将匹配一组匹配器的警报（目标）静音。目标警报和源警报必须具有 equal 列表中标签名称的相同标签值。

# 抑制规则允许在另一个警报正在触发的情况下使一组警报静音。
# 如果同一警报已经是关键警报，我们将使用此功能来静音任何警告级别的通知。
inhibit_rules:- source_matchers: [severity="critical"]target_matchers: [severity="warning"]# 如果源警报和目标警报中都缺少 "equal" 中列出的所有标签名称，则将应用禁止规则！equal: [alertname, cluster, service]

receivers

一个或多个通知集成的命名配置。

receivers:- name: 'team-X-mails'email_configs:- to: 'team-X+alerts@example.org'- name: 'team-X-pager'email_configs:- to: 'team-X+alerts-critical@example.org'pagerduty_configs:- service_key: <team-X-key>- name: 'team-Y-mails'email_configs:- to: 'team-Y+alerts@example.org'- name: 'team-Y-pager'pagerduty_configs:- service_key: <team-Y-key>- name: 'team-DB-pager'pagerduty_configs:- service_key: <team-DB-key>

Alertmanager 部署

同样，这里是采用 k8s 的方式来部署的，部署的版本是 v0.27.0

创建 cm

smtp 相关的，大家修改成自己的配置就可以了

---
apiVersion: v1
data:alertmanager.yml: |global:resolve_timeout: 5msmtp_smarthost: 'localhost:25'smtp_from: 'alertmanager@example.org'smtp_auth_username: 'alertmanager'smtp_auth_password: 'alertmanager'smtp_require_tls: falsetemplates:- '/app/config/email.tmpl'receivers:- name: default-receiveremail_configs:- to: "imcxsen@163.com"html: '{{ template "email.to.html" . }}'headers: { Subject: " {{ .CommonAnnotations.summary }}" }send_resolved: trueroute:group_interval: 15mgroup_wait: 30sreceiver: default-receiverrepeat_interval: 15mroutes:- match:severity: warningreceiver: default-receivercontinue: true- match:severity: errorreceiver: default-receivercontinue: trueemail.tmpl: |-{{ define "email.to.html" }}{{ range .Alerts }}========= {{ .StartsAt.Format "2006-01-02T15:04:05" }} ==========<br>告警程序: prometheus_alert <br>告警类型: {{ .Labels.alertname }} <br>故障主机: {{ .Labels.instance }} <br>告警主题: {{ .Annotations.summary }} <br>告警详情: {{ .Annotations.description }} <br>{{ end }}{{ end }}
kind: ConfigMap
metadata:labels:name: alertmanager-cmnamespace: monitor

创建 svc

---
apiVersion: v1
kind: Service
metadata:annotations:labels:app: alertmanagername: alertmanager-svcnamespace: monitor
spec:ports:- name: httpprotocol: TCPport: 9093selector:app: alertmanagertype: ClusterIP

创建 sts

---
apiVersion: apps/v1
kind: StatefulSet
metadata:labels:app: alertmanagername: alertmanagernamespace: monitor
spec:replicas: 1selector:matchLabels:app: alertmanagerserviceName: alertmanager-svctemplate:metadata:annotations:labels:app: alertmanagerspec:containers:- args:- "--config.file=/app/config/alertmanager.yml"- "--storage.path=/alertmanager/data"image: prom/alertmanager:v0.27.0livenessProbe:failureThreshold: 60initialDelaySeconds: 5periodSeconds: 10successThreshold: 1tcpSocket:port: servicetimeoutSeconds: 1name: alertmanagerports:- containerPort: 9093name: serviceprotocol: TCP- containerPort: 8002name: clusterprotocol: TCPresources:limits:cpu: 1000mmemory: 1024Mirequests:cpu: 1000mmemory: 1024MivolumeMounts:- mountPath: /app/configname: config-volumevolumes:- configMap:name: alertmanager-cmname: config-volume

Prometheus 配置告警

Prometheus 配置文件增加 Alertmanager 配置

主要增加以下的内容，定义 Prometheus 的告警规则路径和 Alertmanager 的地址，配置完成后 curl -X POST http://ip:port/-/reload 来更新 Prometheus 的配置文件

rule_files:
- /etc/prometheus/rules/*.yml
alerting:alertmanagers:- static_configs:- targets: ["alertmanager-svc.monitor.svc.cluster.local:9093"]

Prometheus 增加告警规则

这里为了方便验证，所以把内存使用率超过 15% 的来触发报警，因为我当前环境，有机器的内存使用率是超过 15%的，这个只需要把 expr 里面的 PromQL 放到 Prometheus 里面执行一下，找到一个均值就可以了，和上面一样，增加了规则文件，也需要 reload 一下 Prometheus 的配置文件

下面定义了一个名字叫 NodeMemoryUsage 的报警
for 语句会使 Prometheus 服务等待指定的时间，然后执行查询表达式。
labels 语句允许指定额外的标签列表，把它们附加在告警上。我这里暂时没加
annotations 语句指定了另一组标签，它们不被当做告警实例的身份标识，它们经常用于存储一些额外的信息，用于报警信息的展示之类的。

一个报警信息在生命周期内有下面 3 种状态：
inactive: 表示当前报警信息既不是 firing 状态也不是 pending 状态
pending: 表示在设置的阈值时间范围内被激活了
firing: 表示超过设置的阈值时间被激活了

groups:
- name: test-rulerules:- alert: NodeMemoryUsageexpr: (node_memory_MemTotal_bytes - (node_memory_MemFree_bytes + node_memory_Buffers_bytes + node_memory_Cached_bytes)) / node_memory_MemTotal_bytes * 100 > 15for: 2mannotations:summary: "{{$labels.instance}}: High Memory usage detected"description: "{{$labels.instance}}: Memory usage is above 15% (current value is: {{ $value }}"