SkyWalking项目中OTEL收集器指标聚合问题的分析与解决

问题背景

在SkyWalking项目的最新版本开发过程中，开发团队发现了一个关于指标聚合的重要问题。这个问题主要出现在使用OpenTelemetry(OTEL)收集器作为数据源时，服务级别指标聚合不准确的情况。

问题本质

问题的核心在于OTEL收集器以节点级别采集指标数据时，SkyWalking后端无法正确区分以下两种场景：

1. 跨节点聚合场景：同一时间段内来自不同节点的指标数据（如节点A和节点B）
2. 同节点多次采集场景：同一节点在不同时间点的多次指标采集数据

由于OTEL收集器将这两种场景的数据以相同方式上报，SkyWalking的默认降采样（如AVG操作）会将这些数据混合处理，导致最终的服务级别指标计算结果不准确。

影响范围

这个问题影响了多个数据库和中间件的监控指标，包括但不限于：

• 数据库类：MongoDB、MySQL、MariaDB、PostgreSQL、Redis
• 搜索引擎：Elasticsearch
• Web服务器：Nginx、APISIX
• 消息队列：Kafka、Pulsar、RabbitMQ

技术分析

在传统的监控架构中，服务级别的指标通常应该通过以下两种方式之一处理：

1. 采集时聚合：由数据采集模块(如OTEL)在数据采集阶段完成节点级别的聚合
2. 查询时聚合：由监控系统在查询阶段通过元数据关联完成聚合

SkyWalking原本的设计假设采集模块会处理节点级别的聚合，但实际上OTEL收集器保留了节点级别的原始数据。这导致SkyWalking后端在持久化这些数据时，无法正确区分节点维度和时间维度。

解决方案

开发团队采取了多层次的解决方案：

1. 指标定义重构：对于受影响的组件，重新设计指标定义，确保节点级别的指标被正确标记
2. MQE增强：改进Metrics Query Engine(MQE)的聚合能力，特别是aggregate_labels操作的支持
3. 组件适配：对每个受影响的组件进行单独适配，确保服务级别指标的准确性

实施效果

经过修复后，SkyWalking能够正确处理以下场景：

• 跨节点指标的求和(SUM)操作
• 同节点多次采集的平均(AVG)操作
• 基于标签的灵活聚合

例如，对于HTTP状态码指标，现在可以正确聚合来自不同节点的相同状态码请求数，而不会混淆节点维度和时间维度。

经验总结

这个问题的解决过程为分布式监控系统的设计提供了几个重要启示：

1. 明确数据层级：在设计监控指标时需要明确定义指标的数据层级(节点级、服务级等)
2. 采集与计算分离：采集模块与监控系统之间的数据契约需要明确定义
3. 灵活聚合能力：监控系统需要提供足够灵活的聚合能力以应对不同的使用场景

通过这次问题的解决，SkyWalking的指标处理能力得到了显著提升，为后续更复杂的监控场景打下了坚实基础。