作者没有四次元口袋的蓝胖日期2026-10-02标签Alertmanager, Docker, 监控体系Alertmanager报警与Docker部署监控的最后一公里是告警——数据采集得再好、面板做得再漂亮如果出了问题没人知道等于白搭。Alertmanager 是 Prometheus 生态的告警处理中枢负责将 Prometheus 评估产生的告警进行分组、去重、静默、抑制最终路由到邮件、钉钉、企业微信等通知渠道。另一方面Prometheus 监控体系包含多个组件Prometheus Server、node_exporter、Alertmanager、Grafana手动一个个部署既繁琐又不可复现。Docker Compose 提供了一键部署整套监控系统的方案一条命令即可启动所有服务。这篇笔记聚焦告警体系与部署实操从告警规则编写到通知渠道集成再到完整的 Docker Compose 部署方案。核心掌握Alertmanager告警规则编写、路由分组与通知渠道配置、抑制与静默机制、Docker Compose一键部署与验证。一、Alertmanager告警体系1.1 告警架构┌────────────┐ 告警规则 ┌──────────────┐ 转发告警 ┌──────────────┐ │ Prometheus │ ──────────────► │ Alertmanager │ ───────────► │ 邮件/钉钉/微信│ │ Server │ firing/resolved│ │ └──────────────┘ └────────────┘ └──────────────┘告警分两步Prometheus 评估告警规则满足条件 → 产生告警 → 发送给 AlertmanagerAlertmanager 处理告警分组grouping、去重deduplication、静默silencing、抑制inhibition、路由到通知渠道为什么不直接让 Prometheus 发通知因为生产环境的告警往往不是单条触发而是成百上千条同时触发如一台机器挂了CPU、内存、磁盘告警全来了。Alertmanager 负责将这些告警风暴收敛为一条有意义的通知。1.2 告警规则配置在 Prometheus 中定义告警规则# prometheus.yml 中添加规则文件rule_files:-rules/*.yml# rules/node_alerts.ymlgroups:-name:node_alertsrules:# CPU使用率超过80%持续5分钟-alert:HighCPUUsageexpr:100-(avg by(instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100)80for:5m# 持续5分钟才触发防止瞬时波动误报labels:severity:warning# 告警级别annotations:summary:CPU使用率过高description:{{ $labels.instance }} CPU使用率超过80%当前值: {{ $value | printf \%.1f\ }}%# 内存使用率超过90%-alert:HighMemoryUsageexpr:(1-node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 10090for:3mlabels:severity:criticalannotations:summary:内存使用率过高description:{{ $labels.instance }} 内存使用率超过90%当前值: {{ $value | printf \%.1f\ }}%# 磁盘使用率超过85%-alert:HighDiskUsageexpr:(1-node_filesystem_avail_bytes{fstype!~tmpfs|overlay}/ node_filesystem_size_bytes{fstype!~tmpfs|overlay}) * 10085for:5mlabels:severity:warningannotations:summary:磁盘空间不足description:{{ $labels.instance }} 磁盘 {{ $labels.mountpoint }} 使用率超过85%# 实例宕机-alert:InstanceDownexpr:up{jobnode} 0for:1mlabels:severity:criticalannotations:summary:实例宕机description:{{ $labels.instance }} 已离线超过1分钟1.3 告警规则核心字段字段说明alert告警名称如HighCPUUsageexprPromQL表达式结果为1firing或0正常for持续多久才触发避免瞬时波动误报labels附加标签用于路由和分级如 severity: critical/warningannotations附加信息支持模板变量$labels、$valuefor字段的重要性不加for的话瞬间超过阈值就会触发告警导致大量误报。生产环境至少设置1m~5m。例如 CPU 偶尔飙到 90% 是正常的如 GC、编译只有持续 5 分钟都高才说明有问题。告警级别设计critical需要立即处理。如实例宕机、内存使用率 90%、磁盘 95%。warning需要关注但不紧急。如 CPU 80%、磁盘 85%。info信息性通知。如部署变更通知。二、Alertmanager配置详解2.1 路由与分组# alertmanager.ymlglobal:resolve_timeout:5m# 告警恢复超时# 告警路由route:group_by:[alertname,instance]# 按告警名实例分组group_wait:30s# 同组告警等待30s合并发送group_interval:5m# 同组告警再次发送间隔repeat_interval:4h# 重复告警间隔同一告警4小时内不重复发receiver:default-receiver# 默认接收者routes:# critical级别告警 → 钉钉-match:severity:criticalreceiver:dingtalk-critical# warning级别告警 → 邮件-match:severity:warningreceiver:email-warning路由参数解读参数含义生产建议group_by告警分组维度[alertname, instance]按告警类型和实例分组group_wait同组告警等待时间30s给同组告警时间合并group_interval同组告警再次发送间隔5m避免频繁发送repeat_interval重复告警间隔4h防止值班人员被轰炸receiver默认接收者兜底的接收者分组Grouping的意义假设 10 台机器同时触发 CPU 告警如果不用 grouping你会收到 10 封邮件/10 条钉钉消息。启用 grouping 后这 10 条告警合并为一封通知一目了然。2.2 接收者与通知渠道# 接收者配置receivers:-name:default-receiveremail_configs:-to:adminexample.com-name:email-warningemail_configs:-to:ops-teamexample.comsend_resolved:true# 告警恢复时也发通知-name:dingtalk-criticalwebhook_configs:-url:http://dingtalk-adapter:8060/sendsend_resolved:true三、通知渠道集成3.1 邮件通知# alertmanager.yml - 邮件配置global:smtp_smarthost:smtp.qq.com:465smtp_from:alertexample.comsmtp_auth_username:alertexample.comsmtp_auth_password:your_app_password# QQ邮箱用授权码smtp_require_tls:falsereceivers:-name:emailemail_configs:-to:adminexample.comhtml:{{ template email.default.html . }}send_resolved:true配置要点smtp_auth_passwordQQ 邮箱/163 邮箱需要使用授权码而非登录密码。send_resolved: true告警恢复时也发送通知让值班人员知道问题已解决。smtp_require_tls: false465 端口使用 SSL 加密不需要 STARTTLS。3.2 钉钉通知# 方式1直接用钉钉 Webhook简单场景receivers:-name:dingtalkwebhook_configs:-url:https://oapi.dingtalk.com/robot/send?access_tokenYOUR_TOKENhttp_config:tls_config:insecure_skip_verify:true# 方式2通过 webhook dingtalk adapter推荐支持 Markdown 格式# 需要一个中间服务将 Alertmanager 格式转为钉钉消息格式钉钉 Webhook 配置步骤创建钉钉群 → 群设置 → 智能群助手 → 添加机器人 → 自定义机器人安全设置选择自定义关键词或加签获取 Webhook URL 和 access_token在 Alertmanager 中配置 webhook_configs3.3 企业微信通知# 企业微信机器人 Webhookreceivers:-name:wechatwebhook_configs:-url:https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyYOUR_KEY3.4 告警收敛三大机制Alertmanager 的核心价值在于告警收敛包含三个机制机制作用场景分组Grouping同类告警合并为一条通知10台机器同时CPU告警 → 一封邮件抑制Inhibition高级别告警触发时抑制相关低级别告警机器宕机critical→ 不再发CPU/内存的warning静默Silence维护期间屏蔽指定条件的告警计划维护窗口期间不收告警抑制配置示例# alertmanager.ymlinhibit_rules:-source_match:# 源告警高级别severity:criticaltarget_match:# 目标告警低级别severity:warningequal:[instance]# 同实例才抑制效果当某台机器的告警级别为 critical 时该机器上所有 warning 级别的告警都会被抑制不会发送通知。比如机器宕机了就不会再收到这台机器的 CPU 告警和内存告警。四、Docker Compose一键部署4.1 完整 docker-compose.yml一条命令启动整套监控系统# docker-compose.ymlversion:3.8services:# Prometheus Serverprometheus:image:prom/prometheus:latestcontainer_name:prometheusports:-9090:9090volumes:-./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml-./prometheus/rules:/etc/prometheus/rules-prometheus_data:/prometheuscommand:---config.file/etc/prometheus/prometheus.yml---storage.tsdb.retention.time15d# 数据保留15天---storage.tsdb.path/prometheus---web.enable-lifecycle# 支持热重载 APIrestart:unless-stopped# node_exporter - 主机监控node_exporter:image:prom/node-exporter:latestcontainer_name:node_exporterports:-9100:9100volumes:-/proc:/host/proc:ro-/sys:/host/sys:ro-/:/rootfs:rocommand:---path.procfs/host/proc---path.sysfs/host/sys---path.rootfs/rootfs---collector.filesystem.mount-points-exclude^/(sys|proc|dev|host|container)($$|/)restart:unless-stopped# Alertmanageralertmanager:image:prom/alertmanager:latestcontainer_name:alertmanagerports:-9093:9093volumes:-./alertmanager/alertmanager.yml:/etc/alertmanager/alertmanager.ymlrestart:unless-stopped# Grafanagrafana:image:grafana/grafana:latestcontainer_name:grafanaports:-3000:3000volumes:-grafana_data:/var/lib/grafana-./grafana/provisioning:/etc/grafana/provisioningenvironment:-GF_SECURITY_ADMIN_PASSWORDadmin123-GF_USERS_ALLOW_SIGN_UPfalserestart:unless-stoppeddepends_on:-prometheusvolumes:prometheus_data:grafana_data:4.2 目录结构monitoring/ ├── docker-compose.yml ├── prometheus/ │ ├── prometheus.yml │ └── rules/ │ └── node_alerts.yml ├── alertmanager/ │ └── alertmanager.yml └── grafana/ └── provisioning/ ├── datasources/ │ └── prometheus.yml └── dashboards/ └── dashboards.yml目录结构说明prometheus/prometheus.ymlPrometheus 主配置文件定义采集目标和全局参数。prometheus/rules/告警规则文件目录支持多个.yml规则文件。alertmanager/alertmanager.ymlAlertmanager 配置定义路由和接收者。grafana/provisioning/datasources/Grafana 数据源自动配置。grafana/provisioning/dashboards/Grafana Dashboard 自动配置。4.3 启动与验证# 启动所有服务dockercompose up-d# 查看服务状态dockercomposeps# 验证各组件# 1. Prometheus: http://localhost:9090 → Status → Targets → 所有target为UP# 2. Alertmanager: http://localhost:9093# 3. Grafana: http://localhost:3000 → admin / admin123# 4. node_exporter: curl http://localhost:9100/metrics# 热重载配置修改prometheus.yml后无需重启curl-XPOST http://localhost:9090/-/reload# 查看日志dockercompose logs-fprometheusdockercompose logs-falertmanager4.4 关键启动参数解读参数说明生产建议--web.enable-lifecycle启用热重载 API必开修改配置后curl -X POST :9090/-/reload即可无需重启--storage.tsdb.retention.time15d数据保留时间生产 15~30 天太长占磁盘太短看不到历史趋势--storage.tsdb.pathTSDB 存储路径容器内默认/prometheusVolume 持久化数据不随容器重建丢失prometheus_data和grafana_data必须持久化五、常见面试注意点for字段的重要性不加for的话瞬间超过阈值就会触发告警导致大量误报。生产环境至少1m~5m。告警收敛groupingAlertmanager 会将同组告警合并为一封邮件发送避免告警风暴。比如 10 台机器同时 CPU 告警合并后只收到一封邮件。抑制inhibition当 critical 告警触发时可以抑制相关的 warning 告警。比如机器宕机了critical就不需要再发 CPU/内存的 warning 了。静默silence维护期间可以静默某类告警避免收到大量无关告警。repeat_interval控制告警重复发送频率。设为 4h 表示同一告警每 4 小时提醒一次防止值班人员被轰炸。--web.enable-lifecycle开启后支持热重载配置不用重启 Prometheus。Volume 持久化容器重建数据不丢失的关键。配置挂载路径Prometheus 配置文件必须挂载到/etc/prometheus/目录下。️ 思维导图速览Alertmanager 报警与 Docker 部署 ├── Alertmanager 告警体系 │ ├── 告警架构Prometheus评估规则 → Alertmanager处理 → 通知渠道 │ ├── 告警规则 │ │ ├── exprPromQL表达式 │ │ ├── for持续时间防误报至少1m~5m │ │ ├── labels告警级别critical/warning/info │ │ └── annotations通知内容模板 │ │ │ ├── 路由配置 │ │ ├── group_by分组维度 │ │ ├── group_wait等待合并时间 │ │ ├── group_interval再次发送间隔 │ │ ├── repeat_interval重复告警间隔 │ │ └── routes按 severity 路由到不同接收者 │ │ │ ├── 通知渠道 │ │ ├── 邮件SMTP配置 send_resolved │ │ ├── 钉钉Webhook / dingtalk-adapter │ │ └── 企业微信Webhook │ │ │ └── 收敛三大机制 │ ├── 分组同类告警合并通知 │ ├── 抑制critical抑制warning │ └── 静默维护期间屏蔽告警 │ └── Docker Compose 部署 ├── 目录结构 │ ├── prometheus/prometheus.yml rules/ │ ├── alertmanager/alertmanager.yml │ └── grafana/provisioning/ ├── 启动验证 │ ├── docker compose up -d │ ├── 各端口9090/9100/9093/3000 │ └── 热重载curl -X POST :9090/-/reload └── 关键参数 ├── --web.enable-lifecycle热重载 ├── --storage.tsdb.retention.time数据保留 └── Volume持久化数据不丢失 写在最后学习建议一定要动手部署一遍用 Docker Compose 把整套系统跑起来导入 Dashboard 1860触发几条告警看看实际效果。纸上得来终觉浅。告警规则要合理不要设太多阈值太低的告警否则告警风暴 没有告警。生产环境告警要分级warning/critical、有收敛、有抑制。理解三大收敛机制分组、抑制、静默是 Alertmanager 的核心能力面试和实际工作中都经常提到。熟悉 Docker Compose这是现代部署的标准方式。理解 volume 挂载、端口映射、服务依赖等概念不仅是监控所有 Docker 项目都用得到。面试高频问题速答QAlertmanager 的告警收敛机制是什么三个核心机制① 分组Grouping将同类告警合并为一条通知发送避免告警风暴。如10台机器同时CPU告警合并为一封邮件。② 抑制Inhibition当高级别告警触发时抑制相关的低级别告警。如机器宕机后不再发CPU/内存告警。③ 静默Silence在维护窗口期间临时屏蔽指定条件的告警通知。Q告警规则中for字段的作用是什么for指定告警条件必须持续多久才会真正触发。如果不设for瞬间超过阈值就会告警导致大量误报如 GC、编译等正常波动。生产环境通常设为 1m~5m确保只有持续异常才告警。QDocker Compose 中--web.enable-lifecycle的作用开启后支持通过 API 热重载 Prometheus 配置curl -X POST http://localhost:9090/-/reload。修改 prometheus.yml 或告警规则后无需重启服务即可生效避免监控中断。