Prometheus AlertManager 生产实践-直接根据 to_email label 发 alert 到对应邮箱

prometheus,alertmanager,生产,实践,直接,根据,to,email,label,alert,对应,邮箱 · 浏览次数 : 108

小编点评

通过模板,可以实现通过 Alerts 里自带收件人信息 (如邮箱) 直接使用,而无需再录入所有的 receivers 的情况。 模板可以定义接收人的名称、邮箱地址、主题、内容等信息,并根据模板设置对应的 receiver,方便快捷地处理多个告警组。

正文

概述

通过之前的文章 - Prometheus Alertmanager 生产配置趟过的坑总结, 我们已经知道 AlertManager 作为告警平台,是非常强大的,可以去重 (deduplicating),分组 (grouping),并将它们路由 (routing) 到正确的接收器 (receiver) 集成,如电子邮件,微信,或钉钉。它还负责处理警报的静默/屏蔽 (silencing)、定时发送/不发送 (Mute) 和抑制 (inhibition) 问题。

正常的 AlertManager 处理告警流程,是要经过 Alerts -> Route -> Receivers 这么一个步骤的

  1. Alerts 里带了一些标签,如 env, team, job 等
  2. 根据提前编辑好的 Route, 对 alerts 进行路由,比如 env=prod 的发给哪些 receiver, team=db 的发给哪些人。..
  3. 在 Receivers 里已经提前录入了这些需要处理 prod,处理 db 告警的 receivers 邮箱。告警这样发给对应的收件人。

但是,假如我在 Alerts 里自带收件人信息(如邮箱),能不能直接使用?而不需要再录入所有的 receivers。

答案当然是可以!通过模板(template)实现这个需求。Let's GO!💪💪💪

模板(Template)简介

AlertManager 模板最初的目的是为了对告警的消息做定制化的。
比如同样的 Alerts,我:

  • 通过 SMS 发送,期望是纯文本格式;
  • 通过 email 发送,期望是 HTML 格式;
  • 通过钉钉、企微发送,期望是 Markdown 格式;
  • 而且在这些渠道中,
    • 标题是不同的排列组合
    • 告警内容也是不同的段落格式和用词(比如通过钉钉、企微会加入更多的 emoji)

AlertManager 模板是和 Prometheus 模板一样,使用的同样是 Go template。当然,具体的数据和函数会有细微的区别,因为在这里主要处理的是告警而非单个告警。

示例如下:

receivers:
  - name: emergency
    slack_configs:
    - api_url: https://hooks.slack.com/services/XXXXXXXX
      channel: '#emergency'
      title: 'Alerts in {{ .GroupLabels.cluster }} {{ .GroupLabels.env }}!'

AlertManager 进阶

除了模板化 txt 字段,通知的定义(比如:发给谁)也可以被模板化。通常每个 team 都有自己的路由树,以及相对应的收件人(receivers)。如果另一个团队(不是监控团队,也不是运维团队,而是测试等团队)想要发送给自己团队告警,他们需要从头到尾设置 label、设置匹配其团队 labels 的路由树、把团队内的收件人信息配置到 AlertManager 的 receiver 里。

那如果你是监控团队,你用 AlertManager 做了个告警平台提供给外部团队甚至客户使用,每次都得这么搞会有“亿点点”麻烦。

该怎么办呢?🤔🤔🤔

解决方案

解决方案就是:

  • Label
  • AlertManager 通知模板

首先,直接在 Label 里提供相关的接收人信息,然后通过 AlertManager 的模板,将 receiver -> to 写上对应的模板即可。

具体演示如下:

方案演示

首先,是包含收件人信息 label 的 alerts,如下:

[
  {
    "labels": {
      "alertname": "<requiredAlertName>",
      "<labelname>": "<labelvalue>",
      "email_to": "foo@example.com,bar@example.com",
      ...
    },
    "annotations": {
      "<labelname>": "<labelvalue>",
    },
    "startsAt": "<rfc3339>",
    "endsAt": "<rfc3339>",
    "generatorURL": "<generator_url>"
  },
  ...
]

每个 alert 都提供 email_to 这样的 label。

然后,在 AlertManager 中,可以设置如下 routereceiver, 如下:

global:
  smtp_smarthost: 'localhost:25'
  smtp_from: 'smtp@example.com'
route:
  group_by: [email_to, alertname]
  receiver: customer_email
receivers:
  - name: customer_email
    email_configs:
      - to: '{{ .GroupLabels.email_to }}'
    headers:
      subject: 'Alert: {{ .GroupLabels.alertname }}'

注意,group_by 必须包括 email_to label,这样它才算 .GroupLabels. 下的一员。

当有 alerts 来时,如 "email_to": "foo@example.com,bar@example.com", 会 route 到 customer_email, 其收件人是 {{ .GroupLabels.email_to }}, 会被模板化为: foo@example.com,bar@example.com, 告警邮件自然就会发过去。

完成!🎉🎉🎉

本文由博客一文多发平台 OpenWrite 发布!

与Prometheus AlertManager 生产实践-直接根据 to_email label 发 alert 到对应邮箱相似的内容:

Prometheus AlertManager 生产实践-直接根据 to_email label 发 alert 到对应邮箱

概述 通过之前的文章 - Prometheus Alertmanager 生产配置趟过的坑总结, 我们已经知道 AlertManager 作为告警平台,是非常强大的,可以去重 (deduplicating),分组 (grouping),并将它们路由 (routing) 到正确的接收器 (receiv

Prometheus Alertmanager生产配置趟过的坑总结

简介 Alertmanager 处理由客户端应用程序(如 Prometheus server)发送的警报。它负责去重(deduplicating),分组(grouping),并将它们路由(routing)到正确的接收器(receiver)集成,如电子邮件,微信,或钉钉。它还负责处理警报的静默/屏蔽(

Prometheus+alertmanager实现告警的简单验证

# Prometheus+alertmanager实现告警的简单验证 ## 背景 ``` 学习源自: http://www.mydlq.club/article/126/ 上午没搞定, 中午睡不着,继续学习处理. 发现最恶心的有点事 alertmanager的 --cluster.listen-ad

[转帖]验证Prometheus alertmanager邮件发送

https://www.cnblogs.com/charlieroro/p/11009493.html 新环境上配置alertmanager时出现了“Client was not authenticated to send anonymous mail during MAIL FROM”错误,但老环

[转帖]alertmanager的使用

https://www.jianshu.com/p/654d59325550 一、Alertanager的安装 1、下载 下载altermanager 2、安装 # 不同的平台下载不同的安装包 wget https://github.com/prometheus/alertmanager/relea

[转帖]Alertmanager 部署配置

https://www.cnblogs.com/winstom/p/11940570.html 目录 前言 源码安装 配置 启动 配置prometheus监控Alertmanager 修改prometheus配置 重新加载配置文件 配置测试告警 修改prometheus配置 重新加载配置文件 测试触

使用Prometheus监控docker compose方式部署的ES

需求 收集 ES 的指标, 并进行展示和告警; 现状 ES 通过 docker compose 安装 所在环境的 K8S 集群有 Prometheus 和 AlertManager 及 Grafana 方案 复用现有的监控体系, 通过: Prometheus 监控 ES. 具体实现为: 采集端 el

使用Prometheus监控docker compose方式部署的ES

需求 收集 ES 的指标, 并进行展示和告警; 现状 ES 通过 docker compose 安装 所在环境的 K8S 集群有 Prometheus 和 AlertManager 及 Grafana 方案 复用现有的监控体系, 通过: Prometheus 监控 ES. 具体实现为: 采集端 el

[转帖]简单聊聊运维监控的其他用途

https://www.cnblogs.com/charlieroro/p/16434344.html 说到监控,一般都会聊到这三个基本维度:metrics、log和tracing,以及这几种常用的工具:Prometheus+grafana+alertmanager、ELK、jaeger。 监控通常

[转帖]部署Alertmanager

https://flashcat.cloud/docs/content/flashcat-monitor/prometheus/alert/manager-install/ Alertmanager和Prometheus Server一样均采用Golang实现,并且没有第三方依赖。一般来说我们可以通