1. 项目背景为什么要做PLFM_RADAR先说说这个项目是怎么来的。我所在的团队维护着一个支撑多条业务线的平台系统简称PLFMPlatform的缩写核心服务包括统一网关、用户中心、订单服务、消息推送、文件存储等光核心模块就有十多个每个模块背后还挂着MySQL、Redis、Elasticsearch、RabbitMQ这些基础组件。早期线上出问题基本靠业务方反馈或者值班同事盯着几个监控页面来回切。这种情况持续了大半年中间踩过几次大坑最典型的一次是某个核心服务内存缓慢泄漏业务方比我们先发现问题——用户反馈订单超时我们才开始查日志、看监控、翻链路整整折腾了两个多小时才定位到是某个缓存组件连接未释放。类似的事发生多了团队内部达成一个共识不能再靠人去盯也不能等业务方来报障必须有一套主动感知、快速定位的系统。PLFM_RADAR就是在这套诉求下诞生的。简单来说它是一套面向PLFM平台所有核心模块及中间件的统一监控与告警系统。RADAR取雷达之意就是要把平台里里外外的运行状态全部扫到、扫清楚从应用层的接口响应、错误率到中间件的连接数、内存占用、慢查询再到底层主机的CPU、磁盘、网络一网打尽。系统能做到秒级采集、分钟级告警支持通过企微、邮件、短信三种方式触达值班人员目标是把「从故障发生到有人响应」的时间控制在1分钟以内。因为PLFM_RADAR不是一套从零开始的轮子它复用了不少开源生态的能力但也针对内部平台的实际情况做了相当多的定制开发。整个方案对中小团队自建监控体系很有参考价值尤其是那些被多个内部系统反复告警折磨、却又觉得商业APM太贵的团队。读完这篇文章你能搞清楚监控系统应该怎么搭、采哪些指标才不会白采、告警怎么配置才不会天天误报以及最常见的坑都长什么样。下文所有内容都是我在实际搭建和维护这套系统的过程中一步步验证过的。2. 整体设计思路与架构拆解2.1 需求盘点先把要监控的东西列全在设计PLFM_RADAR之前我们花了整整一周做了一件事盘点需要监控的对象。很多人做监控系统上来就装一套Prometheus Grafana把默认的Node Exporter跑起来以为万事大吉结果用了一周发现应用层的接口监控没有、业务指标的异常看不出来中间件的一些关键指标比如RabbitMQ的消息堆积、Redis的慢日志、MySQL的行锁等待也没采全告警规则更是不知道怎么配。我们按三层做了梳理这里整理成表格供参考层次监控对象核心指标示例采集方式应用层PLFM各核心服务QPS、P95/P99延迟、错误率、JVM内存、线程数、GC耗时Java Agent埋点 主动上报中间件层MySQL、Redis、ES、RabbitMQ、MinIO连接数、慢查询数、主从延迟、队列堆积量、索引命中率Exporter采集基础设施层物理机/容器CPU、内存、磁盘IO、网络带宽、磁盘占用率Node Exporter / cAdvisor有了这三层指标清单之后才能开始选型和动工。这一步做完后面的工作基本都是照方抓药。2.2 架构选型为什么没有直接用开源全家桶PLFM_RADAR在架构选型上经历了几轮内部讨论。最初有人提过直接用Prometheus Operator Grafana Alertmanager这一套组合理由很充分开源、社区活跃、资料多、部署也方便。这个方案我们不是没考虑过但在实际推演之后发现三个问题。第一Prometheus默认的Pull模型在跨网络区域、跨防火墙的采集场景下有天然的短板。我们的部分中间件服务和主机分布在不同的网段安全策略不允许监控节点直接去访问所有目标端口这就意味着要么改造网络策略要么就得在采集端和目标端都做额外的代理。第二Prometheus的告警规则对动态阈值支持不友好比如一个接口平时的P99是100毫秒双十一大促期间变成500毫秒其实是正常的但用固定阈值一条规则这种场景要么漏报要么误报成山。第三我们需要的很多业务指标比如某个用户批量任务的积压量、某个供应商接口的调用成功率需要从业务代码里主动上报这也不是标准Exporter能覆盖的。所以最终PLFM_RADAR采用了推拉结合的混合架构。所谓的「推」是应用层服务通过一个自研的Metric SDK定期把业务指标和运行指标推到统一的采集服务所谓的「拉」是中间件层和基础设施层仍然由采集器定期去目标端点抓取标准指标。这个设计的好处很明显业务指标可以覆盖到代码级的复杂度而通用指标又不用重复造轮子两边互补。2.3 核心链路从采集到告警的完整通路PLFM_RADAR的数据链路可以分成五段按顺序分别是采集端 - 消息缓冲 - 实时计算 - 存储 - 告警与展示。采集端有两类角色。一类是部署在各个业务服务内的SDK采用异步上报方式数据先写本地环形缓冲区由独立线程批量发送避免对业务线程产生阻塞。另一类是部署在中间件主机上的Exporter进程默认15秒拉一次目标端点的指标再暴露给采集器。统一采集服务收到数据后不直接入库而是写入Kafka做缓冲。这里用Kafka而不是直接写时序库主要考虑两个点一是削峰填谷大促或故障期间指标量会瞬间翻倍直接入库容易把存储打爆Kafka可以缓冲一段时间消费端可以根据压力动态调整消费速度二是多消费者复用同一个指标流实时计算引擎要看离线数仓也要落一份通过Kafka可以一份数据多个下游消费互不干扰。实时计算引擎负责做几件事一是降采样把秒级数据聚合成分钟级、小时级的数据二是跑阈值规则判断是否触发告警三是做简单的异常检测比如环比突增突降、持续超过N分钟等。告警判断的结果通过告警管道分发给企微机器人、邮件网关和短信网关。存储层用的是ClickHouse加Redis的组合。ClickHouse管指标数据的持久化按天分区TTL策略保留30天原始数据再往后保留聚合数据Redis用于存最近一小时的实时指标供大屏和即时查询使用查最近一分钟的指标曲线直接打Redis毫秒级返回。整体架构拆解完直接进代码。下面是我在实际搭建过程中的核心实现每一步都标明了对应的文件和关键参数。3. 核心模块实现与关键代码解析3.1 采集端SDK业务指标怎么以最低成本上报应用层的指标采集是PLFM_RADAR里改动最大的一个模块因为要侵入业务代码所以必须做到对业务几乎零侵入。我们选型时对比过Micrometer、Dropwizard Metrics和自研SDK。前两个的优势是社区成熟、指标类型丰富但对我们的团队来说自定义指标太繁琐而且要引入额外的依赖最终我们做了一个非常轻量的SDK只暴露三个核心类。核心设计是采用单例的MetricRegistry内部维护一个线程安全的ConcurrentHashMap键是指标名值是计数器或采样窗口。所有采集线程共用一个调度器默认每10秒上报一次。为了避免SDK初始化时的配置散落在各个业务系统配置项统一走环境变量和配置文件两处读取环境变量优先。来看核心实现我简化掉了一些边缘逻辑保留主干public class MetricSDK { private static final MetricRegistry REGISTRY new MetricRegistry(); private static final ScheduledExecutorService SCHEDULER Executors.newSingleThreadScheduledExecutor( new NamedThreadFactory(plfm-metric-sdk) ); static { String appName ConfigResolver.getString(plfm.app.name, unknown); String reportUrl ConfigResolver.getString(plfm.metric.report.url, http://localhost:8080/metrics/report); int periodSeconds ConfigResolver.getInt(plfm.metric.report.period, 10); SCHEDULER.scheduleWithFixedDelay(() - { MapString, Double snapshot REGISTRY.snapshot(); if (snapshot.isEmpty()) { return; } ReportRequest request new ReportRequest(); request.setAppName(appName); request.setHostIp(IpUtil.getLocalIp()); request.setTimestamp(System.currentTimeMillis()); request.setMetrics(snapshot); asyncReport(request, reportUrl); }, periodSeconds, periodSeconds, TimeUnit.SECONDS); } // 记录调用次数和耗时按接口维度聚合 public static void recordInvoke(String apiName, long costMillis) { REGISTRY.incrementCounter(api.invoke.count, apiName); REGISTRY.recordLatency(api.invoke.cost, apiName, costMillis); } }这段代码里有两个容易被忽略的重点。第一个是上报时间间隔的选择10秒在绝大多数的监控场景中够用了如果设置成1秒Kafka的Topic分区数、ClickHouse的写入并发都要跟着翻倍成本很高收益却很小。第二个是asyncReport内部使用的是有界队列加丢弃策略队列满了直接丢弃最新的上报批次绝不让上报逻辑阻塞业务线程池。实测下来SDK对业务接口的平均时延影响在0.1毫秒以内在可接受范围内。数据到了采集服务之后会做一次字段规整把同一应用上报的指标按时间戳对齐再写入Kafka。这里特别处理了一种情况业务实例重启后本地时钟可能偏差几百毫秒上报的时间戳如果不做校准后面实时计算出的指标曲线会出现毛刺。我们的做法是采集服务收到数据后对时间戳和自身服务器时间做差超过2秒的按采集服务时间替代。3.2 中间件与主机指标采集Exporter的选型与参数调优中间件和主机的采集本质上是把业界成熟的Exporter接进来但真正落地时细节特别多。PLFM_RADAR当前使用的Exporter清单如下目标Exporter关键采集参数Linux主机node_exporter默认端口9100开启systemd、filesystem、network统计MySQLmysqld_exporter采集慢查询、连接数、InnoDB行锁、主从状态Redisredis_exporter采集内存、键数、慢日志、客户端连接数Elasticsearchelasticsearch_exporter采集集群状态、分片数、查询延迟、JVM堆RabbitMQrabbitmq_exporter采集队列堆积、消费速率、连接数MinIOminio_exporter社区版采集桶容量、请求延迟、错误码分布这里边有一个选型上的经验RabbitMQ官方自带的管理API可以输出JSON格式的指标数据但需要额外写脚本去解析效率低且格式不稳定社区版的RabbitMQ Exporter反而更成熟安装即用。Exporter的部署方式也统一做了约定直接以Systemd服务跑在目标主机上而不是放在容器里。原因是这些中间件服务器本身没有部署容器运行时为了一个Exporter单独装一套容器环境得不偿失。每个Exporter的端口统一注册到Prometheus的ServiceDiscovery中由采集器动态发现。参数上有一个比较重要的坑mysqld_exporter默认会采集全量库表的processlist信息在实例数量多、并发大的库上采集本身会带来额外的性能开销实测高峰期会造成主库CPU增加5%左右。解决方案是配置只采集information_schema.processlist中非Sleep状态的连接同时把采集时间间隔从默认的5秒调大到15秒。这个调整需要反复压测我们最后定在15秒是因为这个频率足够发现连接数突增的异常又不会给数据库带来明显压力。3.3 实时计算引擎告警规则怎么设计才不误报采集上来的数据经过Kafka进入实时计算引擎后就轮到告警规则的战场了。PLFM_RADAR的告警规则沉淀了三个版本第一版是最原始的固定阈值规则第二版加了持续时间和环比第三版加入动态基线和事件关联。三个版本的迭代过程就是不断和误报、漏报斗争的过程。固定阈值规则的设计相对直观但参数怎么定很有讲究。拿接口P99延迟来说阈值不能简单地定一个「拍脑袋数」我们的做法是取过去7天同一时刻指标值的分位数乘以一个系数比如1.5倍或2倍作为动态的告警基线。误差容忍度设置了三个档P99超过基线的1.5倍持续5分钟触发Warning超过2倍持续5分钟触发Critical超过2倍持续15分钟触发Page。不同严重级别的告警触达方式不一样Warning只发企微Critical才发邮件和短信Page则直接打电话。这套分级机制让值班人员的注意力真正聚焦在重要问题上。再来看实时计算的代码逻辑这里以滑动窗口实现为例public class SlidingWindowDetector { private static final int WINDOW_SIZE 30; private final RingBufferDouble buffer new RingBuffer(WINDOW_SIZE); public synchronized AlertResult evaluate(double value, double baseline) { buffer.add(value); int overCount 0; for (double v : buffer.values()) { if (v baseline * 1.5) { overCount; } } double overRatio (double) overCount / buffer.size(); // 窗口内超过70%的数据点越过基线则触发 if (overRatio 0.7) { return new AlertResult(true, Severity.WARNING); } return new AlertResult(false, null); } }这段代码里用环形缓冲区保存最近30个数据点每个点代表一个计算周期的指标值。只有当窗口内70%的点都越线时才算告警这种设计能过滤掉偶发的瞬时毛刺。结合Kafka的实时流整个引擎的吞吐量实测可以达到每秒处理250万条指标记录这个量级应对当前平台规模绰绰有余。4. 从零搭建PLFM_RADAR完整实操流程4.1 第一步部署时序存储与消息队列存储层是整个系统的基础最先落地。ClickHouse的部署我用的单机模式配置如下足够支撑千万级指标日增量# /etc/clickhouse-server/config.d/plfm.xml clickhouse profiles default max_execution_time60/max_execution_time max_memory_usage8000000000/max_memory_usage /default /profiles storage_configuration disks default path/data/clickhouse//path /default /disks /storage_configuration /clickhouse建表语句是针对指标场景优化的使用MergeTree引擎按天分区排序键选择(app_name, metric_name, timestamp)。这个组合能保证按应用和指标名查询时ClickHouse只需要扫描少量分区查询响应时间从没超过2秒。Kafka则用的标准3节点集群Topic按指标类型拆分比如metric-app、metric-middleware、metric-infra分区数统一设置为12。分区的数量不是越大越好每个分区对应一个消费线程分区数超过消费端并发数后多余的分区会闲置白占磁盘和内存。12个分区在当前的消费并发下刚好能打满实测生产峰值时处理延迟一直稳定在3秒以下。4.2 第二步搭建采集链路与实时计算服务采集链路由两个服务组成。第一个是collector-service负责接收业务SDK通过HTTP Push上报的指标然后做格式校验写入Kafka第二个是scraper-service负责定时从Exporter端点拉取指标然后同样写入Kafka。直接看collector-service接收数据的关键逻辑这段代码踩过了不少坑RestController public class MetricCollectController { PostMapping(/metrics/report) public ResponseEntityVoid report(RequestBody ReportRequest request) { // 1. 时间戳校准避免业务机器时钟偏差 long serverTime System.currentTimeMillis(); long gap Math.abs(serverTime - request.getTimestamp()); if (gap 2000) { request.setTimestamp(serverTime); } // 2. 指标名合法性校验防注入和脏数据 for (String metricName : request.getMetrics().keySet()) { if (!metricName.matches(^[a-zA-Z][a-zA-Z0-9_.-]{0,127}$)) { request.getMetrics().remove(metricName); } } // 3. 写入Kafka异步非阻塞 kafkaTemplate.send(metric-app, request.getAppName(), request); return ResponseEntity.ok().build(); } }这个接口里有一个细节值得展开。第2步的正则校验不是形式主义。早期我们遇到过业务方在指标名里拼上了用户ID比如api.invoke.count.user_10231虽然单次上报没多大事但长此以往指标基数会爆炸式增长同一个接口可能出现几万个不同用户ID的指标序列ClickHouse的存储膨胀非常快查询也会越拖越慢。加了正则白名单之后指标名只能是固定的业务域加固定的接口标识从源头上控制了基数。scraper-service的抓取任务我用的是Quartz调度框架每个抓取任务对应一个Exporter端点调度表达式统一为每15秒执行一次。抓到的数据经过Prometheus文本格式解析后转换成内部统一的数据模型再写入Kafka。这里有一个天然的优势Prometheus的文本格式里自带job和instance标签我们直接利用这两个标签区分不同的中间件实例和主机。4.3 第三步配置Grafana看板与告警触达PLFM_RADAR的展示层直接用的Grafana因为团队对这套系统已经非常熟悉而且它与ClickHouse有官方插件无需额外适配。看板的组织方式按层级划分总览页、应用页、中间件页、基础设施页。总览页放了几个核心面板整体QPS曲线、错误率、当前告警数量、关键接口P99耗时排行。中间件页则按每个组件单独一个Folder比如MySQL页面放了连接数、慢查询数、主从延迟、缓冲池命中率四块面板。每个面板都配了告警跳转链接点击直接跳到对应的告警详情页省去排查时上下文切换的时间。告警触达分三个渠道企微机器人、邮件、短信网关。企微机器人用的是群机器人Webhook直接在群聊里推送告警卡片卡片里带上故障时间、指标名、当前值、基线值、持续时间、应用负责人姓名。邮件的发送频率做了限制同一告警规则在同一个小时内最多发送5条防止某条规则异常时邮件轰炸。短信网关只在Critical级别触发由实时计算引擎直接调用。这套告警触达机制经过半年的打磨稳定性已经比较可靠。最头疼的一次是企微机器人Webhook链接被误删导致告警全部静默了一个多小时后来我们在告警通道上增加了一个健康检查每5分钟ping一次各通道的连通性确保通道故障能第一时间被发现。5. 告警治理从告警风暴到告警收敛采集、存储和展示跑通之后PLFM_RADAR面临了一个更棘手的问题告警太多。每天少则三四十条多则上百条。告警多了之后值班人员会产生疲劳开始忽略告警真正关键的问题反而被淹没。为了整治这个现象我们专门做了一轮告警治理核心思路就六个字合并、去重、收敛。5.1 告警合并把同类告警聚到一起先说合并。典型的场景是某台数据库主机磁盘满了这个故障会同时触发出多条告警磁盘使用率告警、临时表空间不足告警、慢SQL增多告警、部分查询超时告警。如果按规则逐条推送值班人员在一个故障窗口内会收到4条不同的告警消息操作上需要一条条确认还容易漏掉最重要的那条根因告警。PLFM_RADAR的告警合并策略是按「故障对象」和「时间窗口」两个维度做。同一个应用或同一台主机在15分钟内触发的所有告警聚合成一条告警事件事件内展示该对象的全部异常指标并自动识别置信度最高的根因指标置顶。这个功能的实现不复杂就是在告警引擎里加了一个聚合器按对象窗口维度做分组窗口结束后统一发送。5.2 告警去重与抑制消除重复噪音告警去重针对的是同一指标持续性越线的场景。比如一个接口P99持续超过基线一小时固定阈值规则每分钟都会触发一次告警如果不做去重一小时内会产生60条告警消息。我们的做法是同一告警规则在同一恢复周期内只发送一条告警状态变更消息从正常变为告警时发一条恢复时再发一条。中间状态的变化比如Warning升级为Critical单独发一条升级通知。这样一轮故障下来最多三条消息清晰明了。告警抑制解决的是上下级故障的关联噪音问题。一个典型的场景网关服务故障导致大量下游接口返回504这时下游服务的错误率告警也会被触发。实际上下游服务本身没有问题完全是被网关连累的。如果不做抑制一个根因故障会产生十几条子告警。我们配置了全局的依赖关系拓扑标识了每个服务依赖的上游服务。当上游服务处于Critical状态时下游服务产生的同时间段告警自动降级为静默状态只在告警详情里作为关联事件展示不推送消息。5.3 告警规则的自省机制持续优化规则质量告警规则不是配完就一劳永逸的需要伴随系统的演进不断调整。PLFM_RADAR建立了一个很简单但有效的机制每周一早上有一个「告警周报」统计上周所有告警事件的详情人工复核每一条告警是否有价值。有价值的标准是这条告警是否推动了实际的处理动作如果连续两周都没有产生任何处理动作这条规则就被标记为「待优化」或「建议下线」。运营了几个月之后我们的告警量显著下降每天的活跃告警稳定控制在个位数同时漏报率也降低了。这个结果的核心不在于技术多高明而在于持续的复盘循环。告警治理不是一次性工程它是一个持续迭代的过程。6. 常见问题与排查技巧实录6.1 采集数据缺失或延迟有段时间我们收到反馈说Grafana上看不到某个应用的指标曲线。排查的第一步是看采集服务的日志确认有没有收到该应用的SDK上报请求。如果采集服务没收到数据大概率是SDK配置的问题如果采集服务收到了但Grafana没有数据则要看Kafka的消费链路是否卡住。实际上我们最后定位到的原因是SDK初始化时读取配置文件失败触发了默认值加载上报到了默认的本地地址导致数据一直没有发出来。这个问题的教训是SDK在启动阶段应有明确的配置检查发现无法解析上报地址时打一条醒目的错误日志而不是静默使用默认值。如果你也遇到数据缺失可以按这个顺序排查先看采集服务最近10分钟的日志里有没有对应应用的请求记录。再看Kafka的Topic消费延迟消费组是否卡住。然后看实时计算引擎中的指标接收计数是否在增加。最后查ClickHouse对应表的最新写入时间。这个顺序从上游查到下游能快速定位是链路哪一段出了问题。6.2 告警风暴一次大促引发的血案第一次双十一大促PLFM_RADAR的告警消息几乎刷屏了。原因很简单大促流量是平时的5倍所有基于固定阈值的告警规则全部被触发而且大部分是「假告警」因为业务的承载能力是经过压测的流量大涨并不代表系统有故障。那次之后我们把所有核心业务指标都切换到了动态基线模式。动态基线的计算逻辑是取过去14天同一时间点前后15分钟的数据作为样本计算P50和P90用P90乘以系数作为告警阈值。同时增加了一个「大促模式」的全局开关开启后告警阈值自动放宽为平时的2倍同时告警合并窗口从15分钟调整为5分钟有效减少了告警消息的数量。这个经验教训很值得分享监控系统不能和业务形态脱节。固定阈值只适合容量规划已经明确、上线后不会大范围变动的指标。凡是会随着业务节奏波动幅度大的指标强烈建议用动态基线。6.3 ClickHouse查询变慢索引与分区设计的调整PLFM_RADAR上线运行一个月后某些查询出现了变慢的情况特别是「查询某应用一天的所有指标原始曲线」这类请求响应时间从秒级退化到十几秒。排查后发现问题出在分区键和排序键的设计上。初版建表时排序键用的是(metric_name, timestamp)当查询按应用过滤时ClickHouse需要扫描所有分区中该应用的数据块无法有效利用分区裁剪。调整后的排序键改为(app_name, metric_name, timestamp)同时把分区改为按月分区。实测同样的查询响应时间从12秒降到0.8秒。这个调整告诉我们ClickHouse的表设计一定要基于实际查询模式不能想当然。6.4 时间不同步导致的数据错乱监控系统对时间非常敏感。有一台Redis的Exporter部署的宿主机时钟漂移了约3分钟导致采集上来的指标时间戳一直比真实时间慢3分钟。在实时告警检测中窗口滑动判断使用的是采集服务接收到数据时的处理时间而这台机器的数据时间戳永远是旧的于是这个Redis的告警判断总是慢半拍还出现过一次误告警。解决方案分两层。第一层是在所有采集目标主机上启用NTP同步并且配置了定时校验每天检查一次时间偏移量超过1秒就告警。第二层是在采集链路中对所有Exporter采集的数据统一以采集服务的服务器时间作为数据时间戳忽略目标机的时间。这里有一个注意点对于SDK上报的应用指标时间戳必须以业务请求发生的实际时间为准不能用采集服务接收时间代替否则请求延迟的统计就完全失真了。7. 最后再分享一点实际的体会PLFM_RADAR从立项到稳定运行前后花了差不多两个月的时间。如果让我重新做一次我依然会坚持三个选择第一业务指标必须用主动推的方式采集被动拉取永远无法覆盖代码级的洞察第二告警收敛必须在一开始就做而不是等告警风暴来了再补救第三动态基线的投入产出比远高于固定阈值尤其对业务形态长期波动的系统。还有一个小技巧是我在踩过多次坑之后总结的监控系统的验收标准不能用「能出图」来衡量而要用故障演练来验证。我们每季度会做一次主动故障注入比如手动杀掉一个核心服务、把某个中间件连接数突增到正常值的10倍然后观察PLFM_RADAR能否在1分钟内发现、2分钟内告警、5分钟内定位到根因。这套演练机制比任何监控页面上的数字更真实。如果你的团队也在规划一套类似的监控平台我的建议很简单不要一上来就追求大而全先把最核心的应用层指标和告警链路跑通中间件的指标逐步接入告警规则从少到多慢慢积累。一套好的监控系统不是从文档里写出来的是跟着真实故障一起长出来的。PLFM_RADAR到现在还有很多不完善的地方但每一次线上故障它都能帮我们缩短排查时间这就是它最重要的价值。
1. 项目背景为什么要做PLFM_RADAR先说说这个项目是怎么来的。我所在的团队维护着一个支撑多条业务线的平台系统简称PLFMPlatform的缩写核心服务包括统一网关、用户中心、订单服务、消息推送、文件存储等光核心模块就有十多个每个模块背后还挂着MySQL、Redis、Elasticsearch、RabbitMQ这些基础组件。早期线上出问题基本靠业务方反馈或者值班同事盯着几个监控页面来回切。这种情况持续了大半年中间踩过几次大坑最典型的一次是某个核心服务内存缓慢泄漏业务方比我们先发现问题——用户反馈订单超时我们才开始查日志、看监控、翻链路整整折腾了两个多小时才定位到是某个缓存组件连接未释放。类似的事发生多了团队内部达成一个共识不能再靠人去盯也不能等业务方来报障必须有一套主动感知、快速定位的系统。PLFM_RADAR就是在这套诉求下诞生的。简单来说它是一套面向PLFM平台所有核心模块及中间件的统一监控与告警系统。RADAR取雷达之意就是要把平台里里外外的运行状态全部扫到、扫清楚从应用层的接口响应、错误率到中间件的连接数、内存占用、慢查询再到底层主机的CPU、磁盘、网络一网打尽。系统能做到秒级采集、分钟级告警支持通过企微、邮件、短信三种方式触达值班人员目标是把「从故障发生到有人响应」的时间控制在1分钟以内。因为PLFM_RADAR不是一套从零开始的轮子它复用了不少开源生态的能力但也针对内部平台的实际情况做了相当多的定制开发。整个方案对中小团队自建监控体系很有参考价值尤其是那些被多个内部系统反复告警折磨、却又觉得商业APM太贵的团队。读完这篇文章你能搞清楚监控系统应该怎么搭、采哪些指标才不会白采、告警怎么配置才不会天天误报以及最常见的坑都长什么样。下文所有内容都是我在实际搭建和维护这套系统的过程中一步步验证过的。2. 整体设计思路与架构拆解2.1 需求盘点先把要监控的东西列全在设计PLFM_RADAR之前我们花了整整一周做了一件事盘点需要监控的对象。很多人做监控系统上来就装一套Prometheus Grafana把默认的Node Exporter跑起来以为万事大吉结果用了一周发现应用层的接口监控没有、业务指标的异常看不出来中间件的一些关键指标比如RabbitMQ的消息堆积、Redis的慢日志、MySQL的行锁等待也没采全告警规则更是不知道怎么配。我们按三层做了梳理这里整理成表格供参考层次监控对象核心指标示例采集方式应用层PLFM各核心服务QPS、P95/P99延迟、错误率、JVM内存、线程数、GC耗时Java Agent埋点 主动上报中间件层MySQL、Redis、ES、RabbitMQ、MinIO连接数、慢查询数、主从延迟、队列堆积量、索引命中率Exporter采集基础设施层物理机/容器CPU、内存、磁盘IO、网络带宽、磁盘占用率Node Exporter / cAdvisor有了这三层指标清单之后才能开始选型和动工。这一步做完后面的工作基本都是照方抓药。2.2 架构选型为什么没有直接用开源全家桶PLFM_RADAR在架构选型上经历了几轮内部讨论。最初有人提过直接用Prometheus Operator Grafana Alertmanager这一套组合理由很充分开源、社区活跃、资料多、部署也方便。这个方案我们不是没考虑过但在实际推演之后发现三个问题。第一Prometheus默认的Pull模型在跨网络区域、跨防火墙的采集场景下有天然的短板。我们的部分中间件服务和主机分布在不同的网段安全策略不允许监控节点直接去访问所有目标端口这就意味着要么改造网络策略要么就得在采集端和目标端都做额外的代理。第二Prometheus的告警规则对动态阈值支持不友好比如一个接口平时的P99是100毫秒双十一大促期间变成500毫秒其实是正常的但用固定阈值一条规则这种场景要么漏报要么误报成山。第三我们需要的很多业务指标比如某个用户批量任务的积压量、某个供应商接口的调用成功率需要从业务代码里主动上报这也不是标准Exporter能覆盖的。所以最终PLFM_RADAR采用了推拉结合的混合架构。所谓的「推」是应用层服务通过一个自研的Metric SDK定期把业务指标和运行指标推到统一的采集服务所谓的「拉」是中间件层和基础设施层仍然由采集器定期去目标端点抓取标准指标。这个设计的好处很明显业务指标可以覆盖到代码级的复杂度而通用指标又不用重复造轮子两边互补。2.3 核心链路从采集到告警的完整通路PLFM_RADAR的数据链路可以分成五段按顺序分别是采集端 - 消息缓冲 - 实时计算 - 存储 - 告警与展示。采集端有两类角色。一类是部署在各个业务服务内的SDK采用异步上报方式数据先写本地环形缓冲区由独立线程批量发送避免对业务线程产生阻塞。另一类是部署在中间件主机上的Exporter进程默认15秒拉一次目标端点的指标再暴露给采集器。统一采集服务收到数据后不直接入库而是写入Kafka做缓冲。这里用Kafka而不是直接写时序库主要考虑两个点一是削峰填谷大促或故障期间指标量会瞬间翻倍直接入库容易把存储打爆Kafka可以缓冲一段时间消费端可以根据压力动态调整消费速度二是多消费者复用同一个指标流实时计算引擎要看离线数仓也要落一份通过Kafka可以一份数据多个下游消费互不干扰。实时计算引擎负责做几件事一是降采样把秒级数据聚合成分钟级、小时级的数据二是跑阈值规则判断是否触发告警三是做简单的异常检测比如环比突增突降、持续超过N分钟等。告警判断的结果通过告警管道分发给企微机器人、邮件网关和短信网关。存储层用的是ClickHouse加Redis的组合。ClickHouse管指标数据的持久化按天分区TTL策略保留30天原始数据再往后保留聚合数据Redis用于存最近一小时的实时指标供大屏和即时查询使用查最近一分钟的指标曲线直接打Redis毫秒级返回。整体架构拆解完直接进代码。下面是我在实际搭建过程中的核心实现每一步都标明了对应的文件和关键参数。3. 核心模块实现与关键代码解析3.1 采集端SDK业务指标怎么以最低成本上报应用层的指标采集是PLFM_RADAR里改动最大的一个模块因为要侵入业务代码所以必须做到对业务几乎零侵入。我们选型时对比过Micrometer、Dropwizard Metrics和自研SDK。前两个的优势是社区成熟、指标类型丰富但对我们的团队来说自定义指标太繁琐而且要引入额外的依赖最终我们做了一个非常轻量的SDK只暴露三个核心类。核心设计是采用单例的MetricRegistry内部维护一个线程安全的ConcurrentHashMap键是指标名值是计数器或采样窗口。所有采集线程共用一个调度器默认每10秒上报一次。为了避免SDK初始化时的配置散落在各个业务系统配置项统一走环境变量和配置文件两处读取环境变量优先。来看核心实现我简化掉了一些边缘逻辑保留主干public class MetricSDK { private static final MetricRegistry REGISTRY new MetricRegistry(); private static final ScheduledExecutorService SCHEDULER Executors.newSingleThreadScheduledExecutor( new NamedThreadFactory(plfm-metric-sdk) ); static { String appName ConfigResolver.getString(plfm.app.name, unknown); String reportUrl ConfigResolver.getString(plfm.metric.report.url, http://localhost:8080/metrics/report); int periodSeconds ConfigResolver.getInt(plfm.metric.report.period, 10); SCHEDULER.scheduleWithFixedDelay(() - { MapString, Double snapshot REGISTRY.snapshot(); if (snapshot.isEmpty()) { return; } ReportRequest request new ReportRequest(); request.setAppName(appName); request.setHostIp(IpUtil.getLocalIp()); request.setTimestamp(System.currentTimeMillis()); request.setMetrics(snapshot); asyncReport(request, reportUrl); }, periodSeconds, periodSeconds, TimeUnit.SECONDS); } // 记录调用次数和耗时按接口维度聚合 public static void recordInvoke(String apiName, long costMillis) { REGISTRY.incrementCounter(api.invoke.count, apiName); REGISTRY.recordLatency(api.invoke.cost, apiName, costMillis); } }这段代码里有两个容易被忽略的重点。第一个是上报时间间隔的选择10秒在绝大多数的监控场景中够用了如果设置成1秒Kafka的Topic分区数、ClickHouse的写入并发都要跟着翻倍成本很高收益却很小。第二个是asyncReport内部使用的是有界队列加丢弃策略队列满了直接丢弃最新的上报批次绝不让上报逻辑阻塞业务线程池。实测下来SDK对业务接口的平均时延影响在0.1毫秒以内在可接受范围内。数据到了采集服务之后会做一次字段规整把同一应用上报的指标按时间戳对齐再写入Kafka。这里特别处理了一种情况业务实例重启后本地时钟可能偏差几百毫秒上报的时间戳如果不做校准后面实时计算出的指标曲线会出现毛刺。我们的做法是采集服务收到数据后对时间戳和自身服务器时间做差超过2秒的按采集服务时间替代。3.2 中间件与主机指标采集Exporter的选型与参数调优中间件和主机的采集本质上是把业界成熟的Exporter接进来但真正落地时细节特别多。PLFM_RADAR当前使用的Exporter清单如下目标Exporter关键采集参数Linux主机node_exporter默认端口9100开启systemd、filesystem、network统计MySQLmysqld_exporter采集慢查询、连接数、InnoDB行锁、主从状态Redisredis_exporter采集内存、键数、慢日志、客户端连接数Elasticsearchelasticsearch_exporter采集集群状态、分片数、查询延迟、JVM堆RabbitMQrabbitmq_exporter采集队列堆积、消费速率、连接数MinIOminio_exporter社区版采集桶容量、请求延迟、错误码分布这里边有一个选型上的经验RabbitMQ官方自带的管理API可以输出JSON格式的指标数据但需要额外写脚本去解析效率低且格式不稳定社区版的RabbitMQ Exporter反而更成熟安装即用。Exporter的部署方式也统一做了约定直接以Systemd服务跑在目标主机上而不是放在容器里。原因是这些中间件服务器本身没有部署容器运行时为了一个Exporter单独装一套容器环境得不偿失。每个Exporter的端口统一注册到Prometheus的ServiceDiscovery中由采集器动态发现。参数上有一个比较重要的坑mysqld_exporter默认会采集全量库表的processlist信息在实例数量多、并发大的库上采集本身会带来额外的性能开销实测高峰期会造成主库CPU增加5%左右。解决方案是配置只采集information_schema.processlist中非Sleep状态的连接同时把采集时间间隔从默认的5秒调大到15秒。这个调整需要反复压测我们最后定在15秒是因为这个频率足够发现连接数突增的异常又不会给数据库带来明显压力。3.3 实时计算引擎告警规则怎么设计才不误报采集上来的数据经过Kafka进入实时计算引擎后就轮到告警规则的战场了。PLFM_RADAR的告警规则沉淀了三个版本第一版是最原始的固定阈值规则第二版加了持续时间和环比第三版加入动态基线和事件关联。三个版本的迭代过程就是不断和误报、漏报斗争的过程。固定阈值规则的设计相对直观但参数怎么定很有讲究。拿接口P99延迟来说阈值不能简单地定一个「拍脑袋数」我们的做法是取过去7天同一时刻指标值的分位数乘以一个系数比如1.5倍或2倍作为动态的告警基线。误差容忍度设置了三个档P99超过基线的1.5倍持续5分钟触发Warning超过2倍持续5分钟触发Critical超过2倍持续15分钟触发Page。不同严重级别的告警触达方式不一样Warning只发企微Critical才发邮件和短信Page则直接打电话。这套分级机制让值班人员的注意力真正聚焦在重要问题上。再来看实时计算的代码逻辑这里以滑动窗口实现为例public class SlidingWindowDetector { private static final int WINDOW_SIZE 30; private final RingBufferDouble buffer new RingBuffer(WINDOW_SIZE); public synchronized AlertResult evaluate(double value, double baseline) { buffer.add(value); int overCount 0; for (double v : buffer.values()) { if (v baseline * 1.5) { overCount; } } double overRatio (double) overCount / buffer.size(); // 窗口内超过70%的数据点越过基线则触发 if (overRatio 0.7) { return new AlertResult(true, Severity.WARNING); } return new AlertResult(false, null); } }这段代码里用环形缓冲区保存最近30个数据点每个点代表一个计算周期的指标值。只有当窗口内70%的点都越线时才算告警这种设计能过滤掉偶发的瞬时毛刺。结合Kafka的实时流整个引擎的吞吐量实测可以达到每秒处理250万条指标记录这个量级应对当前平台规模绰绰有余。4. 从零搭建PLFM_RADAR完整实操流程4.1 第一步部署时序存储与消息队列存储层是整个系统的基础最先落地。ClickHouse的部署我用的单机模式配置如下足够支撑千万级指标日增量# /etc/clickhouse-server/config.d/plfm.xml clickhouse profiles default max_execution_time60/max_execution_time max_memory_usage8000000000/max_memory_usage /default /profiles storage_configuration disks default path/data/clickhouse//path /default /disks /storage_configuration /clickhouse建表语句是针对指标场景优化的使用MergeTree引擎按天分区排序键选择(app_name, metric_name, timestamp)。这个组合能保证按应用和指标名查询时ClickHouse只需要扫描少量分区查询响应时间从没超过2秒。Kafka则用的标准3节点集群Topic按指标类型拆分比如metric-app、metric-middleware、metric-infra分区数统一设置为12。分区的数量不是越大越好每个分区对应一个消费线程分区数超过消费端并发数后多余的分区会闲置白占磁盘和内存。12个分区在当前的消费并发下刚好能打满实测生产峰值时处理延迟一直稳定在3秒以下。4.2 第二步搭建采集链路与实时计算服务采集链路由两个服务组成。第一个是collector-service负责接收业务SDK通过HTTP Push上报的指标然后做格式校验写入Kafka第二个是scraper-service负责定时从Exporter端点拉取指标然后同样写入Kafka。直接看collector-service接收数据的关键逻辑这段代码踩过了不少坑RestController public class MetricCollectController { PostMapping(/metrics/report) public ResponseEntityVoid report(RequestBody ReportRequest request) { // 1. 时间戳校准避免业务机器时钟偏差 long serverTime System.currentTimeMillis(); long gap Math.abs(serverTime - request.getTimestamp()); if (gap 2000) { request.setTimestamp(serverTime); } // 2. 指标名合法性校验防注入和脏数据 for (String metricName : request.getMetrics().keySet()) { if (!metricName.matches(^[a-zA-Z][a-zA-Z0-9_.-]{0,127}$)) { request.getMetrics().remove(metricName); } } // 3. 写入Kafka异步非阻塞 kafkaTemplate.send(metric-app, request.getAppName(), request); return ResponseEntity.ok().build(); } }这个接口里有一个细节值得展开。第2步的正则校验不是形式主义。早期我们遇到过业务方在指标名里拼上了用户ID比如api.invoke.count.user_10231虽然单次上报没多大事但长此以往指标基数会爆炸式增长同一个接口可能出现几万个不同用户ID的指标序列ClickHouse的存储膨胀非常快查询也会越拖越慢。加了正则白名单之后指标名只能是固定的业务域加固定的接口标识从源头上控制了基数。scraper-service的抓取任务我用的是Quartz调度框架每个抓取任务对应一个Exporter端点调度表达式统一为每15秒执行一次。抓到的数据经过Prometheus文本格式解析后转换成内部统一的数据模型再写入Kafka。这里有一个天然的优势Prometheus的文本格式里自带job和instance标签我们直接利用这两个标签区分不同的中间件实例和主机。4.3 第三步配置Grafana看板与告警触达PLFM_RADAR的展示层直接用的Grafana因为团队对这套系统已经非常熟悉而且它与ClickHouse有官方插件无需额外适配。看板的组织方式按层级划分总览页、应用页、中间件页、基础设施页。总览页放了几个核心面板整体QPS曲线、错误率、当前告警数量、关键接口P99耗时排行。中间件页则按每个组件单独一个Folder比如MySQL页面放了连接数、慢查询数、主从延迟、缓冲池命中率四块面板。每个面板都配了告警跳转链接点击直接跳到对应的告警详情页省去排查时上下文切换的时间。告警触达分三个渠道企微机器人、邮件、短信网关。企微机器人用的是群机器人Webhook直接在群聊里推送告警卡片卡片里带上故障时间、指标名、当前值、基线值、持续时间、应用负责人姓名。邮件的发送频率做了限制同一告警规则在同一个小时内最多发送5条防止某条规则异常时邮件轰炸。短信网关只在Critical级别触发由实时计算引擎直接调用。这套告警触达机制经过半年的打磨稳定性已经比较可靠。最头疼的一次是企微机器人Webhook链接被误删导致告警全部静默了一个多小时后来我们在告警通道上增加了一个健康检查每5分钟ping一次各通道的连通性确保通道故障能第一时间被发现。5. 告警治理从告警风暴到告警收敛采集、存储和展示跑通之后PLFM_RADAR面临了一个更棘手的问题告警太多。每天少则三四十条多则上百条。告警多了之后值班人员会产生疲劳开始忽略告警真正关键的问题反而被淹没。为了整治这个现象我们专门做了一轮告警治理核心思路就六个字合并、去重、收敛。5.1 告警合并把同类告警聚到一起先说合并。典型的场景是某台数据库主机磁盘满了这个故障会同时触发出多条告警磁盘使用率告警、临时表空间不足告警、慢SQL增多告警、部分查询超时告警。如果按规则逐条推送值班人员在一个故障窗口内会收到4条不同的告警消息操作上需要一条条确认还容易漏掉最重要的那条根因告警。PLFM_RADAR的告警合并策略是按「故障对象」和「时间窗口」两个维度做。同一个应用或同一台主机在15分钟内触发的所有告警聚合成一条告警事件事件内展示该对象的全部异常指标并自动识别置信度最高的根因指标置顶。这个功能的实现不复杂就是在告警引擎里加了一个聚合器按对象窗口维度做分组窗口结束后统一发送。5.2 告警去重与抑制消除重复噪音告警去重针对的是同一指标持续性越线的场景。比如一个接口P99持续超过基线一小时固定阈值规则每分钟都会触发一次告警如果不做去重一小时内会产生60条告警消息。我们的做法是同一告警规则在同一恢复周期内只发送一条告警状态变更消息从正常变为告警时发一条恢复时再发一条。中间状态的变化比如Warning升级为Critical单独发一条升级通知。这样一轮故障下来最多三条消息清晰明了。告警抑制解决的是上下级故障的关联噪音问题。一个典型的场景网关服务故障导致大量下游接口返回504这时下游服务的错误率告警也会被触发。实际上下游服务本身没有问题完全是被网关连累的。如果不做抑制一个根因故障会产生十几条子告警。我们配置了全局的依赖关系拓扑标识了每个服务依赖的上游服务。当上游服务处于Critical状态时下游服务产生的同时间段告警自动降级为静默状态只在告警详情里作为关联事件展示不推送消息。5.3 告警规则的自省机制持续优化规则质量告警规则不是配完就一劳永逸的需要伴随系统的演进不断调整。PLFM_RADAR建立了一个很简单但有效的机制每周一早上有一个「告警周报」统计上周所有告警事件的详情人工复核每一条告警是否有价值。有价值的标准是这条告警是否推动了实际的处理动作如果连续两周都没有产生任何处理动作这条规则就被标记为「待优化」或「建议下线」。运营了几个月之后我们的告警量显著下降每天的活跃告警稳定控制在个位数同时漏报率也降低了。这个结果的核心不在于技术多高明而在于持续的复盘循环。告警治理不是一次性工程它是一个持续迭代的过程。6. 常见问题与排查技巧实录6.1 采集数据缺失或延迟有段时间我们收到反馈说Grafana上看不到某个应用的指标曲线。排查的第一步是看采集服务的日志确认有没有收到该应用的SDK上报请求。如果采集服务没收到数据大概率是SDK配置的问题如果采集服务收到了但Grafana没有数据则要看Kafka的消费链路是否卡住。实际上我们最后定位到的原因是SDK初始化时读取配置文件失败触发了默认值加载上报到了默认的本地地址导致数据一直没有发出来。这个问题的教训是SDK在启动阶段应有明确的配置检查发现无法解析上报地址时打一条醒目的错误日志而不是静默使用默认值。如果你也遇到数据缺失可以按这个顺序排查先看采集服务最近10分钟的日志里有没有对应应用的请求记录。再看Kafka的Topic消费延迟消费组是否卡住。然后看实时计算引擎中的指标接收计数是否在增加。最后查ClickHouse对应表的最新写入时间。这个顺序从上游查到下游能快速定位是链路哪一段出了问题。6.2 告警风暴一次大促引发的血案第一次双十一大促PLFM_RADAR的告警消息几乎刷屏了。原因很简单大促流量是平时的5倍所有基于固定阈值的告警规则全部被触发而且大部分是「假告警」因为业务的承载能力是经过压测的流量大涨并不代表系统有故障。那次之后我们把所有核心业务指标都切换到了动态基线模式。动态基线的计算逻辑是取过去14天同一时间点前后15分钟的数据作为样本计算P50和P90用P90乘以系数作为告警阈值。同时增加了一个「大促模式」的全局开关开启后告警阈值自动放宽为平时的2倍同时告警合并窗口从15分钟调整为5分钟有效减少了告警消息的数量。这个经验教训很值得分享监控系统不能和业务形态脱节。固定阈值只适合容量规划已经明确、上线后不会大范围变动的指标。凡是会随着业务节奏波动幅度大的指标强烈建议用动态基线。6.3 ClickHouse查询变慢索引与分区设计的调整PLFM_RADAR上线运行一个月后某些查询出现了变慢的情况特别是「查询某应用一天的所有指标原始曲线」这类请求响应时间从秒级退化到十几秒。排查后发现问题出在分区键和排序键的设计上。初版建表时排序键用的是(metric_name, timestamp)当查询按应用过滤时ClickHouse需要扫描所有分区中该应用的数据块无法有效利用分区裁剪。调整后的排序键改为(app_name, metric_name, timestamp)同时把分区改为按月分区。实测同样的查询响应时间从12秒降到0.8秒。这个调整告诉我们ClickHouse的表设计一定要基于实际查询模式不能想当然。6.4 时间不同步导致的数据错乱监控系统对时间非常敏感。有一台Redis的Exporter部署的宿主机时钟漂移了约3分钟导致采集上来的指标时间戳一直比真实时间慢3分钟。在实时告警检测中窗口滑动判断使用的是采集服务接收到数据时的处理时间而这台机器的数据时间戳永远是旧的于是这个Redis的告警判断总是慢半拍还出现过一次误告警。解决方案分两层。第一层是在所有采集目标主机上启用NTP同步并且配置了定时校验每天检查一次时间偏移量超过1秒就告警。第二层是在采集链路中对所有Exporter采集的数据统一以采集服务的服务器时间作为数据时间戳忽略目标机的时间。这里有一个注意点对于SDK上报的应用指标时间戳必须以业务请求发生的实际时间为准不能用采集服务接收时间代替否则请求延迟的统计就完全失真了。7. 最后再分享一点实际的体会PLFM_RADAR从立项到稳定运行前后花了差不多两个月的时间。如果让我重新做一次我依然会坚持三个选择第一业务指标必须用主动推的方式采集被动拉取永远无法覆盖代码级的洞察第二告警收敛必须在一开始就做而不是等告警风暴来了再补救第三动态基线的投入产出比远高于固定阈值尤其对业务形态长期波动的系统。还有一个小技巧是我在踩过多次坑之后总结的监控系统的验收标准不能用「能出图」来衡量而要用故障演练来验证。我们每季度会做一次主动故障注入比如手动杀掉一个核心服务、把某个中间件连接数突增到正常值的10倍然后观察PLFM_RADAR能否在1分钟内发现、2分钟内告警、5分钟内定位到根因。这套演练机制比任何监控页面上的数字更真实。如果你的团队也在规划一套类似的监控平台我的建议很简单不要一上来就追求大而全先把最核心的应用层指标和告警链路跑通中间件的指标逐步接入告警规则从少到多慢慢积累。一套好的监控系统不是从文档里写出来的是跟着真实故障一起长出来的。PLFM_RADAR到现在还有很多不完善的地方但每一次线上故障它都能帮我们缩短排查时间这就是它最重要的价值。
