Prometheus 3.x 版本与 OpenTelemetry Collector 的指标名称兼容性问题分析

在 Prometheus 3.1.0 版本中，用户报告了一个与 OpenTelemetry Collector 指标采集相关的兼容性问题。当 Prometheus 尝试从 OpenTelemetry Collector 端点采集指标时，出现了指标名称验证失败的情况。

问题现象

用户在使用 Prometheus 3.1.0 版本采集 OpenTelemetry Collector（版本 0.118.0）的指标时，发现 Prometheus 拒绝了这些指标数据。错误信息表明，Prometheus 仍然在指标名称中识别到了点号（.），尽管用户已经在配置中明确设置了 metric_name_validation_scheme: legacy 参数，期望将点号转换为下划线。

技术背景

Prometheus 3.x 版本引入了一个重要的变化：默认情况下使用 UTF-8 编码验证方案（escaping=allow-utf-8 模式）。这种模式下，Prometheus 允许在指标名称和标签名称中使用更广泛的字符集，包括点号。而在传统的验证方案（legacy 模式）下，Prometheus 会将点号自动转换为下划线，以保持向后兼容性。

OpenTelemetry Collector 的 Prometheus 导出器实现有一个特点：它总是会对指标名称进行转义处理。这种行为在 Prometheus 2.x 版本中工作正常，但在 3.x 版本中，由于默认验证方案的变化，导致了兼容性问题。

根本原因分析

问题的根本原因在于两个方面：

1. OpenTelemetry Collector 的 Prometheus 导出器实现始终对指标名称进行转义处理，这种硬编码的行为在新的验证方案下不再适用。

2. 虽然用户可以通过配置 metric_name_validation_scheme: legacy 强制 Prometheus 使用传统验证方案，但这个设置在特定情况下可能无法完全覆盖 OpenTelemetry Collector 的特殊行为。

解决方案

对于遇到此问题的用户，有以下几种解决方案：

1. 降级 OpenTelemetry Collector 到 0.117.0 或更早版本，这些版本尚未受到此问题影响。

2. 在 OpenTelemetry Collector 中明确配置使用传统验证方案，覆盖默认的 UTF-8 编码方案。

3. 等待 OpenTelemetry 项目更新其 Prometheus 导出器实现，使其能够正确处理新的验证方案。

最佳实践建议

对于生产环境中同时使用 Prometheus 和 OpenTelemetry 的用户，建议：

1. 在升级 Prometheus 到 3.x 版本前，充分测试与现有监控组件的兼容性。

2. 对于关键监控链路，考虑使用版本锁定的方式确保组件兼容性。

3. 关注 Prometheus 和 OpenTelemetry 项目的更新日志，及时了解可能影响兼容性的变更。

这个问题展示了监控生态系统中组件间相互依赖的复杂性，也提醒我们在进行版本升级时需要全面考虑各个组件的兼容性状态。