关于运维:Prometheus-Alertmanager生产配置趟过的坑总结

简介

Alertmanager 解决由客户端应用程序（如 Prometheus server）发送的警报。它负责去重(deduplicating)，分组(grouping)，并将它们路由(routing)到正确的接收器(receiver)集成，如电子邮件，微信，或钉钉。它还负责解决警报的静默/屏蔽(silencing)、定时发送/不发送(Mute)和克制(inhibition)问题。

AlertManager 作为开源的为 Prometheus 而设计的告警利用, 曾经具备了告警利用各类丰盛、灵便、可定制的性能：

去重(deduplicating)：比方高可用 AlertManager 部署下，同一个告警同时发到所有的高可用节点，会依据 hash 进行去重
分组（grouping）：比方能够依据 AlertName, Instance, Job 等任意 label 对海量告警进行分组. 典型状况就是, 忽然好多 Pod 都收回了 AlertName: InstanceDown 的 Alerts, 那么能够间接依据 AlertName 进行分组后发送, 这样用户只会收到一封 xxx 个 Pods InstanceDown 的告警邮件. 大大减少告警接管人员的收件量.
路由(routing): 将告警跟进肯定的过滤条件发送到指定的 receiver. 如: 满足 job=db 的告警路由给 DBA; 满足 team=team-A 的告警路由给 team-A 的邮件组...
接收器(receiver): 具体的告诉渠道 + 收件人. 如: 邮件告诉渠道+DBA邮箱; 钉钉告诉渠道+SRE联系人;
静默/屏蔽(silencing): 如利用公布的时间段, 屏蔽相干的告警.
定时发送/不发送(Mute): 如工作工夫(965, 每周 5天)通过邮件渠道发送; 非工作工夫(上班、周末、节假日)失常渠道 mute，仅通过 on-call 渠道发送给 on-call 人员
克制(inhibition)：罕用场景，高级别的告警触发（firing）后，低级别的告警就不必发了。比方：磁盘空间的 critical 级别告警曾经触发(空间应用超过 90%), 这时候 warning 级别的告警(空间应用超过 80%)就被克制.

除了没有多租户性能、没有很好的 UI 界面、没有告警历史统计展现之外，作为告警利用， AlertManager 曾经是十分弱小了。️️️

AlertManager 生产配置趟过的坑

接下来就不东拉西扯了，间接进入正题：AlertManager 生产配置趟过的坑

Notes:
以下所有内容基于 20220723 时 AlertManager 的最新版: v0.24

URL 相干配置

需要

对外展现的 URL 是相似这样的： https://ewhisper.cn/alertmanager/#/alerts
1. 是个域名
2. 有个 /alertmanager/ 前缀
申请转到 AlertManager 组件时, 还是维持默认的状况不变, 如 https://10.0.0.1:9093/#/alerts

即: 反向代理发送的门路与用户应用的不同.

实现

Ingress 层面的实现

这里间接应用 Traefik 来实现的, 之前曾经写过文章了, 具体参见这里:

基于 Traefik 如何实现向后转发主动去掉前缀? - 东风微鸣技术博客 (ewhisper.cn)

AlertManager 配置

AlertManager 这里须要配置 2 个动态参数, 是通过在 AlertManager 的 StatefulSets 中增加 alertmanager --<flags> 来实现的.

默认状况下，Prometheus（和 Alertmanager）假设内部URL(-web.external-url)中的任何门路都是一个前缀门路，将在所有发送到它的申请中呈现。然而这并不总是如此，--web.route-prefix 标记容许你更细化地管制这一点。

通过如下配置, 这将在向 AlertManager 传递申请之前剥离掉/alertmanager/。在这种状况下，你须要指定用户在其浏览器中应用的URL是 https://ewhisper.cn/alertmanager/ ，而Prometheus在其HTTP申请中看到的前缀不是/alertmanager/，而只是空的/。

alertmanager \  --web.external-url https://ewhisper.cn/alertmanager/ \  --web.route-prefix=/

一个小坑

通过下面的配置, 都很完满, 然而查看邮件内容的时候发现一个小坑:

默认邮件模板最下方的 Sent by Alertmanager url 没有 /, 导致点击该url后无奈失常跳转.

Sent by Alertmanager 无奈跳转" title="点击 Sent by Alertmanager 无奈跳转">

这里是通过 Ingress - Traefik 实现了主动加 / 的性能, 能够参见另一篇文章:

基于 Traefik 如何实现 path 开端主动加斜杠？ - 东风微鸣技术博客 (ewhisper.cn)

默认主动 Resolved 告警的坑

如果你没有具体看过文档, 间接采纳的默认配置, 并且 AlertManager 的告警源除了 Prometheus 也有其余监控软件. 你会发现一个状况: 每过 5min, 某些还在触发中的告警被主动 Resolved(已复原) 了!

这是因为默认的 AlertManager 的配置中, 有个 resolve_timeout 的参数, 且其默认配置为: resolve_timeout: 5m.

️Reference:
ResolveTimeout是alertmanager应用的默认值，如果 alerts 不包含EndsAt，在这个工夫过后，如果 alerts 没有被更新，AlertManager 会将其申明为已解决(Resolved)。
这个参数对来自Prometheus的 alerts 没有影响，因为它们总是包含EndsAt。

这就是 主动 Resolved 的起因, 当初碰到的时候, 我一看, 这好办啊, 我想要禁用这个性能, 尽管这个参数无奈禁用, 如果非要在这份爱上加上一个期限，我心愿是一万年, 间接设置个 10000y 得了.

后果报错了...

这个 duration 在文档上, 明明说是:

️Reference:
<duration>: 正则表达式匹配的持续时间 ((([0-9]+)y)?(([0-9]+)w)?(([0-9]+)d)?(([0-9]+)h)?(([0-9]+)m)?(([0-9]+)s)?(([0-9]+)ms)?|0), 如. 1d, 1h30m, 5m, 10s

然而设置 10000y 满足 ([0-9]+)y) 却报错了.

前面又翻各种源码, 终于发现这个 <duration> 是无奈设置为三位数的 y 的: 设置 100y 报错, 设置 99y 失常运行.

所以, 想要禁用 AlertManager 主动 Resolved 的性能, 就这么设置: resolve_timeout: 99y

默认 4H 还未解决的告警主动重发告警告诉的坑

不管是谁, 我感觉都是心愿本人每天收到的告警邮件越少越好的, 不便一项项跟进解决.
后果 AlertManager 倒好, "贴心"地提供了4H 未解决告警主动重发 的性能.

这是因为默认的 AlertManager 的配置中, 有个 repeat_interval 的参数, 且其默认配置为: repeat_interval: 4h...

还是像上回一样, 我想要禁用这个性能, 尽管这个参数无奈禁用(如果设置为0, 不会禁用, 反而会报错: repeat_interval cannot be zero), 如果非要在这份爱上加上一个期限，我心愿是一万年, 间接设置个 10000y 得了.

后果又报错了(严格说是warning)...

repeat_interval is greater than the data retention period. It can lead to notifications being repeated more often than expected.

️Reference:
repeat_interval大于数据保留期。这可能导致告诉的反复频率超过预期。

也就是说, repeat_interval 设置太大反而可能会导致告诉的反复频率更高, 如果想把它设置的尽可能大, 也不要大于数据的保留工夫.

所以, 想要尽可能升高 AlertManager 未解决告警主动重发 的频率, 就这么设置: repeat_interval: <尽可能大, 但不要大于数据的保留(data retention)工夫

设置 AlertManager 的数据保留(data retention)时长

接着上文来说, 默认的 AlertManager 的数据保留(data retention)时长是多久呢? 如果想要调大该如何调呢?

查找文档, 又没找到

为啥没找到, 起因如下:

️Reference:
Alertmanager通过命令行标记(command-line flags)和一个配置文件进行配置。
命令行标记配置了不可扭转的零碎参数，而配置文件定义了克制规定、告诉路由和告诉接收者。

文档是没有对于 命令行标记配置 的内容的. 在哪儿能找到呢? 运行 alertmanager -h 命令, 后果如下:

Notes:
仅显示局部, cluster 相干的 flags 很多, 就不展现了.

$ alertmanager -husage: alertmanager [<flags>]Flags:    ...      --config.file="alertmanager.yml"                                 Alertmanager configuration file name.      --storage.path="data/"     Base path for data storage.      --data.retention=120h      How long to keep data for.      --alerts.gc-interval=30m   Interval between alert GC.      --web.config.file=""       [EXPERIMENTAL] Path to configuration file that can enable TLS or authentication.      --web.external-url=WEB.EXTERNAL-URL                                 The URL under which Alertmanager is externally reachable (for example, if Alertmanager is served via a reverse proxy). Used for generating relative and absolute links back to Alertmanager itself.                                 If the URL has a path portion, it will be used to prefix all HTTP endpoints served by Alertmanager. If omitted, relevant URL components will be derived automatically.      --web.route-prefix=WEB.ROUTE-PREFIX                                 Prefix for the internal routes of web endpoints. Defaults to path of --web.external-url.      --web.listen-address=":9093"                                 Address to listen on for the web interface and API.      --web.get-concurrency=0    Maximum number of GET requests processed concurrently. If negative or zero, the limit is GOMAXPROC or 8, whichever is larger.      --web.timeout=0            Timeout for HTTP requests. If negative or zero, no timeout is set.      ...      --log.level=info           Only log messages with the given severity or above. One of: [debug, info, warn, error]      --log.format=logfmt        Output format of log messages. One of: [logfmt, json]

能够看到: --data.retention=120h 默认是 120h, 5天.

太少了, 改为 --data.retention=90d, 后果又错了, 这次是格局, 应该写为: --data.retention=--data.retention=2160h

那么相应的, 下面的参数就能够设置为: repeat_interval: 90d (是的, 你没看错, 这里能够写为 90d ...)

残缺的生产实践 AlertManager 配置

最终, 给到大家一份残缺的生产实践 AlertManager 配置, 供参考:

不可变参数(及命令行 flags)

'--storage.path=/alertmanager' (存储地位, 生产上这个目录须要配置长久化存储)
'--config.file=/etc/alertmanager/alertmanager.yml' (配置文件地位, 生产上能够通过 ConfigMap 保留并应用)
'--cluster.advertise-address=[$(POD_IP)]:9094' (高可用集群端口 9094)
'--cluster.listen-address=0.0.0.0:9094' (高可用集群端口 9094)
--cluster.peer=alertmanager-0.alertmanager-headless:9094 (高可用集群的一个 peer; 须要创立 headless service)
--cluster.peer=alertmanager-1.alertmanager-headless:9094 (高可用集群的另一个 peer)
--cluster.peer=alertmanager-2.alertmanager-headless:9094 (高可用集群的第三个 peer)
'--data.retention=2160h'
'--log.level=info' (日志级别, 开发测试环境能够设置为 debug)
'--web.external-url=https://ewhisper.cn/alertmanager/'
'--web.route-prefix=/'

可变参数(配置文件中的参数)

global:  resolve_timeout: 99yreceivers:# jiralert 插件, 能够将告警发送到 jira- name: jiralert  webhook_configs:  - send_resolved: true    url: http://jiralert:9097/alertroute:  group_by:  - alertname  group_interval: 5m  group_wait: 1m  receiver: dev-receiver  repeat_interval: 90dtemplates:- /etc/alertmanager/*.tmpl

具体的 route, receiver, inhibit 等配置就不体现了.

以上.

三人行, 必有我师; 常识共享, 天下为公. 本文由东风微鸣技术博客 EWhisper.cn 编写.