Airbnb把100亿条数据"偷渡"到新系统，StatsD还没反应过来

每秒1亿条指标数据，从StatsD的老旧管道里抽离，塞进OpenTelemetry的新骨架——Airbnb的监控团队干了件让同行眼馋的事：他们没有搞渐进式迁移，而是选择先把数据"灌"进去，再慢慢收拾仪表盘和告警。

这相当于给飞行中的飞机换引擎，但机组人员决定先保证新引擎转起来，再处理乘客的娱乐系统。

三轨并行的混乱现场

Airbnb的监控体系是个典型的技术债标本。StatsD跑了多年，Veneur（他们自己fork的聚合器）扛不住规模，Prometheus生态又在边缘试探。三种instrumentation（埋点）方式同时存在：老的StatsD库、新冒头的OTLP、还有为Grafana Mimir准备的Prometheus兼容层。

40%的服务用着一个平台维护的共享指标库。这个库成了关键杠杆——团队把它改成双发模式：StatsD继续往老管道走，OTLP同步往新系统灌。服务方零感知，埋点代码不用动。

剩下的60%服务各自为政，有的直接调StatsD客户端，有的已经自己接了OTLP。这摊碎片化是迁移的暗礁。

前置采集的赌博

传统迁移剧本是分阶段切流量：先迁一部分服务，验证，再扩大。Airbnb反着来——先把所有采集层打通，让新系统吃上全量数据，再回头修仪表盘、告警规则、用户工具。

「我们想避免的是：用户在新系统里查不到历史数据，或者发现某个指标莫名其妙断了。」团队在技术博客里写道。

这个决策的代价是前期工程量大。Collector（采集器）集群要扛住瞬间峰值，vmagent（VictoriaMetrics的代理）得跟上写入节奏。但收益也明确：用户切换时，数据已经在那儿等着了。

Collector成了翻译官

OpenTelemetry Collector是这套架构的枢纽。它干了几件脏活：

StatsD接收器把UDP包里的指标转成OTLP格式；Prometheus接收器处理那些已经用Prometheus client库埋点的服务；OTLP接收器直接吞原生数据。三种方言，统一出口。

Collector还负责标签重写、指标过滤、采样策略。Airbnb的部署规模是数百个实例，按区域和负载分片。他们没有用Collector的tail-based sampling（尾部采样），而是在源头就做完决策——减轻网络传输压力。

一个细节：StatsD的计数器在OTLP里没有直接对应，需要转成sum类型。团队为此写了自定义processor，处理这种语义错位。

存储层的取舍

VictoriaMetrics替换了原来的Veneur+Mimir组合。选择它的理由是资源效率：同样硬件，能吞更多数据点。vmagent作为边缘代理，把Collector吐出来的数据再压缩、批量、远传。

Airbnb没有透露具体成本数字，但提到「显著降低」了存储开销。VictoriaMetrics的merge算法对高基数场景更友好——这是Airbnb的痛点，微服务标签爆炸后， cardinality（基数）管理成了噩梦。

老系统里，他们得手动给高基数指标加黑名单。新架构里，Collector层就能做标签丢弃和聚合，问题被推到更上游解决。

用户无感切换的秘密

仪表盘和告警的迁移是后半场。Grafana对接VictoriaMetrics的查询接口，PromQL语法兼容，所以大部分面板直接复制过来就能跑。少数用了StatsD特有函数的，需要人工改写。

告警规则从Nagios风格迁到Prometheus的alerting规则，这个花了力气。团队做了个并行期：同一条规则，老系统新系统同时跑，对比触发一致性，再下线老的。

「最麻烦的不是技术，是让用户相信新数据没问题。」一位工程师在内部复盘时提到。他们搞了个「数据质量仪表盘」，对比新老系统的同指标曲线，偏差超过阈值就标红。

还没填的坑

迁移完成不等于万事大吉。Trace和log的OTLP化还在进行，metrics先行是因为痛点最痛。Collector本身的运维复杂度是新债务：版本升级、配置漂移、receiver的bug。

StatsD的老管道还没完全下线，作为逃生舱保留。团队估计再跑一年，等最后一个服务摘掉StatsD客户端，才能彻底关灯。

这个案例的参考价值在于：大规模observability（可观测性）迁移，数据层和用户层可以解耦。先保证数据不断、不丢、可查，再慢慢收拾用户体验，比试图一步到位更可控。

Airbnb的监控团队现在盯着下一个问题：当所有信号都走OTLP，Collector会不会成为新的瓶颈？以及，VictoriaMetrics的集群版他们还没上，单机垂直扩展的极限在哪？