【技术底稿 06】37 岁老码农，Prometheus 告警终于跑通！一次踩坑到底的邮件通知实战

背景与目标这台 HP 服务器的个人 DevOps 平台已经搭了大半监控底座是必须先稳的环节。我用 Docker Compose 部署了 Prometheus Grafana 监控体系node_exporter 探针、告警规则全都配好本以为顺风顺水结果一关探针就傻眼告警在页面亮着日志也在刷就是收不到邮件。于是干脆沉下心从「从零安装部署」到「全链路踩坑排查」把整条链路从头捋一遍目标很简单关掉探针就报警、恢复服务就通知邮件稳稳收到。️ 第一步从零搭建 Prometheus Alertmanager 监控环境1. 环境准备宿主机Ubuntu 22.04已安装 Docker Docker Compose项目目录~/myapp/project/01-monitor核心组件Prometheus 3.10.0、Alertmanager、node_exporter2. 核心配置文件编写1docker-compose.yml一键编排所有服务yamlversion: 3.8 networks: monitor-net: driver: bridge services: prometheus: image: prom/prometheus:v3.10.0 container_name: prometheus volumes: - ./prometheus:/etc/prometheus - prometheus_data:/prometheus command: - --config.file/etc/prometheus/prometheus.yml - --storage.tsdb.path/prometheus - --web.enable-lifecycle ports: - 9090:9090 networks: - monitor-net restart: unless-stopped alertmanager: image: prom/alertmanager:latest container_name: alertmanager volumes: - ./alertmanager:/etc/alertmanager command: - --config.file/etc/alertmanager/alertmanager.yml ports: - 9093:9093 networks: - monitor-net restart: unless-stopped node_exporter: image: prom/node-exporter:latest container_name: node_exporter ports: - 9100:9100 networks: - monitor-net restart: unless-stopped volumes: prometheus_data:2prometheus/prometheus.ymlPrometheus 主配置yamlglobal: scrape_interval: 15s evaluation_interval: 15s alerting: alertmanagers: - static_configs: - targets: - alertmanager:9093 # 服务名通信无需硬编码IP rule_files: - /etc/prometheus/alerts.yml # 加载告警规则 scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090] - job_name: node_exporter static_configs: - targets: [node_exporter:9100]3prometheus/alerts.yml核心告警规则yamlgroups: - name: host_rules rules: - alert: 服务器宕机 expr: up 0 for: 30s # 持续30秒异常才触发避免误报 labels: severity: critical annotations: summary: 实例宕机 {{ $labels.instance }} description: 监控不到该机器4alertmanager/alertmanager.yml最终生效版踩坑后修正yamlglobal: resolve_timeout: 5m # QQ邮箱正确配置587端口 STARTTLS smtp_smarthost: smtp.qq.com:587 smtp_from: 111116091qq.com smtp_auth_username: 1111091qq.com smtp_auth_password: xxxxxx # QQ邮箱授权码非登录密码 smtp_require_tls: true route: group_by: [alertname] group_wait: 5s # 组内告警快速通知 group_interval: 10s # 重复告警间隔 repeat_interval: 1m # 告警重复发送间隔 receiver: email-only receivers: - name: email-only email_configs: - to: 91116091qq.com,142217qq.com send_resolved: true # 告警恢复时发送通知 templates: - /etc/alertmanager/templates/*.tmpl3. 一键启动所有服务bash运行# 进入项目目录 cd ~/myapp/project/01-monitor # 后台启动所有服务 docker-compose up -d # 验证服务状态确保全部正常运行 docker-compose ps️ 第二步核心问题排查 —— 告警链路通但通知发不出来安装完本以为万事大吉结果手动停止 node_exporter 触发告警却始终收不到邮件前后踩了好几个典型坑服务名解析正常却被 wget 错误提示带偏死磕网络QQ 邮箱 SMTP 端口与 TLS 模式不匹配底层直接发不出去抑制规则默默吞掉告警日志有但收件箱没有企业微信 WebHook 格式不兼容多渠道反而互相干扰全程一步步排雷最终把整条链路彻底跑通。步骤 1确认网络与服务发现真的正常先看 Prometheus → Alertmanager 服务发现页面直接显示alertmanager:9093已上线说明服务名解析正常、网络互通。之前用wget alertmanager:9093报bad address纯属 Prometheus 镜像内工具的兼容性问题不要用工具判断监控链路要看页面状态步骤 2修复 QQ 邮箱 SMTP 配置最关键根因一开始用的错误配置yamlsmtp_smarthost: smtp.qq.com:465 smtp_require_tls: true这俩根本不兼容465 是隐式 TLS连接建立时直接加密不支持STARTTLS命令587 才是显式 TLSSTARTTLS和smtp_require_tls: true配置项完美匹配直接改成 587 端口后邮件底层链路瞬间通了。步骤 3删掉抑制规则别让告警被吃掉原来的抑制规则yamlinhibit_rules: - source_match: severity: critical target_match: severity: warning equal: [alertname,instance]意思是同一个实例出现 critical 严重告警时所有 warning 警告告警全部被抑制、不发送。测试阶段直接注释掉保证所有告警都能正常发出排查时不再被 “吞告警” 坑。步骤 4只保留邮件去掉企业微信干扰先把企业微信 WebHook 全删掉只跑邮件通知少一个渠道就少一个报错可能排障效率直接拉满。步骤 5重启 Alertmanager 生效配置bash运行docker restart alertmanager✅ 第三步最终验证 —— 一关探针邮件立刻到1. 手动触发宕机告警bash运行docker stop node_exporter2. 观察 Prometheus 页面状态先变成PENDING等待 30s符合for: 30s规则30s 后自动变成FIRING真正触发告警3. 查看日志确认链路bash运行# 查看Prometheus日志确认告警推送至Alertmanager docker logs --tail 20 prometheus # 查看Alertmanager日志确认接收告警、发送邮件 docker logs --tail 20 alertmanager能清晰看到告警已触发、已发送至 Alertmanager、已发送邮件全链路无异常。4. 查收邮箱告警邮件稳稳收到包含告警级别、实例信息、描述等完整内容。5. 恢复探针验证恢复通知bash运行docker start node_exporter等待 1 分钟后告警恢复邮件也正常收到整条链路采集 → 告警 → 通知 → 恢复彻底闭环。⚠️ 避坑总结干货直接拿走不要用 wget/curl 判断 Prometheus 链路服务发现页面才是标准答案工具报错不代表服务不通别被误导死磕网络。QQ 邮箱一定用 587 STARTTLS465 会直接静默失败不报错、不发送、很难排查是最容易踩的坑。测试阶段先关掉 inhibit_rules它会悄悄吞掉 warning 告警排查时会让你怀疑人生生产环境按需再开。多渠道通知先别一起上先跑通一个再加第二个不然错在哪都不知道排查效率极低。PENDING 不是故障那是for: 30s在等待等一等就会自动转为 FIRING无需手动干预。 下一步计划监控底座已经稳了接下来继续往上堆接入企业微信机器人告警实现邮件 微信双渠道通知完善 CPU、内存、磁盘使用率等多维度告警规则做一套统一的告警模板优化通知样式接入 Grafana 面板做成完整可视化监控体系关注我持续更新《人生底稿》成长史 《技术底稿》实战干货一起踏实成长不焦虑、不内卷。 系列导航【人生底稿 01】农村少年1995–2005【技术底稿】0137岁老码农用4台机器搭了套个人DevOps平台