我正在探索 Open Telemetry Collector Project 以及它如何与容器化的 .NET Core 应用程序（或任何其他应用程序）一起工作。
目前我们在我工作的公司使用 DynaTrace，这需要在主机上安装 DynaTrace 'OneAgent' 代理。DynaTrace 代理以某种方式连接到 dotnet CLR 并执行字节码/MSIL 检测。基本上，这种方法允许我们将 APM 数据捕获到 DynaTrace，而无需在我们的应用程序中进行任何代码更改。
将此与 Open Telemetry 方法进行对比，后者（据我所知）需要将额外的（nuget）包安装到我们想要检测的服务中。在 .NET Core 领域，我怀疑这是在使用基于 DiagnosticSource 的检测，我将其描述为一种 AOP。也就是说，它主要是自动的并集成到各种 .NET 库/框架中，例如 ASP.NET、Entity Framework 等；所以唯一的代码更改是；a) 安装 Open Telemetry nuget 包，b) 一些基本的 Startup.cs 配置，以及 c) 如果需要/在需要时可以选择添加额外的 span。这是最少的代码，但它不像 DynaTrace 方法那样没有代码。我还假设跨度的粒度比 DynaTrace 使用的字节码/MSIL 检测方法要粗得多。
WRT 开放遥测收集器；我真的很喜欢这样一个事实，即我们可以配置导出器以将检测数据发送到任何受支持的第三方监控解决方案（例如 DataDog、Elastic、Kafka 等），而无需安装任何专有代理。IMO 这种方法意味着我们可以更轻松地更改我们可能正在使用的监控服务，从而减轻供应商锁定。
我希望我能找到一种两全其美的方法；
- 我想使用 Open Telemerty Collecter 代理来缓解供应商锁定。通过能够更改底层监控解决方案，我们可以通过切换到更便宜的监控解决方案来节省数十万美元（或者至少切换的威胁是真实的，我们可以协商更便宜的成本）！
- 我想使用字节码/MSIL 检测方法，这样我就不必在我的应用程序中进行任何代码/配置更改。
这可能吗？
我正在研究 DataDog 代理是如何工作的。看起来这可能是与 DynaTrace 类似的方法。对于 DataDog，看起来您需要在应用程序容器中设置一些 CLR 环境变量 - 大概这会扩展 CLR 以将字节码/MSIL 检测数据发送到 DataDog 代理（作为 sidecar 或其他东西运行）......
我们是否能够使用这种 DataDog 方法，但不是将检测数据发送到 DataDog 代理，而是将其发送到 Open Telemerty Collecter 代理？从技术上讲，如果我们愿意，Open Telemerty Collecter 代理仍然可以发送到 DataDog（即使用DataDog 导出器），但至少我们会使用这种方法减轻供应商锁定。想法...