OpenTelemetry .NET 项目中 OTLP 导出器资源处理逻辑的优化与调整

在 OpenTelemetry .NET 项目的开发过程中，我们发现 OTLP（OpenTelemetry Protocol）导出器存在一些需要优化的资源处理逻辑。这些逻辑虽然初衷可能是为了提供更好的默认值，但实际上与 OpenTelemetry 的设计理念存在偏差，需要进行调整。

问题背景

在当前的实现中，OTLP 导出器会自动为资源添加服务名称（service.name）属性。具体来说，当检测到资源中没有定义 service.name 时，导出器会主动添加一个默认值。这种隐式的修改行为虽然看似提供了便利，但实际上违背了 OpenTelemetry 的一个重要原则：观测数据应该真实反映应用程序的实际情况。

技术分析

这种自动补全服务名称的逻辑主要存在于两个地方：

1. 资源扩展方法中，会检查并添加默认服务名称
2. Protobuf 序列化器中，同样包含了类似的补全逻辑

这种设计存在几个问题：

首先，它破坏了观测数据的真实性。服务名称是一个重要的标识属性，应该由应用程序明确指定，而不是由导出器隐式添加。其次，这种隐式修改可能导致难以追踪的问题，特别是当开发者期望资源保持其原始状态时。

相关影响的处理

在深入分析这个问题时，我们还发现类似的逻辑也存在于对等服务（peer.service）属性的处理中。OTLP 标签解析器会自动填充 peer.service 属性。经过讨论，我们认为这也应该被移除，以保持整个系统行为的一致性。

变更影响评估

虽然这些修改会改变现有系统的行为，但我们更倾向于将其视为错误修复而非破坏性变更。因为：

1. 原始行为本身就与 OpenTelemetry 的设计理念不符
2. 这种修改使系统行为更加符合预期和规范
3. 开发者应该明确配置这些重要属性，而不是依赖隐式行为

实施建议

对于开发者而言，这些变更意味着：

1. 需要确保在资源创建时明确设置 service.name 属性
2. 如果需要 peer.service 属性，也应该在源头明确设置
3. 不再依赖导出器的隐式补全行为

这种改变虽然需要开发者进行一些调整，但长期来看会使系统更加健壮和可预测。它鼓励开发者明确表达其意图，而不是依赖框架的隐式行为，这符合现代软件开发的最佳实践。

总结

这次优化体现了 OpenTelemetry .NET 项目对观测数据准确性和一致性的重视。通过移除这些隐式的资源修改逻辑，我们使系统行为更加透明和可预测。开发者现在需要更加明确地配置这些重要属性，这虽然增加了一些显式配置的工作量，但换来了更高的可观测性和更少的意外行为。

对于现有用户，建议检查应用程序中是否依赖了这些隐式行为，并在升级前进行相应的调整。这种改变虽然小，但对于构建可靠的观测系统具有重要意义。