04-xiao-hong-shu-da-gui-mo-zhi-biao-jian-kong-you-hua-ti-sheng-10-bei-cha-xun-su-du-jie-yue-mo-he-cpu-zhang-zheng-zhong-.pptx

1、小红书大规模指标监控优化如何提升 10 倍查询速度 节约万核 CPU,小红书可观测技术组,2025/11/15,章正中,章正中小红书可观测技术工程师,熟悉可观测、性能分析、云原生等领域,形象照,CONTENT,01,背景与挑战,02,演进历程,03,总结与展望,背景与挑战,指标监控链路部署架构(重构前),旧部署架构:Prometheus 随业务分散部署VictoriaMetrics 作为长期存储Thanos 提供备用应急查询,资源成本高Prometheus 内存占用高，实例规格大，集群多稳定性较差故障和变更易引发数据异常与告警误报运维成本高Prometheus 部署分散，无法集中管理扩缩容与配

2、置更新流程复杂,依赖大量黑屏命令行操作使用体验差查询超时,旧部署架构遇到的问题,演进历程,采集端重构高可用改造高基数治理跨云多活查询优化,采集端重构,问题梳理资源成本高，内存需求大，告警频繁部署分散，运维成本高配置管理繁琐，流程不规范,频繁内存告警,实例数多，分散在多个集群,移除 Thanos 备用查询链路基于 vmagent 二次开发:集成配置中心，规范配置发布采集保护，限制异常流量集中管控 push 指标需求按业务线收敛采集端集群部署,基于 vmagent 开发的采集端,重构过程,扩容过程,缩容过程,采集对象按标签分片，分配给不同实例分片数动态调整，实现无须停机的平滑扩缩容,平滑扩缩容,问

3、题一：重启或新增大量采集对象时，cpu/内存剧烈波动优化：分批延迟启动采集问题二：删除大量采集对象时，内存飙升/OOM优化：对象池+并发限速问题三：GC 频繁导致的 cpu 利用率高优化：使用 GOMEMLIMIT 提高 GC 阈值，降低 GC 频率,删除大量采集对象内存利用率突增,性能优化,问题梳理采集与存储单副本，无法容忍单实例异常，重启过程中数据异常或整体不可用缺乏服务发现，依赖静态配置更新高负载情况下，雪崩问题频发,高可用改造,采集端或存储端单实例故障,高可用改造后的部署架构,采集高可用双副本冗余采集存储端去重存储高可用写入链路双副本查询自动切换可用存储副本,高可用部署,问题:静态配置

4、地址列表，维护困难过渡方案:依赖云厂商提供的固定 ip 能力最终方案:meta-service适配多种服务发现机制支持降级到手工维护支持查询自适应切换可用存储副本,服务发现:存储地址更新下发过程,服务发现,现象:某个实例的短暂不可用引发集群吞吐量下降，无法自愈根源:较高负载下，写入重分片(reroute)机制循环加剧过程分析:故障触发 reroute：当部分存储节点不可用时被排除，写入按剩余节点重新分片重分片加剧负载：新序列写入带来索引创建的开销，进一步拖慢更多节点雪崩循环：被拖慢节点不响应写入，触发新一轮 reroute,存储节点不可用时 reroute 过程,雪崩问题,使用写入侧积压+双副

5、本代替 reroute,思路:保持写入分片固定，避免 reroute方案:写入侧积压代替 reroute,每个存储节点对应一个磁盘队列文件，故障时积压，恢复时回放双副本切换保证查询数据实时性,切换过程由 meta service 判断自动触发,如何解决雪崩,问题:扩缩容时，如何灰度，保证存储集群稳定？方案:小流量预热索引meta-service 选取部分 vminsert 实例下发新的分片配置，其余实例保持不变确认存储负载稳定后，全流量生效新的分片配置,灰度生效分片变更,平滑扩缩容,高基数危害:错误的 label 使用姿势导致序列数激增采集和存储负载异常甚至崩溃治理措施:默认开启基于 labe

6、l 基数的管控针对不同场景做全局或者指标级别的基数阈值调整支持按天级月级策略滚动限制基数,写入侧高基数指标管控,高基数治理,全链路高可用：具备对单实例、多实例故障的容忍能力，局部故障对用户无感雪崩问题治理：集群不可用故障从半年 5次降为 0动态扩缩容：具备分钟级快速扩缩容能力高基数治理：可自动感知和限制高基数指标写入，集群负载降低 15%,高可用改造总结,跨云多活部署,单云部署 跨云采集,背景:单云单地域-多云多地域指标采集经过跨云专线问题:指标传输带宽大，专线带宽成本极高存在稳定性风险专线故障，监控丢失地域级故障