Open Telemetry Collector Project と、これがコンテナー化された .NET Core アプリ (またはその他のアプリ) でどのように機能するかを調べています。
現在、私が働いている会社で DynaTrace を使用しています。これには、ホストに DynaTrace 'OneAgent' エージェントをインストールする必要があります。DynaTrace エージェントは何らかの方法で dotnet CLR にフックし、バイトコード/MSIL インストルメンテーションを実行します。基本的に、このアプローチにより、アプリでコードを変更することなく、APM データを DynaTrace にキャプチャできます。
これを Open Telemetry アプローチと比較してください。Open Telemetry アプローチでは、(私が知る限り) 追加の (ナゲット) パッケージをインストルメント化するサービスにインストールする必要があります。.NET Core の世界では、AOP の一種である DiagnosticSource ベースのインストルメンテーションを使用していると思われます。とはいえ、ほとんど自動で、ASP.NET、Entity Framework などのさまざまな .NET ライブラリ/フレームワークに統合されています。したがって、コードの変更は次のとおりです。a) Open Telemetry nuget パッケージのインストール、b) 基本的な Startup.cs 構成、および c) 必要に応じて必要に応じて追加のスパンを追加する。これは最小限のコードですが、DynaTrace アプローチのようなノーコードではありません。また、スパンの粒度は、DynaTrace で使用されるバイトコード/MSIL インストルメンテーション アプローチよりもはるかに粗いと思います。
Open Telemetry Collector の WRT。独自のエージェントをインストールすることなく、サポートされているサードパーティの監視ソリューション (DataDog、Elastic、Kafka など) にインストルメンテーション データを送信するようにエクスポーターを構成できるという事実が本当に気に入っています。IMO このアプローチは、使用している可能性のある監視サービスをより簡単に変更できることを意味し、したがってベンダー ロックを軽減します。
両方の長所を活かす方法を見つけたいと思っています。
- ベンダー ロックを軽減できるように、Open Telemerty Collector エージェントを使用したいと考えています。基礎となる監視ソリューションを変更できることで、より安価な監視ソリューションに切り替えることで数十万ドルを節約できる可能性があります (または、少なくとも切り替えの脅威が現実のものとなり、より安価なコストについて交渉できるようになります)!
- アプリでコードや構成を変更する必要がないように、バイトコード/MSIL インストルメンテーション アプローチを使用したいと考えています。
これは可能ですか？
ここでDataDog エージェントがどのように機能するかを見ていました。これは、DynaTrace と同様のアプローチのようです。DataDog の場合、いくつかの CLR 環境変数をアプリ コンテナーに設定する必要があるようです。おそらく、これにより CLR が拡張され、バイトコード/MSIL 計測データが DataDog エージェント (サイドカーなどとして実行されます) に送信されます...
この DataDog アプローチを使用できますか? ただし、計測データを DataDog エージェントに送信する代わりに、Open Telemerty Collector エージェントに送信しますか? 技術的には、Open Telemerty Collector エージェントは、必要に応じて (つまり、DataDog エクスポーターを使用して) DataDog に送信できますが、少なくともこのアプローチを使用してベンダー ロックを軽減できます。考え...