做过分布式系统的人都有过这种经历凌晨两点被电话叫醒某个服务挂了但没人知道是哪台机器、哪个节点、哪块磁盘出了问题。你赶紧打开终端一台一台登录服务器翻日志、看内存、查CPU忙活半天最后发现是某个节点的磁盘满了但监控系统压根没配到位。这就是我为什么一直强调分布式系统里监控不是“锦上添花”而是“基础设施里的基础设施”。没有监控你的系统就像一台没有仪表盘的飞机——飞得起来但根本不知道什么时候会失控。今天我就把过去几年在真实业务环境里折腾分布式系统监控工具的经验、踩过的坑、以及一套可以直接抄作业的搭建方案一次性梳理出来。这篇内容适合正在搭建或维护分布式系统的开发、运维和SRE同学。不管你是刚接触监控还是已经用着某套工具但想换个思路我都尽量说得具体一点少讲虚的多讲实操。1. 从一次“半夜被叫醒”说起分布式系统为什么需要监控先聊一个最基本的追问分布式系统到底为什么这么依赖监控很多人第一反应是“分布式系统节点多、架构复杂、出了问题不好查”。这句话对但不够本质。我自己理解的逻辑是这样单机系统出问题范围是明确的你只需要在一台机器上排查。分布式系统不同请求会被路由到不同节点数据会跨节点复制某个环节慢一点点整个链路就可能雪崩。你要在几十台、几百台甚至上千台节点里找到罪魁祸首没有一套监控体系几乎是不可能的。1.1 分布式系统的“脆弱性”在哪里分布式系统最大的特点也是最大的痛点就是“局部故障是常态”。比如一个典型的三节点集群某个节点因为网络抖动被集群判定为“失联”。这时候如果监控没有感知到节点状态变化副本数据可能开始重新平衡大量IO开销会瞬间把剩下两个节点拖垮。再比如某个服务的GC停顿从原来的50毫秒涨到2秒调用方的超时时间只有1秒——这个服务自己没挂但上游大量请求已经超时了用户体验就是“系统卡死了”。我给你举一个我自己踩过的真实例子。之前维护过一个数据采集集群每天要处理几十亿条日志。某天下午业务方反馈数据延迟越来越大我们最初怀疑是Kafka消费能力不足把消费者线程数从10调到20没用又升级了实例规格还是没缓解。折腾了两个小时最后才通过监控面板发现某个数据节点的磁盘IO利用率已经跑到98%持续了将近四十分钟。根源是另一个团队在同一个物理机上跑了批量任务把磁盘IO吃光了。这件事最让我印象深刻的不是排查过程有多曲折而是如果没有监控我们可能还要折腾更久。磁盘IO这个指标平时没人看一旦出问题影响是全局性的——Kafka、HDFS、ClickHouse全都会跟着变慢。所以后来我总结了一句话分布式系统里的每一个节点都可能成为整个系统的瓶颈而你永远不知道瓶颈会先出现在哪个环节。1.2 没有监控时排查问题像“大海捞针”没有监控的分布式系统排查问题基本靠猜。你只能登服务器一个个看进程在不在CPU高不高内存够不够。如果这些看起来都没问题你就得翻日志——但日志分布在不同节点上你得先找出请求到底经过了哪些节点。在微服务架构里一个请求可能经过五六层服务每层都可能出问题靠人工去追效率太低了。我印象很深的一次是排查一个偶发超时问题。用户反馈某个接口偶尔会慢但概率很低大概万分之一的请求会超时。我们靠人工盯了三天日志翻了几千条始终找不到规律。后来用监控系统把每个阶段的耗时拆出来才发现问题出在某个服务的连接池上——连接池在高峰期被耗尽新的请求在等待连接时超过了超时时间。这个结论在有监控的情况下半小时就能定位到但我们的团队没有监控数据硬是熬了三天。所以我说监控系统在分布式场景里解决的核心问题是让“看不见的问题”变得“可见”。它帮你把系统的实时状态、历史趋势、故障线索全部记录下来让你在出问题时有一个全局视角而不是在一个个节点里大海捞针。2. 监控到底看什么核心指标拆解与告警设计有了监控工具不等于有监控能力。工具只是载体真正的核心是你知道“该看什么指标”“什么时候该告警”。这一部分我把自己在实践中沉淀下来的指标体系和告警设计思路详细讲一下。2.1 四个黄金信号延迟、流量、错误、饱和度Google SRE的《SRE: Google运维解密》里提出了“四个黄金信号”业界普遍认为是监控指标体系的基础也是我在设计监控方案时的起点。第一是延迟。延迟代表请求处理的速度通常用P50、P95、P99这几个分位数来度量。P99的意思是“99%的请求延迟在这条线以下”。为什么我不太看平均值因为平均值会被少数极慢请求拉高掩盖大多数请求的实际情况。一个接口平均延迟是200ms看起来正常但P99可能已经到了5秒——这意味着每100个请求里有1个请求要忍受5秒的等待这在用户体验上已经是灾难了。第二是流量。流量代表系统当前承接的压力常见指标有QPS每秒查询数、TPS每秒事务数、带宽占用等。流量指标的价值在于它能帮你判断系统是否处于高负载状态以及在流量突增时提前预警。比如双11大促前夕我们会特别关注流量曲线如果提前发现流量涨得比预期快就会提前扩容而不是等系统被打挂了再处理。第三是错误。错误代表请求失败的情况包括显式的HTTP 5xx错误码、业务返回的异常码以及隐式的响应内容错误。错误率是一个必须设置告警的指标。我的经验是不要只盯着“硬错误”还要关注“软错误”——比如接口返回成功但响应体里的数据不符合预期这种错误最隐蔽也最危险。第四是饱和度。饱和度衡量的是系统“还能扛多少量”通常表现为资源使用率。CPU使用率、内存使用率、磁盘IO利用率、连接池使用率、磁盘剩余空间都属于饱和度指标。饱和度是预判故障的关键——延迟和错误是问题已经发生之后的表现而饱和度意味着问题正在逼近你还有时间做准备。2.2 分层的监控视角基础设施层、中间件层、应用层、业务层四个黄金信号是“纬线”监控还需要一条“经线”——按照系统层次来划分监控视角。我自己习惯把监控分为四层每一层都有各自的关注点。第一层是基础设施层。重点看CPU、内存、磁盘IO、网络带宽、文件句柄数等。这些指标是系统运行的底座任何一个出问题都会向上传导。比如CPU持续飙高应用层响应就会变慢磁盘空间满中间件可能直接写不进去数据。这一层我用node_exporter采集几乎覆盖了所有常见的基础设施指标。第二层是中间件层。数据库、缓存、消息队列、搜索引擎这些组件的健康状态直接影响上层应用。比如MySQL的慢查询数、连接数、主从延迟Redis的内存使用量、命中率Kafka的消费延迟、分区状态HDFS的NameNode状态、DataNode存活数、块复制率。这一层每个中间件都需要专门去盯通用指标不够。第三层是应用层。应用层关注的是服务的请求量、延迟、错误率、JVM/GC情况等。应用层故障往往直接影响业务需要快速发现、快速定位。对于Java服务JVM的堆内存使用、GC次数、GC耗时、线程池状态都是重点监控对象。JVM问题很隐蔽比如一次Full GC可能导致几十毫秒的停顿用户的直观感受就是“卡了一下”如果监控不到排查起来无从下手。第四层是业务层。这一层是很多人容易忽略的。业务层指标不是技术指标而是和业务结果直接相关的数据比如订单量、支付成功率、新增用户数、核心业务接口的调用量。业务层告警的价值在于即使所有技术指标都正常如果支付成功率从99.9%掉到80%一定哪里出了问题但这个问题可能隐藏在业务逻辑里纯技术指标看不到。我自己在实践中的一个原则是每层都要有监控但告警的优先级不同。基础设施层的告警用于“提前预防”中间件层的告警用于“快速定位”应用层的告警用于“及时止损”业务层的告警用于“兜底发现”。四层配合起来才能构成一个完整的监控闭环。3. 工具选型不同场景下我推荐的监控组合工具选型是很多刚接触分布式系统监控的同学最纠结的问题。其实工具没有绝对的好坏只有适不适合你的场景。我把这些年用过的主流方案做一个横向对比再说说我自己的选型逻辑。3.1 Prometheus Grafana云原生时代的事实标准如果让我只推荐一套方案我会推荐Prometheus Grafana的组合。这不是跟风而是这套组合确实是目前兼容性最好、生态最强、最值得投入时间学习的方案。Prometheus是一个开源的监控系统和时序数据库它的核心工作模式是“拉取”Pull。监控目标通过HTTP接口暴露指标Prometheus定期去抓取。这个模式有几个好处被监控方只需要暴露一个指标接口不需要主动推送天然解耦Prometheus自己有服务发现能力可以自动发现Kubernetes里新创建的Pod非常适合云原生环境。Grafana是用来做可视化的。它提供了丰富的图表模板可以从Prometheus里查询数据把指标变成可视化的仪表盘。Grafana最大的好处是开源免费、插件丰富而且很多主流的中间件都有现成的DashBoard模板导入就能用不需要你从零开始画图表。这套组合的另外一个核心优势是生态。Prometheus官方和社区提供了大量ExporterLinux主机用node_exporterMySQL用mysqld_exporterRedis用redis_exporterKafka用kafka_exporterHDFS也有专门的HDFS Exporter。几乎你能想到的组件都有现成的Exporter可以用不需要自己写采集器省去大量重复工作。3.2 其他值得关注的工具Zabbix、SkyWalking、ELKPrometheus很强但也不是唯一的选择。每种主流监控工具都有它适合的场景我逐个聊聊。Zabbix是传统监控里的老大哥优点是全功能、开箱即用自带可视化对基础设施层覆盖得很全面支持SNMP、agent、JMX等多种采集方式。如果你维护的是传统架构比如大量物理机和虚拟机不想折腾太多配置Zabbix其实比Prometheus更省心。但它的短板也很明显时序存储能力一般在超大规模和复杂查询场景下性能不如Prometheus告警规则的编写和调试也不是很灵活。SkyWalking是专门做分布式链路追踪APM的。链路追踪解决的是另一个问题当一个请求经过多个服务哪一环最慢这个信息用传统的指标监控很难还原而SkyWalking可以实现无侵入式接入自动抓取调用链展示每个环节的耗时。我在排查之前说的“偶发超时问题”时靠的就是链路追踪工具。这类工具还包括Jaeger、Zipkin但SkyWalking在Java生态里接入成本最低容错率也高。ELK是指Elasticsearch、Logstash和Kibana的组合核心是日志监控与分析。日志和指标是互为补充的指标告诉你“哪里出了问题”日志告诉你“为什么出问题”。在分布式系统里日志会分散在几百台机器上ELK统一采集、索引、检索配合Kibana的可视化排查问题效率会高很多。对于日志量很大的场景我会在ELK前面加Kafka做缓冲防止日志洪峰直接把Elasticsearch打爆。3.3 选型逻辑别迷信单一工具很多人在选型的时候会陷入“工具之争”非要比较出一个“最强王者”。我的建议是分布式系统监控从来不是靠单一工具解决的而是靠一套组合拳。我自己常用的组合是这样的以Prometheus Grafana作为核心监控底座覆盖指标采集、存储、展示和告警用SkyWalking做应用层链路追踪补齐调用链视角用ELK做日志集中管理负责日志的收集、检索和分析对于Kubernetes环境的实时监控直接依赖Prometheus的服务发现和告警能力对于特定中间件比如HDFS、Kafka用专门的Exporter或自研采集器补充监控指标。这套组合的好处是每个环节都用了“最擅长的那把刀”而不是指望一个工具搞定所有事。工具的组合会带来一定的部署和运维复杂度但这是分布式系统监控的必经之路——你要追求的是掌控感而不是省事。4. 从零搭建一套分布式监控体系前面说了这么多理论接下来进入实操环节。我用目前最主流的技术栈手把手带大家搭建一套可用于生产环境的分布式监控体系。为了便于复现我用Docker Compose做编排组件包括Prometheus、Grafana、node_exporter和Alertmanager。这套方案在我自己的测试环境和多个生产环境中都验证过稳定性和可扩展性都是够用的。4.1 架构设计与组件部署先说我建议的架构。Prometheus作为核心的时序数据库和指标抓取器负责定期从各个Exporter拉取指标node_exporter部署在每个需要监控的节点上暴露操作系统层面的指标Alertmanager接收Prometheus推送的告警信息负责告警的路由和发送Grafana连接Prometheus把指标数据可视化成仪表盘。它们之间的协作关系是这样的node_exporter负责采集Prometheus负责存储和计算告警规则Alertmanager负责发送通知Grafana负责展示。部署之前先确认你的机器上已经安装了Docker和Docker Compose这个比较简单我就不展开说了。下面是我的docker-compose.yml文件我把关键点都注释了可以直接复制使用。version: 3.8 networks: monitor: driver: bridge volumes: prometheus_data: grafana_data: services: # Prometheus 核心组件 prometheus: image: prom/prometheus:latest container_name: prometheus volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml - ./alert-rules.yml:/etc/prometheus/alert-rules.yml - prometheus_data:/prometheus command: - --config.file/etc/prometheus/prometheus.yml - --storage.tsdb.path/prometheus - --storage.tsdb.retention.time30d ports: - 9090:9090 networks: - monitor restart: unless-stopped # Grafana 可视化 grafana: image: grafana/grafana:latest container_name: grafana depends_on: - prometheus ports: - 3000:3000 environment: - GF_SECURITY_ADMIN_PASSWORDadmin123 volumes: - grafana_data:/var/lib/grafana networks: - monitor restart: unless-stopped # node_exporter 采集主机指标 node_exporter: image: prom/node-exporter:latest container_name: node_exporter ports: - 9100:9100 networks: - monitor restart: unless-stopped # Alertmanager 告警管理 alertmanager: image: prom/alertmanager:latest container_name: alertmanager depends_on: - prometheus ports: - 9093:9093 volumes: - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml networks: - monitor restart: unless-stopped这个编排有几个细节值得说明。Prometheus的数据保留时间我设置了30天。时序数据非常占空间如果保留时间太长磁盘压力会很大但太短又不利于回溯历史趋势。30天是我在“能回答历史问题”和“存储成本可控”之间找到的平衡点。Grafana的默认密码我用环境变量直接初始化了生产环境中你一定要改成强密码。node_exporter这里部署了一个容器实际使用中需要在每台被监控的机器上分别部署。4.2 数据采集Prometheus配置与多节点部署部署完容器接下来要写Prometheus的核心配置文件。这个文件定义了Prometheus从哪些数据源抓取指标。我这份配置文件里考虑了多节点的部署方式你要采集哪台机器就在targets里加哪个IP。global: scrape_interval: 15s evaluation_interval: 15s rule_files: - alert-rules.yml alerting: alertmanagers: - static_configs: - targets: - alertmanager:9093 scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090] - job_name: node static_configs: - targets: - node_exporter:9100 - 192.168.1.11:9100 - 192.168.1.12:9100这里我建议你重点理解两个参数。scrape_interval是抓取间隔默认15秒生产环境我一般也用这个值。如果抓得太频繁Prometheus和目标机器的压力都会增大如果间隔太长可能会错过一些瞬时的指标波动导致监控数据不够灵敏。evaluation_interval是告警规则的评估间隔它决定了Prometheus多久检查一次告警规则是否被触发同样设置为15秒是比较合理的默认值。node_exporter部署在不同节点上时每个节点都是独立运行的Prometheus只需要把该节点的IP和端口配置到targets列表里。这里有一个实际经验如果节点数量多了以后手动维护targets列表会变得很痛苦。这时候你可以改用Prometheus的基于文件的自动发现机制把所有的目标写在一个JSON或YAML文件里Prometheus会定期重新加载这个文件无需重启服务。配置方式是把static_configs替换成file_sd_configs。配置完成后执行docker compose up -d启动所有服务Prometheus的Web入口是localhost:9090Grafana的入口是localhost:3000使用admin/admin123登录然后在Configuration里添加数据源选择Prometheus填上http://prometheus:9090即可完成数据源的对接。4.3 告警配置实战Alertmanager 规则编写与通知渠道采集数据只是第一步真正让监控体系“活起来”的是告警。如果监控数据不上报、不及时通知那一切都白搭。我重点讲讲告警规则和Alertmanager的配置。先看一份告警规则文件我命名为alert-rules.yml放在Prometheus的同级目录下。这里我设置了两个基础告警你也可以根据自己的需求扩展。groups: - name: node_alerts rules: - alert: 节点CPU使用率过高 expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100) 80 for: 5m labels: severity: warning annotations: summary: {{ $labels.instance }} CPU使用率超过80% description: 实例 CPU 使用率已持续5分钟超过80%当前值{{ $value }}% - alert: 节点磁盘空间不足 expr: (1 - (node_filesystem_avail_bytes{fstype!~tmpfs|overlay} / node_filesystem_size_bytes{fstype!~tmpfs|overlay})) * 100 85 for: 10m labels: severity: critical annotations: summary: {{ $labels.instance }} 磁盘空间不足 description: 实例磁盘使用率超过85%当前值{{ $value }}%请及时清理或扩容。告警规则里的expr是关键的查询表达式。CPU使用率的表达式值得多说两句node_cpu_seconds_total是节点CPU的累计时间包含idle空闲、user用户态、system内核态等不同的mode。我先通过rate函数计算出5分钟内的平均速率再取idle模式的速率用100减去它得到的就是CPU使用率。for: 5m表示这个状态需要持续5分钟才触发告警这个设计是为了防止CPU瞬时抖动导致的误报。Alertmanager的配置文件alertmanager.yml负责定义告警的接收渠道和路由策略。我直接以最常见的“企业微信Webhook”为例这个在企业生产中非常实用。route: group_by: [alertname] group_wait: 10s group_interval: 1m repeat_interval: 4h receiver: wechat_webhook receivers: - name: wechat_webhook webhook_configs: - url: https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key你的机器人key send_resolved: truerepeat_interval: 4h的意思是如果某条告警一直处于触发状态Alertmanager会每4小时给你发一次重复通知。这个参数值得重视我见过不少团队把重复间隔设成10分钟结果告警风暴一来手机直接被轰炸负责值班的人连正常处理的时间都没有。还有一点send_resolved: true表示告警恢复时也会发送一条恢复通知这对于确认“问题已经解决”很有必要但也要看你是否希望收到这条通知不想收的话可以去掉。4.4 可视化Grafana Dashboard 搭建数据采集和告警都打通了最后一步是把监控面板做好。Grafana的强大之处在于你不需要从零开始画图社区里已经有很多现成的Dashboard模板可以直接导入。我的做法是登录Grafana后在Dashboards页面点击Import输入Dashboard ID就行。比如node_exporter的官方推荐模板ID有1860和8919Prometheus内置的监控面板模板ID是3662。导入之后选择你的Prometheus数据源图表就自动渲染出来了。CPU、内存、磁盘IO、网络流量、文件系统使用率一应俱全。如果现有模板不满足需求你可以自己创建面板。Graph Panel是最常用的图表类型需要配置的要素有查询指标比如node_memory_Active_bytes、图例名称比如内存使用量、单位比如bytes或percent、以及时间范围。左下角你会发现Grafana已经自动提供了一些计算函数方便你在界面上直接处理指标数据。我习惯在每个面板上加上图层名称和关键阈值线。比如CPU使用率这一项我会把85%的位置加一条Threshold线这样一旦曲线突破这条线面板上就会变成醒目的警告颜色比纯看数字直观得多。这个细节在值班时特别有用——你不用盯着每个数字看扫一眼颜色就能判断有没有异常。5. 扩展场景HDFS等分布式存储系统的监控要点基础监控体系搭好之后很多人会问我的业务里用了HDFS、Kafka、ClickHouse这些专门的分布式组件怎么监控它们这一节我用HDFS来举例讲讲分布式存储场景的监控要点。标题里的热搜词也提到了HDFS说明大家对这个确实有需求。5.1 HDFS监控的关键指标HDFS是Hadoop分布式文件系统它的架构是NameNode管理元数据、DataNode存储实际数据块。监控HDFS的核心其实就是监控这两个角色的健康状态和容量情况。NameNode是HDFS的“大脑”它一旦挂掉整个文件系统的元数据就不可用了。重点关注的指标包括NameNode进程是否存活、处于Active还是Standby状态、元数据日志目录的使用量、JVM堆内存使用情况。HDFS的高可用架构里有Active和Standby两个NameNode主备切换是否正常也是必须监控的点。如果切换频繁说明网络或磁盘可能有问题。DataNode负责存储真实的数据块重点关注DataNode进程是否存活、当前存活节点数、块复制因子、健康块数量、复制中的块数量、DataNode的磁盘空间使用率。HDFS有个“块复制”机制它会保证每个数据块有多个副本。正常情况下健康副本数应该等于复制因子。如果出现大量块处于“复制中”状态说明有些副本丢失了HDFS正在自动恢复。短期内可以观察如果长期不恢复那就必须排查DataNode的健康状况。还有两个全局指标值得盯着看HDFS容量使用率和文件系统总文件数。容量使用率超过80%就要开始警惕了超过90%就要尽快扩容或清理数据。HDFS在容量快满时写性能会急剧下降因为系统需要花大量精力去找空间。文件数过多会导致NameNode内存占用过高每一百万个文件大概会占用几百MB的内存这是很多人容易忽略的点。5.2 HDFS监控的实操建议HDFS本身提供了丰富的JMX指标接口常见做法是用Prometheus的jmx_exporter或者专门的hdfs_exporter来采集NameNode和DataNode的指标。我自己的方案是用官方提供的dfs命令脚本做定期采集配合node_exporter监控DataNode宿主机的磁盘空间和IO。这里有一个非常实用的经验HDFS的磁盘监控不能只看“系统磁盘剩余空间”还要看DataNode的数据目录空间分配。有时候系统盘还有空间但HDFS的数据目录已经满了这时候HDFS会认为节点处于“数据写满”状态把该节点上的数据块迁移走导致大规模的跨节点复制。这个问题在监控面板上看起来是“网络流量飙升”实际根子是某个数据目录空间不足隐蔽性很强。所以HDFS监控一定要把数据目录的剩余空间单独拎出来作为指标。另外HDFS的告警要设置“分级”策略。节点掉线属于严重故障要马上通知块复制数量异常属于次严重可以等几分钟再处理容量使用率增长趋势异常属于预警可以先观察一段时间。分级的意义在于避免把所有告警都设置成同一个优先级结果真正严重的问题被一堆低优先级的告警淹没。6. 常见问题与排查技巧实录到了最后一部分我把自己在监控系统实际运行中遇到过的问题以及对应的排查思路写出来。这里不谈高深理论全是真实场景里的踩坑记录。6.1 告警风暴手机被轰炸的根源与对策告警风暴是我见过最普遍的问题。刚刚把监控系统搭好还没有做调优的时候最容易发生。比如磁盘使用率告警设置成“只要超过85%就告警”结果集群里有几十台机器同时触发再加上repeat后值班人员的手机基本上就废了。针对这个问题我总结了一套方法。规则的for参数尽量设置长一点比如5到10分钟这样瞬时抖动不会触发告警。告警的重复间隔不要设太短最少1小时否则一个故障你可能会收到几十条重复通知。把告警做分级严重级别用电话或短信普通级别发到群里即可。告警要尽量带上标签说是哪台机器、哪个指标、当前值是多少方便接收者快速判断是否有必要处理。6.2 Prometheus 内存占用持续飙升Prometheus运行时间长了之后内存占用会越来越高这是很多人的痛点。原因基本是采集的指标数太多、指标基数太大、查询过于频繁。排查时先用PromQL查一下某些高基数标签是不是被引入了比如Pod级别的标签、请求URL的路径参数。在Kubernetes环境里如果把Pod的完整环境变量、容器内的详细元数据都采集进来指标数量会爆炸式增长。解决办法有几个方向一是减少采集频率把scrape_interval从15秒调到30秒二是减少采集目标去掉不必要的Exporter和服务三是对高频的、非必要的标签做指标裁剪用Prometheus的relabel_config实现。最直接的办法是评估一下是否有必要保留过多的历史数据把存储保留时间从原来的30天降到15天内存压力会明显缓解。6.3 数据出现断点为什么监控图上有明显的空缺在Grafana面板上看到曲线出现断点是监控系统本身出故障了。最典型的原因是Prometheus和目标Exporter之间的网络不通或者Exporter服务重启。其次Prometheus抓取超时也会导致数据缺失比如某个Exporter响应太慢超过scrape_timeout的设置Prometheus就会放弃这次抓取。排查思路是去Prometheus的Targets页面看看它会展示每个目标的抓取状态、抓取耗时和最后一次抓取时间。如果发现某个目标长期处于Down状态优先检查目标节点的网络通畅性和Exporter进程是否在运行。“Up”状态良好但曲线还是断点那就要检查Prometheus的存储底层是不是磁盘满了或者写入性能跟不上了。6.4 常见监控问题速查表我把监控体系里常见的故障现象、可能原因、处理建议整理成了一张速查表方便你在实际运维中查阅。现象可能原因处理建议监控面板没有数据数据源配置错误Prometheus与Exporter网络不通检查数据源地址检查Targets状态告警触发但收不到通知Alertmanager路由未配置Webhook地址失效检查alertmanager.yml测试Webhook连通性CPU告警频繁误报规则表达式有误for参数设置太短校验PromQL表达式延长for时间磁盘告警长时间不恢复容量清理滞后数据目录与系统盘混淆检查数据目录空间及时扩容监控曲线数据延迟严重抓取间隔过长Prometheus性能不足缩短scrape_interval评估Prometheus存储资源HDFS块副本长时间异常DataNode磁盘故障副本复制任务堆积检查DataNode状态查看HDFS fsck结果排查工具我是这么用的先看Grafana面板定位异常范围再去Prometheus的PromQL查询界面做精确验证最后登录目标机器查看具体进程和日志。这套流程基本能覆盖百分之九十的监控故障场景。另外建议你保留一份长期运行的监控日志每处理一个问题就把原因和解决思路记录下来时间长了你会拥有一份属于自己环境的排障手册比任何现成的文档都有用。我个人的体会是监控体系的建设绝对不是一锤子买卖。你今天把它搭起来、跑起来只是万里长征的第一步。后续会不断有新节点加入、新组件部署、新业务上线监控规则需要持续迭代告警阈值需要根据实际运行情况动态调整仪表盘也需要随着系统的演进不断完善。真正有效的监控是你在业务爆炸之前就能从指标里看到隐患然后从容地优化而不是等故障真的发生了再手忙脚乱地到处救火。希望你搭完这套体系之后能从“半夜被叫醒”的状态彻底解脱出来。