Apache SkyWalking 中 OTEL 收集器目标节点指标聚合问题解析

背景概述

在 Apache SkyWalking 监控系统中，当使用 OpenTelemetry (OTEL) 收集器以节点为目标收集指标时，发现了一个重要的指标聚合问题。这个问题最初是在 ClickHouse 监控的代码审查过程中被发现的，但进一步调查表明这是一个普遍存在于多种数据库和中间件监控中的共性问题。

问题本质

问题的核心在于服务级别指标的聚合方式。当前实现中，当多个节点(如数据库节点)的指标被收集时，系统无法正确区分以下两种情况：

1. 跨节点聚合：同一时间点来自不同节点的指标数据
2. 时间序列聚合：同一节点在不同时间点上报的指标数据

由于这种区分能力的缺失，系统在进行下采样(如默认的AVG计算)时，会将所有数据点简单平均，而无法正确反映服务级别的真实聚合指标。

技术细节分析

在具体实现层面，问题表现为：

• 当OTEL收集器从节点A和节点B分别收集指标时，这些指标会相互重叠
• 系统无法识别这些指标是来自不同节点还是同一节点在不同时间点的采样
• 导致最终的服务级别指标计算不准确

举例说明，假设有：

• 节点A在时间T1和T2上报指标
• 节点B在时间T1上报指标

系统会将这3个数据点(N=2来自节点A，M=1来自节点B)进行简单平均，而这不是服务级别指标的正确聚合方式。

影响范围

经过社区调查，这个问题影响到了多种数据库和中间件的监控实现，包括但不限于：

• MongoDB
• MySQL/MariaDB
• PostgreSQL
• Redis
• Nginx
• APISIX
• RabbitMQ等

值得注意的是，并非所有监控实现都存在此问题。例如Elasticsearch、Kafka和Pulsar的监控由于采用了集群级别的API或正确的聚合逻辑，不受此问题影响。

解决方案

社区针对此问题提出了多方面的解决方案：

1. 指标标签化：将服务指标设计为带标签的值，确保不同节点的指标能够被正确区分
2. MQE聚合：在查询阶段使用Metrics Query Engine (MQE)进行正确的数据合并
3. 多标签支持：通过增强的aggregate_labels功能，支持按指定标签进行聚合

对于APISIX等特定组件的监控，需要等待aggregate_labels功能增强后才能完全修复。

最佳实践建议

基于此问题的经验，建议在实现服务监控时注意以下几点：

1. 明确指标来源：清楚区分节点级别和服务级别的指标
2. 合理设计标签：使用标签系统正确标识指标来源
3. 选择适当聚合：根据指标性质选择SUM、AVG等合适的聚合方式
4. 全面测试验证：在多种节点配置和负载情况下验证监控数据的准确性

总结

Apache SkyWalking社区对此问题的快速响应和全面修复展现了项目对监控数据准确性的高度重视。通过这次问题的解决，不仅修复了现有实现中的缺陷，还为未来类似场景提供了设计参考和实现规范。对于使用SkyWalking进行服务监控的用户，建议关注相关组件的更新，确保使用已修复的版本来获取准确的监控数据。