1. 分布式系统中的监控困局瓶颈为什么总是最晚被发现先说一个我自己的真实经历。某天凌晨两点线上告警响起某核心服务的超时率从0.1%直接飙到30%。我第一反应是打开监控面板结果发现CPU、内存、磁盘、网络全部正常像什么都没发生过一样。然后我开始翻日志逐个服务查整整花了四十分钟才定位到是底层一个存储节点的磁盘I/O延迟异常其他节点看着都正常但那个节点的I/O等待已经高到让整个链路的上游全部排队。这个经历很典型。分布式系统和单机不一样事故的“表象”和“根因”常常隔着好几层。你在应用层看到的是超时往下查可能是消息队列积压再往下查可能是某个消费者线程卡住而那个消费者卡住的原因可能是它依赖的数据库连接池被耗尽了。这一整条链路只要中间有一个环节没有监控你就得靠猜。所以每次聊到“分布式系统监控工具”我的第一个观点都是它解决的不是“有没有数据”的问题而是“故障定位链路有多短”的问题。单机系统用top、df、free就够了因为所有资源都在一台机器上看得见摸得着。到了分布式系统几十上百个节点每个节点都有自己的CPU、内存、磁盘、网络、进程、端口同一时刻产生的数据量之庞大靠人肉翻看根本不可能。你需要一套工具把散落在各个节点上的数据自动化采集、集中存储、统一展示再在异常发生时把有价值的线索主动推送出来。这篇文章就是围绕这件事展开的。适合的技术人群很明确正在为自己的分布式系统搭建监控体系、面对一堆开源方案不知道选哪个、或者已经搭了Prometheus但总觉得没抓到重点的开发和运维同学。我会从选型逻辑、采集器设计、存储可视化、告警排障这几个维度把我踩过的坑和沉淀下来的实践讲透。这里先抛一个结论监控工具不是越贵越好也不是采集指标越多越好而是要让“系统是否健康”和“故障根因在哪”这两个问题能被快速回答。所有组件选型、所有采集项定义、所有告警规则设计都应该围绕这句话来展开。2. 工具选型的三条路线自研采集器、开源套件与单机工具的边界2.1 主流开源监控方案的选型逻辑现在的监控市场基本是几大流派。Prometheus Grafana是云原生时代的事实标准它的拉模式采集、多维标签数据模型、PromQL查询语法非常适合动态变化的容器环境和微服务架构。Zabbix是老牌监控系统擅长传统服务器、网络设备的指标采集和阈值告警机房里的物理机监控用得很广。还有OpenTSDB这类基于HBase的时序数据库方案早期大数据场景用得多但运维成本高现在新项目基本不碰了。这是指标监控的范畴另外还有链路追踪SkyWalking、Jaeger这些管的是请求从一个服务到另一个服务的完整调用链属于另一个维度。这中间有一个特别重要的认知没有一套工具能同时解决指标监控、日志监控和链路追踪三大问题。即便是有钱上商用APM全套也还是会留下自己业务特有的监控盲区。所以理性做法不是选一个“最全”的方案而是先划定边界——指标靠什么日志靠什么调用链靠什么业务自定义指标靠什么。我的边界划分是这样指标监控走Prometheus生态日志监控走ELK或者Loki链路追踪用SkyWalking。这三个东西分开部署、分开维护但会在告警通知里做联动。比如一条告警里带上“相关异常日志的搜索链接”和“该服务最近一段时间的调用链概况”这件事靠的就是告警通知模板和webhook的组装逻辑而不是把监控平台强行整合成一个。2.2 nmon这类单机工具的定位压测与精确定位场景还有一个流派容易被忽略就是nmon、top、perf这类传统单机工具。很多做分布式的人觉得有了Prometheus之后这些命令行工具就该退休了。我的实测经验恰恰相反在大量场景里nmon这类工具的精细度和即时性是平台替代不了的。举个例子你在压测一个分布式存储集群时总会有某个节点的表现和数据中心里其他节点差一大截。整个平台看下来可能只觉得“这个节点好像慢一点”但到底慢在哪nmon可以按秒甚至按更细粒度打出这个节点的CPU、内存、网络、磁盘I/O的每项明细而且不需要额外部署agent也不需要权限审批直接ssh上去跑一下就能看。这种“单点深挖”的能力是平台监控的有力补充。但nmon有一个比较现实的限制它默认只支持较短时间的高频采样长时间运行会产生大量文本文件需要配套分析脚本。还有二进制的兼容性问题尤其是ARM64架构的机器官方提供的预编译版本经常会直接跑不起来这个我下面专门展开说。所以我的定位是平台监控管常态单机工具管排查。后者不是替代品是最后一百米排查时的手持放大镜。2.3 为什么最终选择“自研采集器 Prometheus Grafana”组合选型这件事技术之外还要算成本账。Prometheus是开源免费的Grafana开源版功能也够用社区生态里各种exporter都能直接拿来用——node_exporter负责机器基础指标mysqld_exporter管数据库redis_exporter管缓存中间件。这些现成组件拼起来就能覆盖一个大面的场景。但拼完之后你会发现每个团队多少都有一些“只有自己才知道要监控什么”的东西。比如我们的业务里有一个重要的异步任务队列任务积压量直接决定系统健康度。这个指标任何开源exporter都给不了你得自己从业务代码里暴露出来。而如果仅仅为了这类自定义指标就上一个完整的自研监控平台成本实在太高了。所以我的路线是中间态用现成开源组件解决基础面用轻量级自研采集器解决定制面。自研的部分只是一个Agent程序负责定时抓取业务指标、特定进程状态、自定义探针结果然后通过Prometheus的exporter协议暴露给抓取端。听起来很复杂实际上就是一段几百行的采样逻辑。这个组合既保留了生态红利又拿到了定制灵活性算下来是性价比最高的。下面用一个表格快速对比几个方案方便你根据自己的场景对号入座方案优势劣势最适合场景Prometheus Grafana生态丰富云原生友好PromQL查询强大单机存储受限制高可用需要外部组件微服务、Kubernetes、云原生环境Zabbix传统服务器监控成熟告警机制完善数据模型不是时序库灵活度一般物理机、虚拟机、网络设备为主的环境OpenTSDB扩展性强擅长海量时序数据依赖HBase运维成本高查询能力弱历史遗留大数据平台SkyWalking链路追踪能力强无侵入接入不管指标和日志需要配套方案分布式调用链分析和拓扑发现自研Agent Prometheus精准覆盖业务自定义指标轻量可控需要自己写代码存在维护成本业务有独特监控诉求的团队nmon / top / perf单机即时排查零依赖信息密度高无集中存储长期采集需辅助脚本压测分析和单点故障深挖3. 采集器核心设计从指标定义到ARM64机器上的现实问题3.1 指标采集项如何定义基础面、进程面、业务面采集器最怕的是“什么都采”因为指标一多存储压力上来了查询变慢了还不一定有人看。我在设计这个Agent的时候把采集项严格分成三层。第一层是基础面CPU、内存、磁盘、网络这些直接用node_exporter已经覆盖了没必要重复造轮子。但我会在Agent里保留一个兜底逻辑——如果目标机器上不方便部署node_exporter比如某些临时起的小实例Agent自己就能承担这些基础采集。第二层是进程面采集指定进程是否存活、进程的CPU和内存占用、端口是否可以连通、句柄数是否逼近上限。这些是系统是否“活着”的直接证据。第三层是业务面这是Agent存在的真正价值。比如队列积压数、最近五分钟的成功请求数、错误数、核心业务函数的执行耗时分位数这些指标往往需要从应用内部才能拿到。还有一个被很多人忽略的采集项时间戳本身。听起来很怪但我在实践里发现每个节点Agent上报系统当前时间配合计算该节点与监控服务器的时间偏差能非常有效地排查时间不同步导致的“幽灵告警”和各种日志时序错乱问题后面我会在踩坑清单里详细说。3.2 拉模式与推模式的设计取舍Prometheus pull 与 PushgatewayPrometheus的默认采集方式是从exporter的HTTP端口主动拉取metrics这就是“拉模式pull”。拉模式有一个直观的好处——监控端主动发起请求时能够感知目标节点的存活状态。如果某个目标连续几次拉取失败平台直接就能判定这个节点或服务异常了。如果是推模式pushAgent往服务端发数据服务端天然无法感知“某节点本来应该有数据但没来”的情况因为没有可靠机制判断是Agent挂了、网络断了还是只是数据还没到。这对“心跳类监控”很有价值比如你关心某个进程是否活着拉模式只要连续几次抓不到metrics端口就能告警简单可靠。所以长驻进程类指标我全部走拉模式。但拉模式有一个力不能及的场景短生命周期的任务。一个批量任务可能跑三分钟就退出了监控端还没到抓取周期任务已经没了。对于这类场景Prometheus官方推荐用Pushgateway做一个中转任务运行期间主动把指标推到PushgatewayPrometheus再从Pushgateway把数据拉走。实测下来觉得这个方式可用但有一个明显的坑——Pushgateway的指标带上了实例标签时间一长会积累大量“最后一次成功状态”的陈旧数据造成误判。我的处理方式很简单业务任务结束时会显式调用删除接口清理对应指标同时在Pushgateway侧配置定期清理。3.3 nmon在ARM64机器上的编译坑一次真实到访再来详细讲讲nmon在ARM64架构上的问题这个坑是我在一批国产ARM服务器上做性能摸底时踩到的。nmon官方源站默认提供的是x86平台编译好的二进制。直接把这台机器上能用的nmon拷贝到ARM64机器上大概率会得到“cannot execute binary file: Exec format error”。这个报错很直观架构不同二进制不能互通。解决思路有两个一是找发行版仓库里有没有编译好的。有些Linux发行版专门为ARM64架构准备了nmon包apt或者yum直接装上就能用。二是从nmon源码重新编译。如果走编译路线你会遇到一个比较隐蔽的问题。nmon的源码包里有makefile但makefile里的编译参数没有为ARM64做对应的配置调整尤其是对ncurses库的依赖。nmon的交互式界面依赖ncurses而源码目录里其实自带了一个裁剪过的ncurses副本但它的默认编译逻辑并不会自动启用这个副本。你需要先确认系统里安装了libncurses-dev然后修改makefile里相关平台的宏定义把它指向正确的Linux通用分支再用gcc重新编译。整个过程不算复杂但如果你不清楚“编译器报错找不到头文件”是因为库依赖没有配对就很容易被卡住。这个坑的启示是在混架构机房或者有国产化硬件诉求的环境里所有用到的单机排查工具都得提前做一次架构兼容性测试别等到故障发生时现场应急。我在那之后养成了一个习惯Agent和常用排查脚本的发布物里同时准备x86和ARM64两个版本并且每次上线前在两类机器上都跑一遍冒烟测试。3.4 接入HDFS这类大数据组件的监控维度如果你的分布式系统里跑着HDFS或类似的大数据组件监控维度还得往上一层走。HDFS的监控有一个常见误区只盯节点存活状态。实际上NameNode才是整个集群的大脑它的状态变化对集群影响是决定性的。我建议重点盯这么几个指标NameNode的Active/Standby状态及切换次数、FsImage加载与保存耗时、JVM堆内存使用率、DataNode的存活数与副本数。副本数低于配置阈值、DataNode出现批量离线、NameNode GC时间异常拉长这三件事任何一个发生都意味着集群走向不稳定。还要补充一个实操细节HDFS监控里很多关键指标需要从NameNode的JMX接口捞取而JMX接口本身有安全限制。建议在采集层做统一处理不要让每个监控Agent单独去连NameNode否则既不好管理权限也容易把NameNode的连接数打爆。通过一个集中的HDFS元数据采集器去轮询JMX再把采集结果暴露给Prometheus这样更可控。4. 时序数据与可视化监控大屏背后的存储与查询逻辑4.1 时序数据的存储选型从Prometheus本地存储到外部扩展Prometheus默认的本地存储是自研的TSDB设计得很精巧写入性能出色磁盘空间利用率高契合时序数据“以时间为索引的持续追加”这一特性。但本地存储有一个硬限制它不具备跨节点共享能力单机容量和保留时长都受限。指标量大了比如每秒采集几十万个样本点本地TSDB很快就会把磁盘吃掉然后你不得不在保留时长上做妥协数据只留七天或者更短。Prometheus官方给出的扩展方案是Thanos通过对象存储把历史区块做冷归档查询时再从远端拉回来。而VictoriaMetrics走的是另一条路——它自己就是完全兼容Prometheus查询协议的时序数据库性能和压缩比更好架设和运维也更简单。我在多个团队里看到VictoriaMetrics正在逐渐替代Thanos的位置稳定性口碑不错。对于中小规模的分布式系统我的建议是前期完全没必要上这套外部扩展直接用Prometheus本地存储将采集周期控制在15秒左右合理控制指标数量保留30天数据完全没问题。什么时候需要扩展当你发现指标写速率超过每秒一两万样本点或者希望做跨集群聚合查询时再引入VictoriaMetrics也不迟。第一版先跑通业务闭环比一步到位搭建重型存储架构重要得多这是很多团队容易陷入的误区。4.2 标签设计一个会反噬你的数据结构时序指标可以附带多个label标签比如ip、instance、service、cluster、job等。标签的价值在于多维度聚合查询但代价是每多一个取值组合就会生成一条独立的时间序列。这是高基数的核心逻辑也是分布式系统监控最容易踩的地雷。举个例子如果你把instance标签加到每条业务指标里一个指标对应100个实例就变成了100条序列。如果还有第二个标签“接口路径”且有3000个取值那就是30万条序列。Prometheus单个服务端能承受的时间序列规模是有限的一旦超过阈值查询性能和内存占用都会急剧恶化。这就是标签设计要控制基数的原因。我在设计采集指标时的原则是序列的数量级保持“业务接口×服务数”这个量级最多再乘一个小常数绝对不要拆到实例级别。需要按实例看数据时单独用node_exporter的基础指标去取不要把实例维度延伸到所有业务指标上。4.3 可视化大盘的“黄金四问”Grafana面板谁都会拖拽难的是让面板真正有用。我发现一种普遍现象团队里搭了十几张图表真故障发生了所有人还是不知道看哪里。问题的根源在于面板没有按“决策逻辑”来组织。我自己的经验是把大屏或常用dashboard的主题收敛成四个问题。第一个问题当前业务是否正常对应的是成功率、请求量、响应耗时的P99等业务指标。第二个问题系统容量水位在哪对应的是CPU、内存、磁盘、网络等资源使用率以及队列积压量这类中间件指标。第三个问题资源瓶颈是什么这一层要能下钻比如哪个节点磁盘I/O等待高哪台机器网络重传率高。第四个问题最近有没有异常信号对应的是错误日志量趋势、告警事件时间线、GC耗时等。这四个问题的背后对应着两个经典方法论一个是资源角度的USEUtilization、Saturation、Errors一个是应用角度的REDRate、Errors、Duration。我不建议你死记这两个缩写更推荐把方法论消化成“业务、资源、瓶颈、异常”四类图表每张图都要能回答这四类问题中的一个答不上来的图就是噪声宁可删掉也不要留着分散注意力。5. 告警规则与排障链路值班的人最需要的是什么5.1 告警疲劳与告警风暴为什么“多的告警”等于“没有告警”监控工具落地过程中失败风险最高的环节往往是告警规则设计。“规则写得少怕漏报规则写得多天天被误报轰炸”是每个值班人都会经历的痛苦。告警风暴的杀伤力在于它会摧毁信任。当值班人员连续一周每天收到三十条“CPU超过80%”的告警但每次进去看都没发生事故之后这个人就不会再认真对待告警了。真正的事故发生时告警同样混杂在其中被当成噪声忽略掉。这就是“狼来了”的故事在运维场景里真实存在且代价惨重。我的建议是遵循“症状优先原因靠后”的原则。告警应该关联用户可感知的症状而不是直接照搬系统原因。比如一个节点CPU使用率超过90%这本身不是告警充其量是参考信息。但如果这个节点的请求P99耗时同步飙升、错误率上升这才是需要告警的症状。反过来如果CPU高但业务指标一切正常说明系统还有余量可以在白天上班时间看情况处理完全没必要半夜打电话。5.2 告警规则的设计模板与通知结构这里给出几个我实际用过的告警规则范例你可以在此基础上改。服务心跳类groups: - name: service_availability rules: - alert: ServiceDown expr: up{jobmy-service} 0 for: 120s labels: severity: critical annotations: summary: 服务 {{ $labels.instance }} 心跳丢失超过2分钟 description: {{ $labels.instance }} 已无法被抓取请立即检查进程状态与网络连通性资源水位类- alert: DiskUsageHigh expr: (1 - node_filesystem_avail_bytes{fstype!~tmpfs|overlay} / node_filesystem_size_bytes{fstype!~tmpfs|overlay}) * 100 90 for: 10m labels: severity: warning annotations: summary: 实例 {{ $labels.instance }} 磁盘使用率超过90%HDFS关键项以DataNode离线为例- alert: HDFSDataNodeOffline expr: hdfs_datanode_live_nodes (hdfs_datanode_total_nodes - 1) for: 5m labels: severity: critical annotations: summary: HDFS DataNode 离线数量异常 description: 当前离线节点超过1个请检查DataNode进程与网络。这里有一个很容易犯的错for: 0s。意思是一旦表达式结果为真就立刻告警。短时抖动会带来非常多的重复告警我见过一个集群因为一个节点GC停顿导致抓取超时瞬间打出几十条告警的例子。经验是给每条规则都配上至少1到5分钟的for窗口用持续时间来过滤瞬时抖动可靠性会提高很多。5.3 一次故障告警到定位的完整链路我来完整拆解一次典型的故障处理流程你把这条链路看得越透越能理解告警设计的目标是什么。假设某个晚上告警弹出订单服务的成功率跌到90%级别是critical。值班人员点开这条告警首先看到的是时间线——告警开始的时刻、持续时长、当前严重级别。然后他打开Grafana的订单服务面板看到成功率下降的同时响应耗时的P99从200毫秒涨到了2秒这一组合基本说明不是逻辑错误而是链路拥堵或阻塞。下一步看关联的中间件面板发现消息队列的积压量正在快速上涨。此时定位点就收敛到了消费者。再看消费者服务所在节点的资源面板CPU不高但JVM的Old区GC耗时明显增加查看GC日志确认是大量长时间停顿。最后定位到根因消费者服务里有一段批量处理逻辑存在内存分配的突变导致频繁Full GC。从告警到根因整个过程用了大概15分钟。如果没有那套联动设计第一步看告警第二步查日志第三步猜方向第四步再猜下一跳传统人肉排查至少需要一个小时以上。告警系统设计得好能让值班人员在最短时间内把“系统哪里不正常”收敛到“大概是什么原因”。6. 落地配置参考与踩坑清单6.1 Prometheus采集配置的完整示例自研采集器暴露的metrics端口自身要解决两件事让Prometheus知道有哪些目标、让配置维护起来足够简单。给出一份可以直接用的scrape_config配置scrape_configs: - job_name: custom-agent metrics_path: /metrics scheme: http static_configs: - targets: - 10.0.0.11:9101 - 10.0.0.12:9101 - 10.0.0.13:9101 labels: cluster: prod-a role: app relabel_configs: - source_labels: [__address__] regex: (.*):9101 target_label: instance replacement: $1特地说一下relabel那段的作用。Prometheus一串下来会区分job、instance等内容。默认instance标签会把端口号也带进去如“10.0.0.11:9101”但很多查询场景下你并不关心端口把它单独拆出来能提高后续写PromQL的便利度。这个小处理在面板多起来之后能帮你避免大量重复写正则表达式。Grafana侧需要配数据源这一步基本是界面点点点就完成了。提醒一句别急着装一堆第三方面板插件先按照你自己的业务指标建模方式手动画两三张真正关心的图。从第三方导入的通用面板不一定匹配你的标签设计反而会造成理解偏差。6.2 采集器和监控平台运维的踩坑清单这里把我踩过、也看别人踩过的坑集中列出来每条都是真金白银换来的。时间不同步问题。分布式系统的监控日志、指标数据、告警时间必须对齐时间基准不一致就会出现“告警时间早于日志时间”“两个节点的CPU曲线错位”这类诡异现象。解决办法是在所有节点配置NTP服务并且在采集器里带上时间偏差指标偏差超过500毫秒就告警。这个简单操作能省下平均每天至少半小时的排障时间。监控自身的高可用问题。监控系统是为其他系统服务的但它自身也会挂。Prometheus单点部署就有单点故障风险至少要做到配置定期备份、数据目录用可靠磁盘、监控服务器本身的资源告警单独通知到另一个渠道。否则会出现“监控先挂了出事时没人知道”的最坏情况。磁盘被Prometheus数据写满问题。Prometheus的TSDB对磁盘空间的消耗比很多新手预期的要快得多。默认情况下它不会自动清理旧数据的优先级很高一旦磁盘写满整个服务端写入都会出现问题。建议在启动参数里明确数据保留时长把常用和长期两个场景分开处理同时给磁盘用量设一个独立的告警。PromQL标签匹配问题。写查询时如果标签的匹配不上返回的数据永远是空而且PromQL不像关系型数据库那样会给你报错看起来就像是系统里没有数据。这个问题的排查技巧是先用curl直接查看metrics输出确认标签名拼写再在Prometheus里用{jobxxx}做最小化查询逐步放宽条件。养成这个习惯能省下大量“明明有数据却查不到”的调试时间。6.3 监控工具后续演进从“有监控”到“能定位”搭建好这套体系只是第一步想把监控工具真正变成团队里的“系统状态说明书”还需要在流程上做几件事。第一是给每个服务建立变更与告警的关联机制。现在看来很多告警平白无故地出现查完才知道是之前上线的新版本带了问题。如果在发布流程里强制填写变更单并把变更时间轴叠加到监控时间线上值班人员点开告警时能立刻看到“这个服务15分钟前刚发过版本”定位速度又会快上一个量级。第二是沉淀故障分析文档。每解决一次线上事故就花半小时把告警链路、根因分析、处理过程写成一页纸的复盘。这个动作比任何监控调优都能更快提升团队的应急能力。如果你能做到两次同类事故的告警发现时间明显缩短这套监控体系的价值就已经远超投入的成本了。 
长河君 · 2026/10/14 7:51:59 · 阅读 1.2k 分布式系统监控工具选型与告警排障实战指南
1. 分布式系统中的监控困局瓶颈为什么总是最晚被发现先说一个我自己的真实经历。某天凌晨两点线上告警响起某核心服务的超时率从0.1%直接飙到30%。我第一反应是打开监控面板结果发现CPU、内存、磁盘、网络全部正常像什么都没发生过一样。然后我开始翻日志逐个服务查整整花了四十分钟才定位到是底层一个存储节点的磁盘I/O延迟异常其他节点看着都正常但那个节点的I/O等待已经高到让整个链路的上游全部排队。这个经历很典型。分布式系统和单机不一样事故的“表象”和“根因”常常隔着好几层。你在应用层看到的是超时往下查可能是消息队列积压再往下查可能是某个消费者线程卡住而那个消费者卡住的原因可能是它依赖的数据库连接池被耗尽了。这一整条链路只要中间有一个环节没有监控你就得靠猜。所以每次聊到“分布式系统监控工具”我的第一个观点都是它解决的不是“有没有数据”的问题而是“故障定位链路有多短”的问题。单机系统用top、df、free就够了因为所有资源都在一台机器上看得见摸得着。到了分布式系统几十上百个节点每个节点都有自己的CPU、内存、磁盘、网络、进程、端口同一时刻产生的数据量之庞大靠人肉翻看根本不可能。你需要一套工具把散落在各个节点上的数据自动化采集、集中存储、统一展示再在异常发生时把有价值的线索主动推送出来。这篇文章就是围绕这件事展开的。适合的技术人群很明确正在为自己的分布式系统搭建监控体系、面对一堆开源方案不知道选哪个、或者已经搭了Prometheus但总觉得没抓到重点的开发和运维同学。我会从选型逻辑、采集器设计、存储可视化、告警排障这几个维度把我踩过的坑和沉淀下来的实践讲透。这里先抛一个结论监控工具不是越贵越好也不是采集指标越多越好而是要让“系统是否健康”和“故障根因在哪”这两个问题能被快速回答。所有组件选型、所有采集项定义、所有告警规则设计都应该围绕这句话来展开。2. 工具选型的三条路线自研采集器、开源套件与单机工具的边界2.1 主流开源监控方案的选型逻辑现在的监控市场基本是几大流派。Prometheus Grafana是云原生时代的事实标准它的拉模式采集、多维标签数据模型、PromQL查询语法非常适合动态变化的容器环境和微服务架构。Zabbix是老牌监控系统擅长传统服务器、网络设备的指标采集和阈值告警机房里的物理机监控用得很广。还有OpenTSDB这类基于HBase的时序数据库方案早期大数据场景用得多但运维成本高现在新项目基本不碰了。这是指标监控的范畴另外还有链路追踪SkyWalking、Jaeger这些管的是请求从一个服务到另一个服务的完整调用链属于另一个维度。这中间有一个特别重要的认知没有一套工具能同时解决指标监控、日志监控和链路追踪三大问题。即便是有钱上商用APM全套也还是会留下自己业务特有的监控盲区。所以理性做法不是选一个“最全”的方案而是先划定边界——指标靠什么日志靠什么调用链靠什么业务自定义指标靠什么。我的边界划分是这样指标监控走Prometheus生态日志监控走ELK或者Loki链路追踪用SkyWalking。这三个东西分开部署、分开维护但会在告警通知里做联动。比如一条告警里带上“相关异常日志的搜索链接”和“该服务最近一段时间的调用链概况”这件事靠的就是告警通知模板和webhook的组装逻辑而不是把监控平台强行整合成一个。2.2 nmon这类单机工具的定位压测与精确定位场景还有一个流派容易被忽略就是nmon、top、perf这类传统单机工具。很多做分布式的人觉得有了Prometheus之后这些命令行工具就该退休了。我的实测经验恰恰相反在大量场景里nmon这类工具的精细度和即时性是平台替代不了的。举个例子你在压测一个分布式存储集群时总会有某个节点的表现和数据中心里其他节点差一大截。整个平台看下来可能只觉得“这个节点好像慢一点”但到底慢在哪nmon可以按秒甚至按更细粒度打出这个节点的CPU、内存、网络、磁盘I/O的每项明细而且不需要额外部署agent也不需要权限审批直接ssh上去跑一下就能看。这种“单点深挖”的能力是平台监控的有力补充。但nmon有一个比较现实的限制它默认只支持较短时间的高频采样长时间运行会产生大量文本文件需要配套分析脚本。还有二进制的兼容性问题尤其是ARM64架构的机器官方提供的预编译版本经常会直接跑不起来这个我下面专门展开说。所以我的定位是平台监控管常态单机工具管排查。后者不是替代品是最后一百米排查时的手持放大镜。2.3 为什么最终选择“自研采集器 Prometheus Grafana”组合选型这件事技术之外还要算成本账。Prometheus是开源免费的Grafana开源版功能也够用社区生态里各种exporter都能直接拿来用——node_exporter负责机器基础指标mysqld_exporter管数据库redis_exporter管缓存中间件。这些现成组件拼起来就能覆盖一个大面的场景。但拼完之后你会发现每个团队多少都有一些“只有自己才知道要监控什么”的东西。比如我们的业务里有一个重要的异步任务队列任务积压量直接决定系统健康度。这个指标任何开源exporter都给不了你得自己从业务代码里暴露出来。而如果仅仅为了这类自定义指标就上一个完整的自研监控平台成本实在太高了。所以我的路线是中间态用现成开源组件解决基础面用轻量级自研采集器解决定制面。自研的部分只是一个Agent程序负责定时抓取业务指标、特定进程状态、自定义探针结果然后通过Prometheus的exporter协议暴露给抓取端。听起来很复杂实际上就是一段几百行的采样逻辑。这个组合既保留了生态红利又拿到了定制灵活性算下来是性价比最高的。下面用一个表格快速对比几个方案方便你根据自己的场景对号入座方案优势劣势最适合场景Prometheus Grafana生态丰富云原生友好PromQL查询强大单机存储受限制高可用需要外部组件微服务、Kubernetes、云原生环境Zabbix传统服务器监控成熟告警机制完善数据模型不是时序库灵活度一般物理机、虚拟机、网络设备为主的环境OpenTSDB扩展性强擅长海量时序数据依赖HBase运维成本高查询能力弱历史遗留大数据平台SkyWalking链路追踪能力强无侵入接入不管指标和日志需要配套方案分布式调用链分析和拓扑发现自研Agent Prometheus精准覆盖业务自定义指标轻量可控需要自己写代码存在维护成本业务有独特监控诉求的团队nmon / top / perf单机即时排查零依赖信息密度高无集中存储长期采集需辅助脚本压测分析和单点故障深挖3. 采集器核心设计从指标定义到ARM64机器上的现实问题3.1 指标采集项如何定义基础面、进程面、业务面采集器最怕的是“什么都采”因为指标一多存储压力上来了查询变慢了还不一定有人看。我在设计这个Agent的时候把采集项严格分成三层。第一层是基础面CPU、内存、磁盘、网络这些直接用node_exporter已经覆盖了没必要重复造轮子。但我会在Agent里保留一个兜底逻辑——如果目标机器上不方便部署node_exporter比如某些临时起的小实例Agent自己就能承担这些基础采集。第二层是进程面采集指定进程是否存活、进程的CPU和内存占用、端口是否可以连通、句柄数是否逼近上限。这些是系统是否“活着”的直接证据。第三层是业务面这是Agent存在的真正价值。比如队列积压数、最近五分钟的成功请求数、错误数、核心业务函数的执行耗时分位数这些指标往往需要从应用内部才能拿到。还有一个被很多人忽略的采集项时间戳本身。听起来很怪但我在实践里发现每个节点Agent上报系统当前时间配合计算该节点与监控服务器的时间偏差能非常有效地排查时间不同步导致的“幽灵告警”和各种日志时序错乱问题后面我会在踩坑清单里详细说。3.2 拉模式与推模式的设计取舍Prometheus pull 与 PushgatewayPrometheus的默认采集方式是从exporter的HTTP端口主动拉取metrics这就是“拉模式pull”。拉模式有一个直观的好处——监控端主动发起请求时能够感知目标节点的存活状态。如果某个目标连续几次拉取失败平台直接就能判定这个节点或服务异常了。如果是推模式pushAgent往服务端发数据服务端天然无法感知“某节点本来应该有数据但没来”的情况因为没有可靠机制判断是Agent挂了、网络断了还是只是数据还没到。这对“心跳类监控”很有价值比如你关心某个进程是否活着拉模式只要连续几次抓不到metrics端口就能告警简单可靠。所以长驻进程类指标我全部走拉模式。但拉模式有一个力不能及的场景短生命周期的任务。一个批量任务可能跑三分钟就退出了监控端还没到抓取周期任务已经没了。对于这类场景Prometheus官方推荐用Pushgateway做一个中转任务运行期间主动把指标推到PushgatewayPrometheus再从Pushgateway把数据拉走。实测下来觉得这个方式可用但有一个明显的坑——Pushgateway的指标带上了实例标签时间一长会积累大量“最后一次成功状态”的陈旧数据造成误判。我的处理方式很简单业务任务结束时会显式调用删除接口清理对应指标同时在Pushgateway侧配置定期清理。3.3 nmon在ARM64机器上的编译坑一次真实到访再来详细讲讲nmon在ARM64架构上的问题这个坑是我在一批国产ARM服务器上做性能摸底时踩到的。nmon官方源站默认提供的是x86平台编译好的二进制。直接把这台机器上能用的nmon拷贝到ARM64机器上大概率会得到“cannot execute binary file: Exec format error”。这个报错很直观架构不同二进制不能互通。解决思路有两个一是找发行版仓库里有没有编译好的。有些Linux发行版专门为ARM64架构准备了nmon包apt或者yum直接装上就能用。二是从nmon源码重新编译。如果走编译路线你会遇到一个比较隐蔽的问题。nmon的源码包里有makefile但makefile里的编译参数没有为ARM64做对应的配置调整尤其是对ncurses库的依赖。nmon的交互式界面依赖ncurses而源码目录里其实自带了一个裁剪过的ncurses副本但它的默认编译逻辑并不会自动启用这个副本。你需要先确认系统里安装了libncurses-dev然后修改makefile里相关平台的宏定义把它指向正确的Linux通用分支再用gcc重新编译。整个过程不算复杂但如果你不清楚“编译器报错找不到头文件”是因为库依赖没有配对就很容易被卡住。这个坑的启示是在混架构机房或者有国产化硬件诉求的环境里所有用到的单机排查工具都得提前做一次架构兼容性测试别等到故障发生时现场应急。我在那之后养成了一个习惯Agent和常用排查脚本的发布物里同时准备x86和ARM64两个版本并且每次上线前在两类机器上都跑一遍冒烟测试。3.4 接入HDFS这类大数据组件的监控维度如果你的分布式系统里跑着HDFS或类似的大数据组件监控维度还得往上一层走。HDFS的监控有一个常见误区只盯节点存活状态。实际上NameNode才是整个集群的大脑它的状态变化对集群影响是决定性的。我建议重点盯这么几个指标NameNode的Active/Standby状态及切换次数、FsImage加载与保存耗时、JVM堆内存使用率、DataNode的存活数与副本数。副本数低于配置阈值、DataNode出现批量离线、NameNode GC时间异常拉长这三件事任何一个发生都意味着集群走向不稳定。还要补充一个实操细节HDFS监控里很多关键指标需要从NameNode的JMX接口捞取而JMX接口本身有安全限制。建议在采集层做统一处理不要让每个监控Agent单独去连NameNode否则既不好管理权限也容易把NameNode的连接数打爆。通过一个集中的HDFS元数据采集器去轮询JMX再把采集结果暴露给Prometheus这样更可控。4. 时序数据与可视化监控大屏背后的存储与查询逻辑4.1 时序数据的存储选型从Prometheus本地存储到外部扩展Prometheus默认的本地存储是自研的TSDB设计得很精巧写入性能出色磁盘空间利用率高契合时序数据“以时间为索引的持续追加”这一特性。但本地存储有一个硬限制它不具备跨节点共享能力单机容量和保留时长都受限。指标量大了比如每秒采集几十万个样本点本地TSDB很快就会把磁盘吃掉然后你不得不在保留时长上做妥协数据只留七天或者更短。Prometheus官方给出的扩展方案是Thanos通过对象存储把历史区块做冷归档查询时再从远端拉回来。而VictoriaMetrics走的是另一条路——它自己就是完全兼容Prometheus查询协议的时序数据库性能和压缩比更好架设和运维也更简单。我在多个团队里看到VictoriaMetrics正在逐渐替代Thanos的位置稳定性口碑不错。对于中小规模的分布式系统我的建议是前期完全没必要上这套外部扩展直接用Prometheus本地存储将采集周期控制在15秒左右合理控制指标数量保留30天数据完全没问题。什么时候需要扩展当你发现指标写速率超过每秒一两万样本点或者希望做跨集群聚合查询时再引入VictoriaMetrics也不迟。第一版先跑通业务闭环比一步到位搭建重型存储架构重要得多这是很多团队容易陷入的误区。4.2 标签设计一个会反噬你的数据结构时序指标可以附带多个label标签比如ip、instance、service、cluster、job等。标签的价值在于多维度聚合查询但代价是每多一个取值组合就会生成一条独立的时间序列。这是高基数的核心逻辑也是分布式系统监控最容易踩的地雷。举个例子如果你把instance标签加到每条业务指标里一个指标对应100个实例就变成了100条序列。如果还有第二个标签“接口路径”且有3000个取值那就是30万条序列。Prometheus单个服务端能承受的时间序列规模是有限的一旦超过阈值查询性能和内存占用都会急剧恶化。这就是标签设计要控制基数的原因。我在设计采集指标时的原则是序列的数量级保持“业务接口×服务数”这个量级最多再乘一个小常数绝对不要拆到实例级别。需要按实例看数据时单独用node_exporter的基础指标去取不要把实例维度延伸到所有业务指标上。4.3 可视化大盘的“黄金四问”Grafana面板谁都会拖拽难的是让面板真正有用。我发现一种普遍现象团队里搭了十几张图表真故障发生了所有人还是不知道看哪里。问题的根源在于面板没有按“决策逻辑”来组织。我自己的经验是把大屏或常用dashboard的主题收敛成四个问题。第一个问题当前业务是否正常对应的是成功率、请求量、响应耗时的P99等业务指标。第二个问题系统容量水位在哪对应的是CPU、内存、磁盘、网络等资源使用率以及队列积压量这类中间件指标。第三个问题资源瓶颈是什么这一层要能下钻比如哪个节点磁盘I/O等待高哪台机器网络重传率高。第四个问题最近有没有异常信号对应的是错误日志量趋势、告警事件时间线、GC耗时等。这四个问题的背后对应着两个经典方法论一个是资源角度的USEUtilization、Saturation、Errors一个是应用角度的REDRate、Errors、Duration。我不建议你死记这两个缩写更推荐把方法论消化成“业务、资源、瓶颈、异常”四类图表每张图都要能回答这四类问题中的一个答不上来的图就是噪声宁可删掉也不要留着分散注意力。5. 告警规则与排障链路值班的人最需要的是什么5.1 告警疲劳与告警风暴为什么“多的告警”等于“没有告警”监控工具落地过程中失败风险最高的环节往往是告警规则设计。“规则写得少怕漏报规则写得多天天被误报轰炸”是每个值班人都会经历的痛苦。告警风暴的杀伤力在于它会摧毁信任。当值班人员连续一周每天收到三十条“CPU超过80%”的告警但每次进去看都没发生事故之后这个人就不会再认真对待告警了。真正的事故发生时告警同样混杂在其中被当成噪声忽略掉。这就是“狼来了”的故事在运维场景里真实存在且代价惨重。我的建议是遵循“症状优先原因靠后”的原则。告警应该关联用户可感知的症状而不是直接照搬系统原因。比如一个节点CPU使用率超过90%这本身不是告警充其量是参考信息。但如果这个节点的请求P99耗时同步飙升、错误率上升这才是需要告警的症状。反过来如果CPU高但业务指标一切正常说明系统还有余量可以在白天上班时间看情况处理完全没必要半夜打电话。5.2 告警规则的设计模板与通知结构这里给出几个我实际用过的告警规则范例你可以在此基础上改。服务心跳类groups: - name: service_availability rules: - alert: ServiceDown expr: up{jobmy-service} 0 for: 120s labels: severity: critical annotations: summary: 服务 {{ $labels.instance }} 心跳丢失超过2分钟 description: {{ $labels.instance }} 已无法被抓取请立即检查进程状态与网络连通性资源水位类- alert: DiskUsageHigh expr: (1 - node_filesystem_avail_bytes{fstype!~tmpfs|overlay} / node_filesystem_size_bytes{fstype!~tmpfs|overlay}) * 100 90 for: 10m labels: severity: warning annotations: summary: 实例 {{ $labels.instance }} 磁盘使用率超过90%HDFS关键项以DataNode离线为例- alert: HDFSDataNodeOffline expr: hdfs_datanode_live_nodes (hdfs_datanode_total_nodes - 1) for: 5m labels: severity: critical annotations: summary: HDFS DataNode 离线数量异常 description: 当前离线节点超过1个请检查DataNode进程与网络。这里有一个很容易犯的错for: 0s。意思是一旦表达式结果为真就立刻告警。短时抖动会带来非常多的重复告警我见过一个集群因为一个节点GC停顿导致抓取超时瞬间打出几十条告警的例子。经验是给每条规则都配上至少1到5分钟的for窗口用持续时间来过滤瞬时抖动可靠性会提高很多。5.3 一次故障告警到定位的完整链路我来完整拆解一次典型的故障处理流程你把这条链路看得越透越能理解告警设计的目标是什么。假设某个晚上告警弹出订单服务的成功率跌到90%级别是critical。值班人员点开这条告警首先看到的是时间线——告警开始的时刻、持续时长、当前严重级别。然后他打开Grafana的订单服务面板看到成功率下降的同时响应耗时的P99从200毫秒涨到了2秒这一组合基本说明不是逻辑错误而是链路拥堵或阻塞。下一步看关联的中间件面板发现消息队列的积压量正在快速上涨。此时定位点就收敛到了消费者。再看消费者服务所在节点的资源面板CPU不高但JVM的Old区GC耗时明显增加查看GC日志确认是大量长时间停顿。最后定位到根因消费者服务里有一段批量处理逻辑存在内存分配的突变导致频繁Full GC。从告警到根因整个过程用了大概15分钟。如果没有那套联动设计第一步看告警第二步查日志第三步猜方向第四步再猜下一跳传统人肉排查至少需要一个小时以上。告警系统设计得好能让值班人员在最短时间内把“系统哪里不正常”收敛到“大概是什么原因”。6. 落地配置参考与踩坑清单6.1 Prometheus采集配置的完整示例自研采集器暴露的metrics端口自身要解决两件事让Prometheus知道有哪些目标、让配置维护起来足够简单。给出一份可以直接用的scrape_config配置scrape_configs: - job_name: custom-agent metrics_path: /metrics scheme: http static_configs: - targets: - 10.0.0.11:9101 - 10.0.0.12:9101 - 10.0.0.13:9101 labels: cluster: prod-a role: app relabel_configs: - source_labels: [__address__] regex: (.*):9101 target_label: instance replacement: $1特地说一下relabel那段的作用。Prometheus一串下来会区分job、instance等内容。默认instance标签会把端口号也带进去如“10.0.0.11:9101”但很多查询场景下你并不关心端口把它单独拆出来能提高后续写PromQL的便利度。这个小处理在面板多起来之后能帮你避免大量重复写正则表达式。Grafana侧需要配数据源这一步基本是界面点点点就完成了。提醒一句别急着装一堆第三方面板插件先按照你自己的业务指标建模方式手动画两三张真正关心的图。从第三方导入的通用面板不一定匹配你的标签设计反而会造成理解偏差。6.2 采集器和监控平台运维的踩坑清单这里把我踩过、也看别人踩过的坑集中列出来每条都是真金白银换来的。时间不同步问题。分布式系统的监控日志、指标数据、告警时间必须对齐时间基准不一致就会出现“告警时间早于日志时间”“两个节点的CPU曲线错位”这类诡异现象。解决办法是在所有节点配置NTP服务并且在采集器里带上时间偏差指标偏差超过500毫秒就告警。这个简单操作能省下平均每天至少半小时的排障时间。监控自身的高可用问题。监控系统是为其他系统服务的但它自身也会挂。Prometheus单点部署就有单点故障风险至少要做到配置定期备份、数据目录用可靠磁盘、监控服务器本身的资源告警单独通知到另一个渠道。否则会出现“监控先挂了出事时没人知道”的最坏情况。磁盘被Prometheus数据写满问题。Prometheus的TSDB对磁盘空间的消耗比很多新手预期的要快得多。默认情况下它不会自动清理旧数据的优先级很高一旦磁盘写满整个服务端写入都会出现问题。建议在启动参数里明确数据保留时长把常用和长期两个场景分开处理同时给磁盘用量设一个独立的告警。PromQL标签匹配问题。写查询时如果标签的匹配不上返回的数据永远是空而且PromQL不像关系型数据库那样会给你报错看起来就像是系统里没有数据。这个问题的排查技巧是先用curl直接查看metrics输出确认标签名拼写再在Prometheus里用{jobxxx}做最小化查询逐步放宽条件。养成这个习惯能省下大量“明明有数据却查不到”的调试时间。6.3 监控工具后续演进从“有监控”到“能定位”搭建好这套体系只是第一步想把监控工具真正变成团队里的“系统状态说明书”还需要在流程上做几件事。第一是给每个服务建立变更与告警的关联机制。现在看来很多告警平白无故地出现查完才知道是之前上线的新版本带了问题。如果在发布流程里强制填写变更单并把变更时间轴叠加到监控时间线上值班人员点开告警时能立刻看到“这个服务15分钟前刚发过版本”定位速度又会快上一个量级。第二是沉淀故障分析文档。每解决一次线上事故就花半小时把告警链路、根因分析、处理过程写成一页纸的复盘。这个动作比任何监控调优都能更快提升团队的应急能力。如果你能做到两次同类事故的告警发现时间明显缩短这套监控体系的价值就已经远超投入的成本了。