1. 项目概述为什么需要这套监控告警体系在任何一个稍微有点规模的线上系统里你肯定遇到过这样的场景半夜被电话叫醒说服务挂了然后你手忙脚乱地登录服务器一通top、df、netstat操作试图从海量的日志和模糊的报错信息里找到问题根源。这个过程痛苦、低效而且充满了不确定性。更糟的是很多时候问题发生了但没人知道直到用户投诉过来损失已经造成。这就是为什么我们需要一个主动的、可视化的、能及时告警的监控系统。它就像是系统的“仪表盘”和“哨兵”让你能实时掌握服务的健康状态在问题萌芽阶段就收到警报而不是被动地“救火”。Prometheus和Grafana的组合正是当前云原生时代监控领域的“黄金搭档”。Prometheus负责数据的抓取和存储它采用拉模型Pull主动从配置好的目标Targets上抓取指标Metrics时序数据库的设计让它特别适合处理动态变化的监控数据。而Grafana则是一个强大的数据可视化平台它能将Prometheus里那些冰冷的数字变成直观的图表、仪表盘让你一眼就能看懂系统的CPU、内存、网络I/O、业务QPS等关键指标。更重要的是两者都支持灵活的告警规则配置当指标异常时可以通过邮件、钉钉、企业微信、Webhook等多种方式通知到你。这次我们不谈空洞的理论直接上手实战。我会带你从最基础的Docker环境开始一步步搭建起一套完整的PrometheusGrafana监控告警系统并深入到企业级应用中常见的配置细节和避坑指南。无论你是运维工程师、开发人员还是架构师这套流程都能为你提供一个坚实可靠的监控基础。2. 核心组件选型与环境准备2.1 为什么选择Docker部署在开始之前我们先聊聊部署方式的选择。你可以选择在物理机或虚拟机上直接安装二进制包也可以用包管理器如apt、yum安装。但我强烈推荐使用Docker部署原因有三点。第一是环境隔离与一致性。Prometheus、Grafana以及后面要用到的各种Exporter如Node Exporter用于监控主机它们对运行环境可能有不同的依赖。用Docker容器化部署每个服务都在自己独立的沙箱环境中运行互不干扰避免了“在我的机器上好好的”这类环境问题。你只需要一个Docker环境就能在任何地方开发、测试、生产复现完全相同的部署。第二是部署与升级的便捷性。Docker通过镜像和容器管理使得服务的启动、停止、升级变得极其简单。升级Prometheus版本只需要拉取新镜像重启容器即可通常配置文件都是挂载进去的数据也可以持久化到宿主机升级过程对业务几乎无感。第三是资源管理与编排友好。Docker天然适合与KubernetesK8s等容器编排平台结合。当你未来需要将监控系统容器化编排、实现高可用时基于Docker的部署就是最顺滑的起点。所以确保你的服务器上已经安装好了Docker和Docker Compose。这里以Linux系统为例如果你用的是Windows或macOSDocker Desktop也能提供相同的体验。# 1. 安装Docker以Ubuntu为例其他系统请参考官方文档 sudo apt-get update sudo apt-get install -y docker.io # 2. 启动Docker服务并设置开机自启 sudo systemctl start docker sudo systemctl enable docker # 3. 安装Docker Compose sudo curl -L https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose sudo chmod x /usr/local/bin/docker-compose # 4. 验证安装 docker --version docker-compose --version注意生产环境建议使用特定版本而非latest标签以保证稳定性。国内用户可能需要在/etc/docker/daemon.json中配置镜像加速器以提升拉取镜像的速度。2.2 规划监控架构与目录结构在敲命令之前好的规划能让后续维护事半功倍。我们规划一个简单的单节点架构但预留出扩展性。Prometheus Server: 监控核心负责抓取、存储指标数据并评估告警规则。Grafana: 数据可视化与告警面板。Node Exporter: 部署在需要监控的宿主机上用于收集主机层面的指标CPU、内存、磁盘、网络等。Alertmanager(可选但推荐): 专用于处理由Prometheus产生的告警进行分组、去重、静默并路由到不同的接收器如钉钉。我们使用Docker Compose来编排这些服务。先创建一个清晰的项目目录mkdir -p ~/monitoring/{prometheus,grafana,alertmanager} cd ~/monitoring目录结构如下monitoring/ ├── docker-compose.yml # 编排文件 ├── prometheus/ │ ├── prometheus.yml # Prometheus主配置文件 │ └── alerts/ # 存放告警规则文件 │ └── host_rules.yml ├── grafana/ │ ├── provisioning/ # Grafana预配置数据源、仪表盘 │ │ ├── datasources/ │ │ │ └── datasource.yml │ │ └── dashboards/ │ │ └── dashboard.yml │ └── config/ # 自定义Grafana配置如汉化 │ └── grafana.ini └── alertmanager/ # Alertmanager配置 └── config.yml使用这种结构我们将配置和数据都挂载到宿主机这样即使容器销毁我们的配置和监控数据如果配置了持久化也不会丢失。3. 核心配置解析与实操部署3.1 编写Docker Compose编排文件docker-compose.yml是我们的总指挥文件。它定义了所有服务、网络、卷挂载和依赖关系。version: 3.8 networks: monitoring: driver: bridge volumes: prometheus_data: {} # Prometheus数据持久化卷 grafana_data: {} # Grafana数据持久化卷 services: prometheus: image: prom/prometheus:latest container_name: prometheus restart: unless-stopped volumes: - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro - ./prometheus/alerts/:/etc/prometheus/alerts/:ro - prometheus_data:/prometheus command: - --config.file/etc/prometheus/prometheus.yml - --storage.tsdb.path/prometheus - --web.console.libraries/etc/prometheus/console_libraries - --web.console.templates/etc/prometheus/consoles - --storage.tsdb.retention.time30d # 数据保留30天 - --web.enable-lifecycle # 启用生命周期API支持热重载配置 ports: - 9090:9090 networks: - monitoring extra_hosts: - host.docker.internal:host-gateway # 用于容器内访问宿主机服务 grafana: image: grafana/grafana:latest container_name: grafana restart: unless-stopped volumes: - grafana_data:/var/lib/grafana - ./grafana/provisioning:/etc/grafana/provisioning:ro - ./grafana/config/grafana.ini:/etc/grafana/grafana.ini:ro environment: - GF_SECURITY_ADMIN_PASSWORDadmin123 # 设置初始管理员密码生产环境务必修改 - GF_INSTALL_PLUGINSgrafana-piechart-panel # 可安装额外插件 ports: - 3000:3000 networks: - monitoring depends_on: - prometheus alertmanager: image: prom/alertmanager:latest container_name: alertmanager restart: unless-stopped volumes: - ./alertmanager/config.yml:/etc/alertmanager/config.yml:ro command: - --config.file/etc/alertmanager/config.yml - --storage.path/alertmanager ports: - 9093:9093 networks: - monitoring实操心得--web.enable-lifecycle这个参数非常有用。启用后当你修改了prometheus.yml或告警规则文件不需要重启整个容器只需要发送一个POST请求到http://localhost:9090/-/reloadPrometheus就会热重载配置避免监控中断。另外extra_hosts的配置是为了让Prometheus容器能通过host.docker.internal这个主机名访问到宿主机上运行的Node Exporter这在开发测试时很方便。3.2 详解Prometheus核心配置接下来是重头戏prometheus.yml。这个文件定义了Prometheus要监控谁抓取目标、抓取频率、告警规则文件位置等。# prometheus/prometheus.yml global: scrape_interval: 15s # 默认每15秒抓取一次指标 evaluation_interval: 15s # 每15秒评估一次告警规则 # 告警规则文件路径支持通配符 rule_files: - alerts/*.yml # 抓取配置这里定义了一个名为“监控对象”的抓取任务 scrape_configs: # 任务一监控Prometheus自身 - job_name: prometheus static_configs: - targets: [localhost:9090] # Prometheus自己暴露的指标端点 # 任务二监控宿主机通过Node Exporter - job_name: node static_configs: - targets: [host.docker.internal:9100] # Node Exporter默认端口9100 labels: instance: monitor-server-01 # 给这台主机打上标签便于在Grafana中区分 # 任务三示例监控一个Web服务 - job_name: my-web-app metrics_path: /actuator/prometheus # Spring Boot Actuator的端点 static_configs: - targets: [app-server:8080] labels: app: user-service env: prod关键配置解析scrape_interval: 抓取间隔。太短会增加Prometheus和目标服务的负载太长则监控粒度太粗。15s是平衡性能和实时性的常用值。evaluation_interval: 告警规则评估间隔。它决定了Prometheus多久检查一次告警规则是否被触发。通常与抓取间隔一致或为其倍数。job_name: 任务名逻辑上的一组监控目标。targets: 监控目标地址格式为host:port。host.docker.internal是Docker提供的一个特殊DNS指向宿主机。labels: 标签。这是Prometheus最强大的特性之一你可以为监控目标添加任意维度的标签如instance,app,env,region。这些标签会附加到该目标产生的所有指标上后续在Grafana查询、聚合、告警时可以按这些标签进行灵活的筛选和分组。3.3 部署Node Exporter并验证Node Exporter需要部署在你想监控的宿主机上。由于它需要访问主机系统信息我们通常直接运行二进制文件或使用host网络模式的容器。使用Docker运行Node Exporterdocker run -d \ --namenode-exporter \ --restartunless-stopped \ --nethost \ --pidhost \ -v /:/host:ro,rslave \ prom/node-exporter:latest \ --path.rootfs/host--nethost: 使用主机网络让Node Exporter直接暴露在主机的9100端口。--pidhost: 允许容器访问主机进程信息。-v /:/host:ro,rslave: 将主机根目录只读挂载到容器内以便读取系统文件。部署后访问http://你的服务器IP:9100/metrics应该能看到大量以node_开头的指标输出这证明Node Exporter工作正常。现在启动我们的监控栈cd ~/monitoring docker-compose up -d访问http://localhost:9090(Prometheus) 和http://localhost:3000(Grafana账号admin/密码admin123)如果都能打开说明基础服务已就绪。在Prometheus的Web UI - Status - Targets页面你应该能看到prometheus和node两个job的状态都是UP。如果node是DOWN检查一下Node Exporter是否运行以及Prometheus配置中的host.docker.internal是否能正确解析到宿主机的IP在某些Linux发行版上可能需要额外配置。4. Grafana配置与可视化实战4.1 配置Prometheus数据源首次登录Grafana后需要先添加数据源。我们可以通过预配置Provisioning自动完成避免手动操作。创建grafana/provisioning/datasources/datasource.ymlapiVersion: 1 datasources: - name: Prometheus type: prometheus access: proxy url: http://prometheus:9090 # 使用Docker Compose服务名访问 isDefault: true editable: false重启Grafana容器后数据源会自动添加。在Grafana侧边栏的Configuration-Data Sources中确认Prometheus数据源已存在且状态正常显示Health: OK。4.2 导入与定制监控仪表盘Grafana社区有海量现成的仪表盘模板。对于主机监控最经典的就是Node Exporter Full仪表盘。方法一通过ID在线导入需网络在Grafana首页点击Create-Import。在Import via grafana.com输入框中填入仪表盘ID1860点击Load。选择数据源为Prometheus点击Import。方法二通过Provisioning预配置推荐用于生产将仪表盘JSON文件下载到本地通过配置自动导入。创建grafana/provisioning/dashboards/dashboard.ymlapiVersion: 1 providers: - name: default orgId: 1 folder: type: file disableDeletion: false updateIntervalSeconds: 10 allowUiUpdates: true options: path: /etc/grafana/provisioning/dashboards然后将下载的node-exporter-full.json文件放到grafana/provisioning/dashboards/目录下重启Grafana服务。导入成功后你就能看到一个全面的主机监控面板涵盖了CPU、内存、磁盘、网络、系统负载等几乎所有关键指标。你可以基于这个模板进行修改比如调整图表颜色、修改查询语句、增加符合自己业务需求的图表。4.3 核心指标解读与告警阈值设定看仪表盘不能只看个热闹要理解关键指标的含义和健康范围。CPU使用率100 - (avg by (instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100)。长期超过80%就需要关注可能意味着需要扩容或优化代码。内存使用率(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100。注意Linux的可用内存Available包含了缓存和缓冲区所以即使使用率看起来很高系统也可能很健康。更应关注是否发生Swap。磁盘使用率node_filesystem_avail_bytes{mountpoint/} / node_filesystem_size_bytes{mountpoint/} * 100。这是最需要设置告警的指标之一根分区使用率超过85%就必须处理超过90%很可能导致服务崩溃。系统负载node_load1,node_load5,node_load15。负载平均值应小于CPU核心数。如果1分钟负载远高于15分钟负载可能是突发流量如果持续高于核心数2倍以上说明系统过载。基于这些理解我们就可以去Prometheus配置告警规则了。5. 企业级告警配置实战5.1 编写Prometheus告警规则告警规则定义了在什么条件下触发告警。我们创建prometheus/alerts/host_rules.ymlgroups: - name: host_monitoring rules: # 规则1实例宕机 - alert: InstanceDown expr: up{jobnode} 0 for: 1m # 持续1分钟条件满足才触发避免网络抖动误报 labels: severity: critical team: infra annotations: summary: 实例 {{ $labels.instance }} 宕机 description: {{ $labels.instance }} 上的 {{ $labels.job }} 服务已超过1分钟无法访问。 # 规则2CPU使用率过高 - alert: HighCpuUsage expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100) 80 for: 5m labels: severity: warning team: infra annotations: summary: 实例 {{ $labels.instance }} CPU使用率过高 description: {{ $labels.instance }} 的CPU使用率持续5分钟超过80%当前值为 {{ $value }}%。 # 规则3内存使用率过高 - alert: HighMemoryUsage expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 85 for: 5m labels: severity: warning team: infra annotations: summary: 实例 {{ $labels.instance }} 内存使用率过高 description: {{ $labels.instance }} 的内存使用率持续5分钟超过85%当前值为 {{ $value }}%。 # 规则4磁盘空间不足根分区 - alert: LowDiskSpace expr: node_filesystem_avail_bytes{mountpoint/} / node_filesystem_size_bytes{mountpoint/} * 100 15 for: 2m labels: severity: critical team: infra annotations: summary: 实例 {{ $labels.instance }} 根分区磁盘空间不足 description: {{ $labels.instance }} 的根分区可用空间低于15%当前仅剩 {{ $value }}%。请立即清理规则解析expr: 告警表达式使用PromQLPrometheus查询语言。当表达式结果不为空时表示条件满足。for: 持续时间。指标异常必须持续满足该时长才会触发告警。这是避免告警风暴的关键务必根据指标特性设置。labels: 附加到告警上的标签用于在Alertmanager中做路由和分组。annotations: 告警的详细描述支持模板变量如{{ $labels.instance }},{{ $value }}这些信息会出现在告警通知里。修改规则后需要让Prometheus重新加载配置curl -X POST http://localhost:9090/-/reload。然后在Prometheus的Alerts页面可以看到定义的告警规则及其当前状态Pending或Firing。5.2 配置Alertmanager实现告警路由与降噪Prometheus负责“触发”告警而Alertmanager负责“处理”告警。它的核心功能是分组、抑制、静默和路由。创建alertmanager/config.ymlglobal: resolve_timeout: 5m # 告警恢复后等待5分钟再发送解决通知 route: group_by: [alertname, severity] # 按告警名和严重程度分组 group_wait: 30s # 同一分组内等待30秒收集同一时间段内产生的告警 group_interval: 5m # 同一分组内已发送过告警后至少等待5分钟再发送新告警 repeat_interval: 12h # 同一告警如果未解决每隔12小时重复发送一次 receiver: web.hook # 默认接收器我们先用Webhook测试 routes: # 子路由可以按标签将告警路由到不同的接收器 - match: severity: critical receiver: critical_team continue: false # 匹配后不再继续向下路由 - match: severity: warning receiver: warning_team receivers: - name: web.hook webhook_configs: - url: http://your-webhook-server/alert # 替换成你的Webhook接收地址用于测试 - name: critical_team # 这里可以配置邮件、钉钉、企业微信等。以钉钉为例 # webhook_configs: # - url: https://oapi.dingtalk.com/robot/send?access_tokenYOUR_TOKEN # send_resolved: true - name: warning_team # 配置警告级别的通知方式如邮件 # email_configs: # - to: ops-teamexample.com # from: alertmanagerexample.com # smarthost: smtp.example.com:587 # auth_username: user # auth_password: password inhibit_rules: # 抑制规则用于减少重复告警 - source_match: severity: critical target_match: severity: warning equal: [alertname, instance] # 如果同一个实例的同一个告警名出现了critical告警则抑制它的warning告警这个配置实现了分组将30秒内同一主机产生的多个告警合并成一条通知发送避免刷屏。路由将critical和warning级别的告警发送到不同的接收方如钉钉群和邮件组。抑制当某个主机发生critical级别的HighCpuUsage告警时抑制同一主机warning级别的HighCpuUsage告警避免重复通知。5.3 配置Grafana告警作为补充除了Prometheus的告警Grafana自身也提供了强大的告警功能它更侧重于对仪表盘上已可视化的图表设置阈值告警。其优点是配置直观直接在图表上操作。在任意图表标题处点击选择Edit。切换到Alert标签页点击Create Alert。设置告警规则例如当CPU使用率在5分钟内is above80时触发。配置通知渠道需要先在Alerting-Notification channels中添加如邮件、钉钉等。实操心得建议以Prometheus告警为主Grafana告警为辅。Prometheus告警更底层、更灵活能与Alertmanager的强大路由、抑制功能结合。Grafana告警适合对某个特定仪表盘的视图设置快速告警或者当你的数据源不是Prometheus时使用。两者可以共存但要注意避免重复告警。6. 生产环境进阶配置与优化6.1 数据持久化与备份在Docker Compose中我们已经通过volumes将prometheus_data和grafana_data挂载到了命名卷。但命名卷默认由Docker管理位置可能不直观。生产环境建议挂载到宿主机的特定目录并做好备份。# 修改docker-compose.yml中的volumes部分 services: prometheus: volumes: - /data/monitoring/prometheus/data:/prometheus # 挂载到宿主机目录 - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro - ./prometheus/alerts/:/etc/prometheus/alerts/:ro grafana: volumes: - /data/monitoring/grafana/data:/var/lib/grafana - ./grafana/provisioning:/etc/grafana/provisioning:ro备份策略Prometheus数据定期备份/data/monitoring/prometheus/data目录。可以使用rsync或云存储工具。注意Prometheus的数据是分块存储的直接拷贝整个目录是安全的。Grafana数据备份/data/monitoring/grafana/data目录。更重要的是利用Grafana的Dashboard Provisioning和DataSource Provisioning将仪表盘和数据源的配置都以代码YAML/JSON形式管理在git中这是最可靠的备份。配置文件整个~/monitoring目录除了数据目录都应该纳入版本控制如Git。6.2 安全与访问控制默认部署下Prometheus9090端口和Grafana3000端口都是无认证直接暴露的这非常危险。Grafana安全强制修改默认密码首次登录后立即修改admin密码。启用登录认证在grafana.ini中配置[security]和[auth]部分或使用OAuth如GitHub, GitLab, Google登录。配置反向代理与HTTPS使用Nginx或Traefik作为反向代理配置SSL证书启用HTTPS并可以在代理层配置基础认证或IP白名单。# Nginx示例配置片段 server { listen 443 ssl; server_name grafana.yourdomain.com; ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/key.pem; location / { proxy_pass http://localhost:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } # 可以添加 auth_basic 等指令 }Prometheus安全 Prometheus本身功能相对简单通常不建议直接对外暴露。最佳实践是不对外暴露9090端口或通过反向代理IP白名单严格限制访问来源如只允许内网IP、Grafana服务器IP、运维跳板机IP。使用Prometheus的--web.config.file参数支持TLS和基础认证较新版本但配置稍复杂。对于内部系统通过网络隔离VPC、安全组是更常见有效的方式。6.3 性能调优与高可用考量Prometheus调优存储对于写入量大的场景考虑使用SSD磁盘。调整--storage.tsdb.retention.time数据保留时间和--storage.tsdb.retention.size数据保留大小平衡存储成本与历史查询需求。抓取调整scrape_interval。对于不重要的指标可以适当拉长间隔。使用scrape_timeout设置抓取超时避免慢响应目标阻塞。内存Prometheus对内存消耗较大尤其是查询大量历史数据时。确保服务器有足够内存建议16GB起步。监控Prometheus自身的process_resident_memory_bytes指标。高可用HA方案 单点Prometheus存在单点故障风险。企业级方案通常采用双活Prometheus部署两个完全相同的Prometheus抓取相同的目标。Grafana配置两个数据源查询时做冗余。缺点是存储翻倍且告警可能重复。Prometheus Thanos/Cortex/VictoriaMetrics这是更成熟的方案。多个Prometheus实例将数据上传到对象存储如S3由Thanos Query组件提供统一的查询入口实现全局视图、长期存储和高可用。这是面向大规模集群的推荐架构。监控Kubernetes 当你的应用部署在K8s中时监控方式需要调整。推荐使用Prometheus Operator它通过CRD自定义资源定义来管理Prometheus、Alertmanager及其配置能够自动发现并监控K8s中的Service、Pod等资源极大地简化了在动态容器环境中的监控配置。7. 常见问题排查与实战技巧7.1 部署与启动问题问题1Docker Compose启动时Prometheus或Grafana容器不断重启。排查使用docker-compose logs -f prometheus查看具体日志。常见原因与解决配置文件语法错误YAML对缩进非常敏感。使用在线YAML校验器或yamllint工具检查prometheus.yml和docker-compose.yml。端口冲突确保宿主机9090、3000、9093端口未被占用。netstat -tlnp | grep 端口号。挂载目录权限Prometheus/Grafana容器内用户如nobody uid 65534可能没有写入挂载数据目录的权限。确保宿主机目录权限正确sudo chown -R 65534:65534 /data/monitoring/prometheus/data。问题2Prometheus Targets页面显示DOWN。排查将鼠标悬停在DOWN状态上会显示错误信息如“connection refused”或“i/o timeout”。常见原因与解决目标服务未运行确认Node Exporter等服务是否正在运行docker ps或systemctl status。网络不通如果目标在容器内确保它们在同一个Docker网络中。如果目标是宿主机服务检查host.docker.internal是否可用Linux原生Docker可能需要额外配置。可以进入Prometheus容器测试连通性docker exec -it prometheus sh然后curl target-ip:port。防火墙/安全组检查目标端口如9100是否在宿主机防火墙或云服务商安全组中开放。7.2 数据与查询问题问题3Grafana中查询不到数据显示“No data”。排查步骤检查数据源在Grafana的Data Sources中测试Prometheus数据源连接是否成功。检查时间范围确保Grafana右上角的时间范围选择器没有设到一个过去没有数据的时间段。检查PromQL在Grafana的Explore页面或Prometheus的Graph页面手动输入查询语句如up看是否有数据返回。检查指标名在Prometheus的Graph页面输入{jobnode}查看自动补全的指标列表确认你查询的指标名是否存在且拼写正确。问题4告警规则不触发或状态不对。排查在Prometheus的Alerts页面查看告警规则状态。Inactive表达式条件不满足。Pending条件满足但未持续for指定的时间。这是正常状态用于防抖。Firing告警已触发。常见原因表达式错误在Prometheus的Graph页面手动执行告警规则中的expr看是否有数据返回数据值是否符合预期。for时间设置过长对于需要快速响应的告警如InstanceDownfor可以设短些如30s。标签不匹配确保告警规则中的标签如jobnode与抓取目标配置的标签匹配。7.3 性能与稳定性问题问题5Prometheus内存或CPU使用率过高。可能原因抓取目标过多或间隔太短减少不必要的抓取任务或拉长非核心指标的scrape_interval。存储数据量过大缩短数据保留时间--storage.tsdb.retention.time或迁移到长期存储方案Thanos。复杂的查询或告警规则优化PromQL避免全表扫描或计算过于复杂的表达式。特别是Grafana仪表盘上刷新间隔过短且图表过多时会给Prometheus带来很大查询压力。监控自身务必为Prometheus服务器本身部署Node Exporter并设置关键告警如内存使用率80%。问题6告警通知没有发送。排查链路Prometheus Alerts页面确认告警状态是否为Firing。Alertmanager页面访问http://localhost:9093查看Alerts标签页是否有告警到达Alertmanager。Alertmanager日志docker-compose logs alertmanager查看发送通知时的错误信息。接收端配置检查钉钉机器人Webhook地址、邮件SMTP配置等是否正确。特别是网络策略确保Alertmanager容器能访问外网或你的内部通知服务。踩过几次坑之后我的体会是监控系统的稳定性比功能的丰富性更重要。一个时不时误报、漏报或者自己挂掉的监控系统会迅速消耗掉团队的信任。因此在初期优先保证核心指标如存活、CPU、内存、磁盘的准确告警并让监控系统自身处于被监控之下。随着对这套体系的理解加深再逐步添加业务层面的自定义指标和更复杂的告警规则这样才能构建出一个真正可靠、有用的监控防线。