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

3次阅读

共计 6191 个字符，预计需要花费 16 分钟才能阅读完成。

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 生产配置趟过的坑

📝Notes:

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

对外展现的 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)

如果你没有具体看过文档, 间接采纳的默认配置, 并且 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

不管是谁, 我感觉都是心愿本人每天收到的告警邮件越少越好的, 不便一项项跟进解决.
后果 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) 时长是多久呢? 如果想要调大该如何调呢?

查找文档, 又没找到😂😂😂

为啥没找到, 起因如下:

📚️Reference:

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

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

📝Notes:

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

$ alertmanager -h
usage: 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 配置, 供参考:

'--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: 99y
receivers:
# jiralert 插件, 能够将告警发送到 jira
- name: jiralert
  webhook_configs:
  - send_resolved: true
    url: http://jiralert:9097/alert
route:
  group_by:
  - alertname
  group_interval: 5m
  group_wait: 1m
  receiver: dev-receiver
  repeat_interval: 90d
templates:
- /etc/alertmanager/*.tmpl

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

以上.

🎉🎉🎉

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

正文完

运维

发表至：运维

2023-03-20

0

关于运维:实用教程Linux系统Windows系统硬盘扩容教程

关于运维:恒源云云GPU服务器如何使用FinRL

关于运维:PrometheusInfluxDBGrafana-打造高逼格监控平台

关于运维:阿里云的认证为什么那么多人考没基础的人能考吗

关于运维:Cron-Job-表达式解析

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

简介

AlertManager 生产配置趟过的坑

URL 相干配置

需要

实现

Ingress 层面的实现

AlertManager 配置

一个小坑

默认主动 Resolved 告警的坑

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

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

残缺的生产实践 AlertManager 配置

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

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

站内搜索