【Prometheus Operator 的 AlertmanagerConfig 邮件告警配置部署】

原创 于 2026-06-18 15:44:46 发布 · 116 阅读 · 0 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
GEO检测
标签
#prometheus

提示：本文原创作品，良心制作，干货为主，简洁清晰，一看就会

文章目录

前言

在云原生监控体系中，Prometheus 负责采集指标与触发告警，而 Alertmanager 则承担告警路由、分组与通知分发的核心职责。然而，原生 Alertmanager 的配置方式较为复杂，尤其在多租户场景下，维护单一的全局配置文件往往带来安全风险与运维负担。Kubernetes 生态中的 AlertmanagerConfig 自定义资源（CRD）正是为解决这一问题而生——它允许用户在命名空间级别独立声明告警接收器、路由规则与抑制策略，实现细粒度的权限隔离与声明式管理


一、AlertmanagerConfig简介

AlertmanagerConfig 是Prometheus Operator提供的命名空间级 CRD 自定义资源，用来替代手动写 Secret 维护 alertmanager.yml 告警配置文件

核心作用

  1. 配置告警路由、分组、抑制规则、告警接收渠道（邮件、钉钉、企业微信、Webhook等）
  2. 多租户/多业务隔离：不同命名空间、不同业务可以各自写独立告警配置，互不干扰
  3. 通过标签选择器绑定到指定 Alertmanager 实例，Operator 自动把所有匹配的配置合并成最终的 alertmanager.yml 并热加载，不用重启 Alertmanager

二、邮箱配置

2.1 修改alertmanager-alertmanager.yaml

root@k8s-master1:~# cd kube-prometheus/manifests/
root@k8s-master1:~/kube-prometheus/manifests# vim alertmanager-alertmanager.yaml

在这里插入图片描述

root@k8s-master1:~/kube-prometheus/manifests# kubectl replace alertmanager-alertmanager.yaml

2.2 添加alertmanagerconfig.yaml

root@k8s-master1:~/kube-prometheus/manifests# vim email-alertmanagerconfig.yaml 
apiVersion: monitoring.coreos.com/v1alpha1
kind: AlertmanagerConfig
metadata:
  name: email-config
  namespace: monitoring
  # 标签必须被Alertmanager CR的alertmanagerConfigSelector匹配
  labels:
    alertmanagerConfig: email
# 告警配置规则主体
spec:
  route:
    # 按照告警级别severity进行分组，相同级别告警合并推送
    groupBy: ['severity']
    # 首次等待时间：收到告警后等待30秒，收集同组多条告警再一次发送
    groupWait: 30s
    # 同组告警发送间隔：上一组告警发送后，5分钟内新触发的同组告警不再单独推送
    groupInterval: 5m
    # 重复告警推送间隔：同一告警持续未恢复，每12小时重复发送一次告警通知
    repeatInterval: 12h
    # 默认告警接收人
    receiver: 'Default'
    # 子路由规则列表，用于对不同条件的告警做路由分发
    routes:
    # 第一条子路由规则
    - matchers:
      - matchType: =
        name: severity
        value: critical
    #- matchers:
     #- matchType: =
      # name: severity
      # value: warning  还可有warning分组或者其他分组
      receiver: Default
 # 告警接收器配置
  receivers:
  # 第一个接收器
  - name: Default
    emailConfigs:
    - to: 'bestluqing@163.com'  # 告警接收邮箱
      from: 'bestluqing@163.com'  # 告警发送方
      smarthost: 'smtp.163.com:465'  # 163邮箱SMTP服务+端口
      authUsername: 'bestluqing@163.com'  # SMTP服务认证用户名
      authPassword:
        # 存储SMTP邮箱授权码
        name: smtp-secret
        key: password
      sendResolved: true  # 开启告警恢复通知
      requireTLS: false   # 关闭强制TLS校验
  # 第二个接收器，空接收器，可用于丢弃不需要的告警
  - name: 'null-receiver'

root@k8s-master1:~/kube-prometheus/manifests# kubectl apply -f email-alertmanagerconfig.yaml

登录alertmanager页面，可以看到config已经更新了
在这里插入图片描述


2.3 详解config

我们在Alertmanager页面查看配置时会发现，config展示的完整配置和我们编写的email-alertmanagerconfig.yaml并不一致，配置中多出了大量从未手动定义过的参数
出现该现象的核心原因是：我们自定义的email-alertmanagerconfig.yaml仅属于用户侧的片段式配置，并非Alertmanager最终生效的完整配置文件

Alertmanager最终加载运行的完整配置，由三部分内容合并渲染生成：Prometheus Operator内置的全局默认配置 + Alertmanager CR自带的默认路由模板 + 我们编写的AlertmanagerConfig自定义配置

下面我们逐一梳理这些自动生成的默认配置项，这部分内容至关重要，直接决定了告警能否正常触发并成功推送

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述


2.4 添加secret.yaml

此前配置的email-alertmanagerconfig.yaml中引用了Secret用于存放邮箱授权码，当前该Secret尚未创建，接下来我们完成Secret的创建操作

登录163邮箱，选择“设置”，开启SMTP服务，其他邮箱类似操作
在这里插入图片描述

root@k8s-master1:~/kube-prometheus/manifests# vim email-secret.yaml 
apiVersion: v1
kind: Secret
metadata:
  name: smtp-secret
  namespace: monitoring
type: Opaque
stringData:
  password: 授权码
root@k8s-master1:~/kube-prometheus/manifests# kubectl apply -f email-secret.yaml

2.5 添加rule.yaml

我们已经完成告警发送渠道配置，编写了email-alertmanagerconfig.yaml告警接收器配置文件
我目前有一套mysql高可用集群，接下来将以mysql集群为例演示如何配置对应的 Prometheus 告警触发规则

root@k8s-master1:~/kube-prometheus/manifests# kubectl get pod
NAME                 READY   STATUS    RESTARTS       AGE
mysql-rep-master-0   2/2     Running   6 (127m ago)   44h
mysql-rep-slave-0    2/2     Running   4 (127m ago)   44h
mysql-rep-slave-1    2/2     Running   4 (127m ago)   44h

我们可以先查看 MySQL 集群已采集的监控指标，包括 MySQL 运行状态、SQL 线程与 IO 线程数量、数据库连接数等核心指标，再基于这些指标配置对应的告警触发规则

mysql运行状态
在这里插入图片描述

sql线程数
在这里插入图片描述

io线程数
在这里插入图片描述

root@k8s-master1:~/kube-prometheus/manifests# vim mysql-rule.yaml 
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  labels:
    app: kube-prometheus-stack
    role: alerting-rules
    prometheus: kube-prometheus-stack-prometheus
  name: prometheus-mysql-alerts
  namespace: monitoring  # 请替换为你的Prometheus所在namespace
spec:
  groups:
  - name: mysql
    rules:
    # ==================== 1. 集群可用性告警 ====================
    - alert: MySQLDown
      expr: mysql_up == 0
      for: 1m
      labels:
        severity: critical
        #  mysql宕机告警通过AlertmanagerConfig配置的邮箱接收，那么必须添加这个标签，不然匹配不到父路由
        namespace: monitoring
      annotations:
        summary: "MySQL实例 {{ $labels.instance }} 已宕机"
        description: "Prometheus 无法连接到 {{ $labels.pod }} 上的 MySQL 实例。这通常意味着 mysqld 进程已停止或 exporter 无法连接。"
    # ==================== 2. 主从复制告警 ====================
    # 2.1 复制延迟过高
    - alert: MySQLReplicationLagHigh
      expr: mysql_slave_status_seconds_behind_source > 30
      for: 2m
      labels:
        severity: warning
        #  mysql宕机告警通过AlertmanagerConfig配置的邮箱接收，那么必须添加这个标签，不然匹配不到父路由
        namespace: monitoring
      annotations:
        summary: "MySQL 复制延迟较高"
        description: "从库 {{ $labels.pod }} (实例: {{ $labels.instance }}) 复制落后主库 {{ $value }} 秒。请检查网络延迟或主库写入负载。"
    # 2.2 复制线程停止
    - alert: MySQLReplicationSQLThreadDown
      expr: mysql_slave_status_replica_sql_running == 0
      for: 1m
      labels:
        severity: critical
        #  mysql宕机告警通过AlertmanagerConfig配置的邮箱接收，那么必须添加这个标签，不然匹配不到父路由
        namespace: monitoring
      annotations:
        summary: "MySQL 复制 SQL 线程停止"
        description: "从库 {{ $labels.pod }} 的 SQL 线程未运行，数据同步已中断。请检查 relay log 是否有损坏或错误。"
    - alert: MySQLReplicationIOThreadDown
      expr: mysql_slave_status_replica_io_running == 0
      for: 1m
      labels:
        severity: critical
        #  mysql宕机告警通过AlertmanagerConfig配置的邮箱接收，那么必须添加这个标签，不然匹配不到父路由
        namespace: monitoring
      annotations:
        summary: "MySQL 复制 IO 线程停止"
        description: "从库 {{ $labels.pod }} 的 IO 线程未运行，无法从主库获取二进制日志，网络连接可能已断开。"
    # ==================== 3. 实例健康告警 ====================
    - alert: MySQLTooManyConnections
      expr: >-
        mysql_global_status_threads_connected
        / mysql_global_variables_max_connections > 0.8
      for: 5m
      labels:
        severity: warning
        #  mysql宕机告警通过AlertmanagerConfig配置的邮箱接收，那么必须添加这个标签，不然匹配不到父路由
        namespace: monitoring
      annotations:
        summary: "MySQL 连接数超过阈值"
        description: "实例 {{ $labels.pod }} 当前连接数使用率已超过 80%，请排查慢查询或应用连接池配置。"
    - alert: MySQLInnoDBBufferPoolLowFree
      expr: >-
        (mysql_global_variables_innodb_buffer_pool_size - mysql_global_status_innodb_buffer_pool_bytes_data) / mysql_global_variables_innodb_buffer_pool_size < 0.05
      for: 5m
      labels:
        severity: warning
        #  mysql宕机告警通过AlertmanagerConfig配置的邮箱接收，那么必须添加这个标签，不然匹配不到父路由
        namespace: monitoring
      annotations:
        summary: "MySQL InnoDB Buffer Pool 可用空间不足"
        description: "实例 {{ $labels.pod }} InnoDB Buffer Pool 可用空间低于 5%，磁盘 I/O 可能会显著增加，建议扩容内存。"

2.5 测试告警

告警通知

进入mysql slave pod内部，关闭sql线程，测试一下能不能收到告警

root@k8s-master1:~/kube-prometheus/manifests# kubectl exec -it mysql-rep-slave-0 /bin/bash
I have no name!@mysql-rep-slave-0:/$ mysql -uroot -p'Root@12345'
mysql> STOP REPLICA SQL_THREAD;

登录Prometheus可以看到sql线程数据变为0
在这里插入图片描述

在这里插入图片描述

登录163邮箱，可以看到收到了告警消息

在这里插入图片描述


恢复通知

进入mysql slave pod内部，启动sql线程，测试一下能不能收到恢复消息

root@k8s-master1:~/kube-prometheus/manifests# kubectl exec -it mysql-rep-slave-0 /bin/bash
I have no name!@mysql-rep-slave-0:/$ mysql -uroot -p'Root@12345'
mysql> START REPLICA SQL_THREAD;

登录Prometheus可以看到sql线程数为1
在这里插入图片描述

在这里插入图片描述

登录163邮箱可以看到收到了恢复邮件
在这里插入图片描述

到此，邮件告警配置就到此结束了！


注：
文中若有疏漏，欢迎大家指正赐教。
本文为100%原创，转载请务必标注原创作者，尊重劳动成果。
求赞、求关注、求评论！你的支持是我更新的最大动力，评论区等你～

prometheus告警处理
wq1205750492的博客
05-11 8106
文章目录一.告警简介1.工作流程2.告警生命周期3.告警等级4.通知方式二. AlertManager组件1.特性1.1 分组1.2. 抑制1.3.沉默2.AlertManager安装2.1 下载安装2.2 创建service脚本2.3 检查配置文件2.4 启动程序3.自定义告警规则4. 自定义通知模板三.配置告警信息1. Prometheus配置告警规则1. 1 配置alertmanager地址1.2 添加告警规则2.Alertmanager配置告警机制wechat 告警通知 一.告警简介 1.工作流程
Prometheus告警处理
GGB_GG的博客
01-19 3974
告警能力在Prometheus的架构中被划分成两个独立的部分。如下所示，通过在Prometheus中定义AlertRule（告警规则），Prometheus会周期性的对告警规则进行计算，如果满足告警触发条件就会向Alertmanager发送告警信息。Prometheus告警处理告警名称：用户需要为告警规则命名，当然对于命名而言，需要能够直接表达出该告警的主要内容告警规则：告警规则实际上主要由PromQL进行定义，其实际意义是当表达式（PromQL）查询结果持续多长时间（During）后出发告警。
【Prometheus】Alertmanager配置钉钉告警
热门推荐
liu_chen_yang的博客
03-07 1万+
本文介绍了部署Alertmanager及钉钉告警服务的详细步骤。首先提供了二进制和k8s两种部署Alertmanager的方式。随后详细讲解了钉钉告警服务的配置过程，包括下载prometheus-webhook-dingtalk组件、创建钉钉机器人、配置dingtalk服务等关键环节。文章还包含服务启动测试、Alertmanager对接钉钉告警的配置方法，并给出了完整的配置文件示例。通过本文指导，读者可以快速实现Prometheus监控系统与钉钉告警的集成。
Prometheus 告警
escaping的博客
10-22 1113
前几篇文章讲了Prometheus的监控，这一篇文章，讲通过监控指标触发告警常用的告警方式有发邮件、调用指定接口(webhook) 等。本文讲解webhook方式，完成这个示例需要准备4个组件：prometheus、node_exporter、alertmanagers、接受webhook调用的web服务。
prometheus的告警处理机制
weixin_46689397的博客
12-23 1720
Prometheus 的告警功能基于PromQL查询语言，并通过配置告警规则来指定何时触发告警。告警规则（Alerting Rules）：用于定义何时触发告警。：用于处理告警并将其发送到指定的通知渠道（如 Slack、邮件、PagerDuty 等）。告警规则：使用expr定义触发告警的 PromQL 查询，并使用alert定义告警的名称和条件。：处理和分发告警，支持通过多种渠道（如 Slack、邮件等）通知。：查看和管理活动告警。
告警疲劳？Prometheus + Alertmanager 如何让真正重要的告警才能叫醒你
从事移动开发八年，csdn博客专家，阿里云特邀专家，华为云云享专家，高级网络信息安全工程师，大数据工程师（高级），python技术开发（高级），HarmonyOS 应用开发者高级认证，现在某学校任教。
04-09 1万+
告警这条链路上，最容易出问题的环节不是监控系统本身，而是"告警太多"。你有没有经历过这些：CPU 偶尔抖了一下，告警进群了；凌晨三点业务低峰期某个指标短暂飘高，电话响了；一个服务出问题，同一个故障原因触发了七八条告警，手机震了一晚上。最后运维人员的反应是什么？“算了，反正多半是误报，先睡吧。”——直到真有问题被漏掉了。Prometheus 负责采集和评估指标，这部分大多数团队都配了。但 Alertmanager 这个角色，往往被当成"可选配件"而不是核心组件来对待。
Prometheus监控平台Alertmanager配置告警
Map的博客
08-21 1万+
1. 前言 接上一篇Prometheus+Grafana监控部署，环境已经安装完成，本篇进行学习使用Alertmanager告警配置。 2. 告警概述 官方文档 Alertmanager是一个独立的告警模块，接收Prometheus等客户端发来的警报，之后通过分组、删除重复等处理，并将它们通过路由发送给正确的接收器。 Prometheus的警报分为两个部分。Prometheus服务器中的警报规则将警报发送到Alertmanager。该Alertmanager 然后管理这些警报，包括沉默，抑制，聚集
Prometheus 监控告警配置
IoTHub - 物联网开源技术社区
03-14 3179
Prometheus 监控告警配置，邮件通知、钉钉通知、自定义模版，常用软件报警规则配置，包括：linux、docker、nginx、postgresql、mysql、rabbitmq 等。
Prometheus 监控指标采集
Korbin的博客
08-13 4538
在现代分布式系统和云原生环境中，为了确保复杂的分布式系统和服务的高可用性、可靠性和性能，通常采用实时可视化监控和分析，实现故障快速响应、资源优化和安全保障，从而提升用户满意度和运营效率。在目前主流的解决方案中，Prometheus和Grafana是两个使用 Go 开发的强大开源工具，通常一起使用来实现全面的监控和可视化系统。其中Prometheus负责采集和存储监控对象的时序数据。
几百个免费 AI 模型配额，一键接入本地项目。| Hundreds of free AI model quotas, one-c.zip
06-17
几百个免费 AI 模型配额，一键接入本地项目。| Hundreds of free AI model quotas, one-click access to local projects.
Delphi 13.1控件之unidac-12.0.1-d28pro.exe
最新发布
06-17
Delphi 13.1控件之unidac_12.0.1_d28pro.exe
多功能四轮小车SolidWorks三维.rar
06-17
多功能四轮小车SolidWorks三维.rar
PYexe python代码可视化打包成exe的工具软件
06-17
python代码可视化打包成exe的工具软件，可以轻松打包exe
二级减速器图纸（CAD).rar
06-17
二级减速器图纸（CAD).rar
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

成为你的宁宁

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值