Apache SkyWalking 中 OTEL 收集器指标聚合问题的分析与解决方案

问题背景

在 Apache SkyWalking 的 ClickHouse PR 审查过程中，发现了一个关于指标聚合的共性问题。这个问题主要出现在使用 OpenTelemetry (OTEL) 收集器针对每个节点收集指标时，服务级别的指标聚合处理不当。

问题本质

当 SkyWalking 从多个节点收集指标时，存在两种典型场景：

1. 跨节点聚合场景：不同节点（如 node1 和 node2）同时向 OTEL 收集器发送指标数据，然后转发到 OAP 服务器
2. 单节点多次采集场景：同一节点在不同时间点（如 T1 和 T2）发送指标数据

OAP 服务器在处理这些数据时，无法区分这两种场景。当进行降采样（默认使用 AVG 算法）时，会导致指标聚合结果不准确：

• 对于跨节点数据，应该计算的是所有节点的聚合值
• 对于单节点多次采集，应该计算的是该节点在时间窗口内的聚合值

影响范围

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

• 数据库类：MongoDB、MySQL、MariaDB、PostgreSQL、Redis
• 中间件类：Nginx、APISIX、Kafka、Pulsar、RabbitMQ
• 搜索引擎：Elasticsearch

技术分析

问题的核心在于 SkyWalking 的指标处理机制。在现有实现中：

1. 指标数据以"指标名_标签值"的形式存储（如 http_status_401）
2. 节点信息作为标签值存储（如 {192.168.0.1=5, 192.168.0.3=1}）
3. 服务级别的聚合需要基于这些标签值进行计算

解决方案

为了解决这个问题，SkyWalking 社区采取了以下措施：

1. 引入多标签支持：增强了 aggregate_labels 操作，使其能够基于指定标签进行聚合
2. 重构指标处理逻辑：确保服务级别指标使用 MQE（查询阶段聚合）来合并数据
3. 组件专项修复：针对每个受影响组件进行单独验证和修复

实现示例

以 HTTP 状态码监控为例，改进后的处理流程：

1. 原始数据格式：

   http_status{host=192.168.0.1, status=401} 5
   http_status{host=192.168.0.3, status=401} 1
   

2. 存储格式：

   http_status_401{192.168.0.1=5, 192.168.0.3=1}
   

3. 聚合查询：

   aggregate_labels(http_status,'status',sum)
   

4. 结果输出：

   http_status{status=401} 6
   

最佳实践

对于 SkyWalking 用户和开发者：

1. 在实现服务级别监控时，确保使用 MQE 进行数据聚合
2. 合理设计指标标签体系，区分节点级别和服务级别指标
3. 对于集群监控，确保从所有节点收集数据并进行正确聚合
4. 定期检查监控仪表板，验证指标聚合的准确性

总结

Apache SkyWalking 通过引入多标签支持和改进聚合机制，有效解决了 OTEL 收集器在节点级别指标聚合中的问题。这一改进不仅提升了监控数据的准确性，也为更复杂的监控场景提供了更好的支持。开发者在使用 SkyWalking 进行系统监控时，应当充分理解这些机制，以确保监控数据的可靠性。