OpenTelemetry .NET 中查询参数脱敏问题的分析与解决

问题背景

在OpenTelemetry .NET的1.10.0版本中，开发者在使用HTTP客户端进行监控时会遇到一个常见问题：所有的URL查询参数都会被自动脱敏处理。这种设计原本是为了保护用户隐私，防止敏感信息被记录，但对于那些依赖查询参数进行业务处理的系统来说，这会导致监控数据失去价值。

问题重现

当开发者按照标准方式配置OpenTelemetry后，即使设置了环境变量OTEL_DOTNET_EXPERIMENTAL_ASPNETCORE_DISABLE_URL_QUERY_REDACTION，查询参数仍然会被脱敏。这个问题在1.8.1及以上版本中尤为明显。

根本原因

经过深入分析，发现问题的根源在于环境变量名称的混淆。OpenTelemetry针对不同的使用场景提供了不同的环境变量：

1. 对于ASP.NET Core应用，应使用OTEL_DOTNET_EXPERIMENTAL_ASPNETCORE_DISABLE_URL_QUERY_REDACTION
2. 对于直接使用HttpClient的场景，则需要使用OTEL_DOTNET_EXPERIMENTAL_HTTPCLIENT_DISABLE_URL_QUERY_REDACTION

开发者容易混淆这两者的区别，导致配置无效。

解决方案

要解决这个问题，需要根据实际使用场景正确设置环境变量：

1. ASP.NET Core应用：确保设置的是ASP.NET Core专用的环境变量
2. HttpClient直接调用：使用HttpClient专用的环境变量

最佳实践

1. 明确应用类型：首先确定你的应用是ASP.NET Core Web应用还是控制台应用
2. 正确配置环境变量：根据应用类型选择正确的环境变量名称
3. 测试验证：部署后检查OpenTelemetry收集的数据，确认查询参数是否按预期显示

技术细节

OpenTelemetry对查询参数的脱敏处理是通过不同的Instrumentation库实现的。ASP.NET Core和HttpClient有各自独立的Instrumentation实现，因此需要分别配置。这种设计虽然增加了灵活性，但也带来了配置上的复杂性。

总结

OpenTelemetry作为强大的可观测性工具，其配置需要精确匹配使用场景。查询参数脱敏功能的设计体现了隐私保护的考虑，但开发者需要了解不同场景下的配置差异才能充分发挥其功能。通过正确理解和使用环境变量，开发者可以灵活控制查询参数的脱敏行为，既保护用户隐私，又不丢失重要的业务监控信息。