【极简监控】告别重度存储！用 InMemoryMetricsCollector 搞定 99% 的单体应用Metrics排错

文章目录前言破局断舍离只关注“最近半小时”极简利器InMemoryMetricsCollector 的设计哲学它是如何工作的注入灵魂结合 AI 的智能可视化结语与延伸相关前言做系统监控这么多年下来我们团队常常在反思监控的本质到底是什么剥开各种高大上的 APM 架构外衣我们终于理解对于监控来说核心其实就是两个维度眼前问题发生时的快速定位比如刚才这几分钟为什么接口响应变慢了线程池是不是满了基于数周甚至数月的统计分析找出系统隐藏的问题比如近半年的系统容量演进趋势。现实往往很骨感对于 99% 的单体业务应用来说真正的痛点基本都在前者。很多应用甚至直到下线都没有用到过第二种维度的能力。为了那 1% 的“长期统计”伪需求去搭建庞大的时序数据库、维护沉重的存储集群这显然是个吃力不讨好的脏活累活。破局断舍离只关注“最近半小时”顺着这个思路往下走我们得出了一个极简的结论我们其实完全可以不考虑跨度达到一周、一个月的 Metrics指标数据。排查当下的问题我只需要记录最近一天甚至最近半小时的周期性数据就足够了只要能把这极短周期内的数据抓取到并进行前端可视化展示就已经可以应对绝大部分的日常监控和排错工作。基于这种“断舍离”的实用主义考虑我们专门开发了一个极轻量级的组件InMemoryMetricsCollector。极简利器InMemoryMetricsCollector 的设计哲学如同它的名字一样这是一个完全基于内存的指标收集器。它的核心目标只有一个用最少的资源画出排错最需要的趋势曲线。在设计上它的构造函数被精简到了极致只接收三个参数Supplier数据获取逻辑这是第一个参数也是唯一需要使用者去写代码实现的方法。你只需要告诉收集器“怎么拿到数据”比如返回当前的活跃线程数、内存使用率或是某个业务队列的长度返回值就是对应的监控数据。collectIntervalSeconds采样间隔第二个参数默认为 1 秒。代表收集器去拉取数据的频率。retentionMinutes数据保留时长(分钟)第三个参数也是防止内存溢出的关键。它定义了内存中最多保存多长时限得。当收集的数据量超出这个数字时组件会自动将头部最老的数据过期剔除类似于一个固定大小的滑动窗口/环形队列。/** * 通用指标采集器 * p 一个基于内存的、轻量级的、滑动窗口式的指标采集工具类 (MetricsTemporaryCollector)。 * p 提供一个“妥协”方案在不需要外部依赖、不需要大幅改造业务代码的前提下能够保留最近一段时间如30分钟的指标数据用于压测或生产环境的问题定位Root Cause Analysis。 * p * 1. 使用 Supplier 注入采集逻辑解耦业务。 * 2. 使用 ArrayDeque 作为环形缓冲内存更紧凑。 * 3. 全局共享调度线程池节省资源。 * * param T 指标数据的类型 * * * p 依然是一个迫不得已的挫方案. * p 背景: * p 在做压测等需要长时间运行, 然后基于运行这段时间的全部数据进行metrics, 以发现和定位问题根因. * p 业内通用方案是采用诸如prometheus/InfluxDB这样的时序数据库进行数据记录. * p 但业内正规方案不能够快速应用于toG这样的小微企业, 一来是额外的部署成本, 二来则是对于调用端的改造也是相关研发人员所抗拒的 —— 缺乏相关意识, 认为业务代码调整之外的工作都是负担. 比较典型的就是性能分析盯着单个请求来猜测. * p 解决方案: * p 1. 借鉴自skywalking-local里的思路, 只保留最近X分钟内的数据, 过期则删除. * p 2. 如此既保证了能够进行metrics的基本数据, 也不需要额外的部署成本和客户端改造. * * */Slf4jpublicclassInMemoryMetricsCollectorT{// 全局共享的定时任务线程池 (Daemon模式随JVM销毁)privatestaticfinalScheduledExecutorServiceSCHEDULERnewScheduledThreadPoolExecutor(2,ThreadUtil.newNamedThreadFactory(Metrics-Scheduler-Temporary-,true));// 采集逻辑提供者privatefinalSupplierTscraper;// 缓冲区最大容量privatefinalintmaxCapacity;// 内存缓冲区 (ArrayDeque比LinkedList更省内存无Node开销)privatefinalDequeMetricsNodeTbuffer;// 读写锁privatefinalReentrantReadWriteLocklocknewReentrantReadWriteLock();// 任务句柄privatefinalScheduledFuture?future;/** * param scraper 采集逻辑 * param collectIntervalSeconds 采集间隔(秒) * param retentionMinutes 数据保留时长(分钟) */publicInMemoryMetricsCollector(SupplierTscraper,intcollectIntervalSeconds,intretentionMinutes){if(scrapernull){thrownewIllegalArgumentException(Scraper supplier cannot be null);}this.scraperscraper;// 计算容量保留分钟数 * 60 / 间隔秒数// 例如20分钟 * 60 / 1秒 1200this.maxCapacity(retentionMinutes*60)/Math.max(1,collectIntervalSeconds);this.buffernewArrayDeque(this.maxCapacity);// 启动定时任务// 1. scheduleAtFixedRate (不管做没做完每60秒触发一次)// 2. scheduleWithFixedDelay (执行完再等60秒)this.futureSCHEDULER.scheduleWithFixedDelay(this::doScrape,0,collectIntervalSeconds,TimeUnit.SECONDS);}/** * 默认构造1秒采集一次保留30分钟 */publicInMemoryMetricsCollector(SupplierTscraper){this(scraper,1,30);}privatevoiddoScrape(){try{longnowSystem.currentTimeMillis();// 执行外部传入的采集逻辑Tdatascraper.get();if(datanull){return;}MetricsNodeTnodenewMetricsNode(now,data);// 写锁极速写入lock.writeLock().lock();try{if(buffer.size()maxCapacity){buffer.pollFirst();// 移除最旧的 (ArrayDeque pollFirst效率很高)}buffer.offerLast(node);// 加入最新的}finally{lock.writeLock().unlock();}}catch(Throwablet){// 捕获所有异常确保定时任务不会因为一次失败而终止log.error(Metrics scrape task failed.,t);}}/** * 获取当前所有指标数据快照 */publicListMetricsNodeTgetMetrics(){lock.readLock().lock();try{// 返回副本线程安全returnnewArrayList(buffer);}finally{lock.readLock().unlock();}}/** * 销毁任务 */publicvoidshutdown(){if(future!null!future.isCancelled()){future.cancel(false);}}// // 内部数据载体 (Immutable更安全)// GetterpublicstaticclassMetricsNodeV{privatefinallongtimestamp;privatefinalVvalue;publicMetricsNode(longtimestamp,Vvalue){this.timestamptimestamp;this.valuevalue;}}}它是如何工作的当你初始化了一个InMemoryMetricsCollector后它内部会启动一个专属的轻量级线程池。这个线程池会按照你传入的Interval配置像个不知疲倦的打工人一样周期性地去调用你写的Supplier拉取数据并将它们按顺序存储在内存数组中。这种设计的绝妙之处在于对应用绝对安全因为有严格的Capacity限制旧数据会被源源不断地淘汰。既实现了 metrics 数据的连续记录又从根本上避免了内存无限上涨导致 OOM 的隐患。零外部依赖不需要连 Redis不需要写 InfluxDB所有时序数据就在本地内存里流转极度轻量。注入灵魂结合 AI 的智能可视化光把数据存在内存里还不够开发人员排查问题需要的是直观的曲线图。考虑到轻量化的初衷我们放弃了笨重的传统看板而是引入了全新的玩法借助 AI 来对收集起来的这部分近期数据进行可视化展示。当线上出现状况你只需要将InMemoryMetricsCollector缓存的这“最近半小时”的纯文本/JSON 数据导出来丢给 AIAI 就能迅速理解数据结构并为你绘制出清晰的趋势变化曲线图。哪里有突刺、哪里在持续攀升一目了然。结语与延伸InMemoryMetricsCollector的诞生是我们向“过度设计”开的一炮。只要几行代码一个Supplier99% 的单体应用就能拥有极其好用的近期指标回溯能力应对日常排错绰绰有余。事实上这个小巧的组件也正是我们近期推行的“本地化监控改造”理念中的重要一环。如果你对这种“干掉沉重服务端、回归本地轻量化”的监控思路感兴趣或者想看看我们是如何将这种理念应用在更复杂的链路追踪上的可以移步参考我们之前的这篇博文《DevOps实践SkyWalking-Local 的诞生与魔改》监控不应该是研发的负担而应该是随手可用的利器。快把InMermoryMetricsCollector用起来让你的应用轻装上阵吧相关告别沉重的OAP一款专为单体应用打造的 SkyWalking 轻量级本地化 Reporter 插件