小红书可观测 Metrics 架构演进，如何实现数十倍性能提升？

在当前云原生时代，随着微服务架构的广泛应用，云原生可观测性概念被广泛讨论。可观测技术建设，将有助于跟踪、了解和诊断生产环境问题，辅助开发和运维人员快速发现、定位和解决问题，支撑风险追溯、经验沉淀、故障预警，提升系统可靠性。可观测技术主要包括 Metrics、Logging、Tracing、Profiling 等，其中 Metrics 是最重要的基石，它不仅为业务监控和系统监控提供基础数据，还是构建告警系统、性能优化和容量规划的核心，这些都对 Metrics 体系的稳定、实时、高效提出了更高的要求。

基于此背景，小红书可观测技术团队在过去一年内，对原有 Metrics 体系进行了全面技术升级。目前在时序数据的采集、查询上实现了数十倍的性能提升，大幅降低计算、存储、带宽成本；同时显著提升可用性，具备全链路的单实例、单集群故障容忍能力，实现了分钟级的快速扩缩容；通过产品化配置变更、自动化集群迁移、标准化监控接入流程等方面，实现运维人力成本节约。

1.1 小红书 Metrics 发展情况

随着小红书业务的持续发展，推荐、搜索、广告、电商和基础服务等各个领域的 Metrics 规模不断扩大。以推荐系统为例，单个核心应用在单次采集周期内所产生的指标量已达到亿级别，整个推荐系统的监控数据源指标量更是接近十亿级别。

云原生时代，Prometheus 逐步成为 Metrics 的事实标准。然而，最初基于开源 Prometheus 构建的系统，在规模迅速扩大的情况下，暴露了越来越多的问题。无论是资源占用，还是迭代效率，都已经无法支撑现有的数据规模和业务需求。作为小红书可观测团队，我们迫切需要对现有系统进行技术优化和成本压缩，以支撑业务的快速、高效发展。

1.2 面临的问题

依托开源 Prometheus 解决方案，小红书 Metrics 整体架构如图所示：

主要特点：

单副本架构：全链路从采集、写入、存储到查询都采用单副本方式。
分散部署：Prometheus 作为采集端部署在对应的 K8s 集群中，每个 K8s 集群中往往会部署多个 Prometheus 实例，负责采集不同业务指标，并将其写入不同的远端存储中。此外，还有一部分 Promethues 实例是以虚拟机方式部署，用于采集一些个性化的指标需求。
高可用性：Prometheus 不仅作为 Tsdb，还存储两个小时的数据供 Thanos 查询进行应急查询。

存在的问题：

稳定性差：由于全链路采用单副本方式，稳定性较差。日常变更和故障都可能导致 Metrics 丢失，进而影响告警、监控的准确性和可靠性，用户对此有明显感知。在指标量突增时，容易出现指标端到端写入延迟过大，进一步影响监控和告警功能。
资源成本高：Prometheus 的资源消耗较大，内存使用率经常超过 85%，频繁触发 Prometheus 资源告警；同时增加了实施多活/多副本的成本压力。
运维复杂：部署方式分散且管理成本高，甚至存在一些未知的、无主的 Prometheus 实例，导致日常运维需要耗费大量时间。大多数的虚机部署实例在进行变更时，属于黑屏操作状态，无法追溯。此外，系统还不具备全链路快速弹性扩缩容能力。
使用体验差：Metrics 的查询速度慢，经常出现慢查询问题。用户反馈大盘打开速度较慢、Panel 加载失败。作为应急备用查询方式的 Thanos 查询速度慢，经常超时，并且需要较高的资源成本。

我们主要从以下几个方面，逐步做了架构演进：

● 初步云原生化：尽可能将虚机部署容器化，并迁移到发布平台进行发布，实现变更白屏化的目标。

● 采集端重构：采用新的采集架构替换 Prometheus，同时下线 Thanos，以解决采集过程中的各种问题，并实现采集-存储的彻底分离。同时，我们对Push 类需求进行了统一的支持和管控。

● 高可用改造：我们从采集、写入、存储和查询等方面，设计并实现了整体的高可用方案，使系统在端到端具备高可用能力，能够容忍单机群内少量实例故障、单机群整体故障等常见故障场景。

● 查询优化：我们对查询进行了限流和资源使用的限制，并对存量查询进行分析，重构了查询流程，将聚合运算下推到存储节点执行，从而加速大多数查询操作。

● 高基数治理：核心集群具备高基数治理能力，防止业务不规范使用导致的时间序列膨胀问题。

● 跨云多活：进一步优化部署方式，通过单元化部署实现机房故障隔离，并降低跨云带宽。

● 存储优化：目前我们进行的工作，存储支持降采样，以在不增加资源的情况下支持更长时间的指标数据存储。

技术选型：

我们基于开源 Victoriametrics (以下简称 Vms ) 作为整体架构基础，针对小红书内部的业务场景和痛点进行定制开发，以适配公司内部组件。全链路选择 Vms 的原因主要是：

● 出色性能：相比于 Prometheus ，Vms 在性能方面表现更出色。以 Prometheus Agent 模式为例，经测试发现，在相同的指标量下，Vms 所占用的资源约为其的 1/3 左右。

● 兼容性好：Vms 在采集侧基本兼容 Prometheus，这使得我们能平滑地迁移现有的 Prometheus 采集组件。同时，当前小红书 Metrics 存储组件已经基于 Vms 构建，全链路切换到 Vms 的成本和风险较低。

● 可扩展性：Vms 具有清晰简洁的代码结构，易于理解和维护，具备良好的可扩展性，在此基础上进行二次开发更加高效；此外，开源社区的版本更新速度、Issue 讨论、Bug fix 都非常迅速，为我们提供了好的支持。

演进后，当前架构图如下所示：

包括以下核心组件：

● Vms: 包括Vmagent、Vminsert、Vmselect、Vmstorage 等开源组件。

● Push service gateway: 负责接收业务主动推送的 Metrics，并根据租户将其转发到对应的监控采集集群。

● 管理组件：

◌ 配置中心：负责指标采集的配置、Kube-config 的维护。

◌ Meta service：负责服务发现、主备集群切换等功能。

◌ 运维平台：提供集群注册、扩缩容等常规运维支持，以及查询切流、写入限速/停写等多种应急处理能力。

接下来我们将从采集端、全链路高可用方案、查询优化、高基数处理和跨云多活等方面来详细介绍。

2.1 采集

在最初的采集端部署方案中，我们按照每个 K8s 集群进行 1:1 的部署。例如，推荐集群在多达 15 个 K8s 集群中进行部署，整个公司的 Prometheus 部署组超过两百个。在资源使用方面，普遍采用的是 1:8 的大内存机型，其中某些 Prometheus 实例的内存配置接近于 512GB；即便如此，几乎每周都会出现多次内存超过 85% 的告警。扩容时由于大内存资源无法及时释放，导致故障时间延长。采集变更通过上线变更实现，当业务需求发生变化时，需要对十几组 Prometheus 分别进行上线，集群运维复杂烦琐。为了快速迭代上线，不同部署组的 Prometheus 配置逐渐分裂，增加了配置管理的负担。

2.1.1 整体架构

针对以上这些问题，我们重新设计实现了采集的架构，整体架构如下：

基于 vmagent 的开发方案：我们选择使用 vmagent 替代 Prometheus，并通过全链路的双活机制（后文介绍）替换和下线 Thanos。放弃使用 Prometheus agent 的原因是，在原型验证阶段发现了该代理存在的必现 Bug，且社区无相应的解决方案。经过测试，我们发现 vmagent 在性能方面明显优于 Prometheus agent，且其代码结构更加简洁直观，可扩展性更好。