#### **背景** OpenTelemetry Collector 是 OpenTelemetry 生态中的核心组件，用于采集、处理和导出 traces、metrics 和 logs 数据。在 VKE addon 平台，我们入驻基于社区版本二开增强的 Opentelemetry Collector，支持白屏一键部署。为了帮助用户合理选择 Collector 的规格和副本数量，我们对其性能进行了详细压测评估。 --- #### **压测目标** 1. **性能评估**：测试 Collector 在不同负载下的吞吐量、延迟和稳定性，明确其处理能力边界。 2. **资源使用分析**：评估 Collector 在不同负载场景下的 CPU 和内存使用情况。 3. **集群规模规划**：根据测试结果，计算生产环境中 Collector 的副本数量需求。 --- #### **压测结果** 基线数据，collector 在空载时的 cpu 约 0.25%，mem 约 1.5%。 |**规格** |**吞吐(spans/s)** |CPU |MEM | |---|---|---|---| |

1C2G

|4w |60% |4.5% |\ | | | | | |^^|6w |90% |4.6% | |^^|7.3w |100% |5.8% | |

2C2G

|9w |67% |3% |\ | | | | | |^^|12w |86% |3% | |^^|14.5w |100% |3.8% | |

4C4G

|16w |56% |1.8% |\ | | | | | |^^|24w |83% |2% | |^^|29w |100% |2.5% | 1. **CPU 消耗与吞吐量**：Collector 的 CPU 消耗与 span 吞吐量呈线性关系。测试数据表明： * 1w/s 吞吐大约消耗单核 15% 的 CPU。 * 单核 CPU 的数据处理上限约为 7w/s spans。 2. **内存使用**：Collector 的内存消耗较低，处理高负载时内存使用率保持在 6% 以下。 3. **稳定性**：在测试过程中，Collector 未出现数据丢弃或拒收现象，性能表现稳定。 --- #### **使用建议** 根据压测结果和线上环境的复杂性，推荐以下规格和吞吐量： |**规格** |**推荐吞吐量** | |---|---| |1C2G |4w/s | |2C2G |8w/s | |4C4G |18w/s | 为了确保线上服务稳定性，建议将 CPU 水位尽量保持在 80% 以下，并预留 20%~50% 的副本冗余。 --- #### **如何选择 Collector 的副本数** 1. **预估集群的 span 吞吐量**： * 方式一：联系 APMPlus 研发团队查看当前租户的 span 吞吐。 * 方式二：根据业务 QPS 估算 span 吞吐。例如，业务整体 QPS 为 1000/s，每条请求平均产生 20 条 span，实例数为 20，则总吞吐量为： ```Plain Text 1000/s * 20 * 20 = 40w/s ``` 2. **计算所需实例数**：根据推荐比例，40w/s 吞吐需 40/4 ≈ 10 台 1C2G Collector 实例。考虑冗余，建议部署 12~15 台实例，其他规格的选择同理。 --- #### **结论** Apmplus OpenTelemetry Collector 的性能在高负载场景下表现稳定，主要受 CPU 资源限制。用户可根据业务需求和 span 吞吐量选择适当规格和副本数量，确保数据处理效率和系统稳定性。

应用性能监控全链路版