Prometheus+Grafana知识梳理(3)

作者：没有四次元口袋的蓝胖
日期：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│ │ └──────────────┘ └────────────┘ └──────────────┘

告警分两步：

1. Prometheus 评估告警规则：满足条件 → 产生告警 → 发送给 Alertmanager
2. Alertmanager 处理告警：分组（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{mode="idle"}[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) * 100>90for: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"}) * 100>85for:5mlabels:severity:warningannotations:summary:"磁盘空间不足"description:"{{ $labels.instance }} 磁盘 {{ $labels.mountpoint }} 使用率超过85%"# 实例宕机-alert:InstanceDownexpr:up{job="node"}== 0for:1mlabels:severity:criticalannotations:summary:"实例宕机"description:"{{ $labels.instance }} 已离线超过1分钟"

1.3 告警规则核心字段

for字段的重要性：不加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'

路由参数解读：

分组（Grouping）的意义：假设 10 台机器同时触发 CPU 告警，如果不用 grouping，你会收到 10 封邮件/10 条钉钉消息。启用 grouping 后，这 10 条告警合并为一封通知，一目了然。

2.2 接收者与通知渠道

# 接收者配置receivers:-name:'default-receiver'email_configs:-to:'admin@example.com'-name:'email-warning'email_configs:-to:'ops-team@example.com'send_resolved:true# 告警恢复时也发通知-name:'dingtalk-critical'webhook_configs:-url:'http://dingtalk-adapter:8060/send'send_resolved:true

三、通知渠道集成

3.1 邮件通知

# alertmanager.yml - 邮件配置global:smtp_smarthost:'smtp.qq.com:465'smtp_from:'alert@example.com'smtp_auth_username:'alert@example.com'smtp_auth_password:'your_app_password'# QQ邮箱用授权码smtp_require_tls:falsereceivers:-name:'email'email_configs:-to:'admin@example.com'html:'{{ template "email.default.html" . }}'send_resolved:true

配置要点：

• smtp_auth_password：QQ 邮箱/163 邮箱需要使用授权码而非登录密码。
• send_resolved: true：告警恢复时也发送通知，让值班人员知道问题已解决。
• smtp_require_tls: false：465 端口使用 SSL 加密，不需要 STARTTLS。

3.2 钉钉通知

# 方式1：直接用钉钉 Webhook（简单场景）receivers:-name:'dingtalk'webhook_configs:-url:'https://oapi.dingtalk.com/robot/send?access_token=YOUR_TOKEN'http_config:tls_config:insecure_skip_verify:true# 方式2：通过 webhook dingtalk adapter（推荐，支持 Markdown 格式）# 需要一个中间服务将 Alertmanager 格式转为钉钉消息格式

钉钉 Webhook 配置步骤：

1. 创建钉钉群 → 群设置 → 智能群助手 → 添加机器人 → 自定义机器人
2. 安全设置选择"自定义关键词"或"加签"
3. 获取 Webhook URL 和 access_token
4. 在 Alertmanager 中配置 webhook_configs

3.3 企业微信通知

# 企业微信机器人 Webhookreceivers:-name:'wechat'webhook_configs:-url:'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=YOUR_KEY'

3.4 告警收敛三大机制

Alertmanager 的核心价值在于告警收敛，包含三个机制：

抑制配置示例：

# alertmanager.ymlinhibit_rules:-source_match:# 源告警（高级别）severity:'critical'target_match:# 目标告警（低级别）severity:'warning'equal:['instance']# 同实例才抑制

效果：当某台机器的告警级别为 critical 时，该机器上所有 warning 级别的告警都会被抑制，不会发送通知。比如机器宕机了，就不会再收到这台机器的 CPU 告警和内存告警。

四、Docker Compose一键部署

4.1 完整 docker-compose.yml

一条命令启动整套监控系统：

# docker-compose.ymlversion:'3.8'services:# Prometheus Serverprometheus:image:prom/prometheus:latestcontainer_name:prometheusports:-"9090:9090"volumes:-./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml-./prometheus/rules:/etc/prometheus/rules-prometheus_data:/prometheuscommand:-'--config.file=/etc/prometheus/prometheus.yml'-'--storage.tsdb.retention.time=15d'# 数据保留15天-'--storage.tsdb.path=/prometheus'-'--web.enable-lifecycle'# 支持热重载 APIrestart:unless-stopped# node_exporter - 主机监控node_exporter:image:prom/node-exporter:latestcontainer_name:node_exporterports:-"9100:9100"volumes:-/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:9093"volumes:-./alertmanager/alertmanager.yml:/etc/alertmanager/alertmanager.ymlrestart:unless-stopped# Grafanagrafana:image:grafana/grafana:latestcontainer_name:grafanaports:-"3000:3000"volumes:-grafana_data:/var/lib/grafana-./grafana/provisioning:/etc/grafana/provisioningenvironment:-GF_SECURITY_ADMIN_PASSWORD=admin123-GF_USERS_ALLOW_SIGN_UP=falserestart: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.yml：Prometheus 主配置文件，定义采集目标和全局参数。
• prometheus/rules/：告警规则文件目录，支持多个.yml规则文件。
• alertmanager/alertmanager.yml：Alertmanager 配置，定义路由和接收者。
• 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-falertmanager

4.4 关键启动参数解读

五、常见面试注意点

• for字段的重要性：不加for的话，瞬间超过阈值就会触发告警，导致大量误报。生产环境至少1m~5m。
• 告警收敛（grouping）：Alertmanager 会将同组告警合并为一封邮件发送，避免告警风暴。比如 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处理 → 通知渠道 │ ├── 告警规则 │ │ ├── expr：PromQL表达式 │ │ ├── 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持久化（数据不丢失）

📝 写在最后

学习建议

1. 一定要动手部署一遍：用 Docker Compose 把整套系统跑起来，导入 Dashboard 1860，触发几条告警看看实际效果。纸上得来终觉浅。
2. 告警规则要合理：不要设太多阈值太低的告警，否则告警风暴 = 没有告警。生产环境告警要分级（warning/critical）、有收敛、有抑制。
3. 理解三大收敛机制：分组、抑制、静默是 Alertmanager 的核心能力，面试和实际工作中都经常提到。
4. 熟悉 Docker Compose：这是现代部署的标准方式。理解 volume 挂载、端口映射、服务依赖等概念，不仅是监控，所有 Docker 项目都用得到。

面试高频问题速答

Q：Alertmanager 的告警收敛机制是什么？

三个核心机制：① 分组（Grouping）：将同类告警合并为一条通知发送，避免告警风暴。如10台机器同时CPU告警，合并为一封邮件。② 抑制（Inhibition）：当高级别告警触发时，抑制相关的低级别告警。如机器宕机后不再发CPU/内存告警。③ 静默（Silence）：在维护窗口期间，临时屏蔽指定条件的告警通知。

Q：告警规则中for字段的作用是什么？

for指定告警条件必须持续多久才会真正触发。如果不设for，瞬间超过阈值就会告警，导致大量误报（如 GC、编译等正常波动）。生产环境通常设为 1m~5m，确保只有持续异常才告警。

Q：Docker Compose 中--web.enable-lifecycle的作用？

开启后支持通过 API 热重载 Prometheus 配置：curl -X POST http://localhost:9090/-/reload。修改 prometheus.yml 或告警规则后无需重启服务即可生效，避免监控中断。