Splunk Distribution of OpenTelemetry .NET のパフォーマンスリファレンス 🔗
OpenTelemetry .NET の Splunk ディストリビューションは、同じ .NET AppDomain 内で実行することで、アプリケーションをインストルメンテーションします。他のソフトウェアインストルメンテーションと同様に、.NET インストルメンテーションは CPU、メモリ、ネットワーク帯域幅などのシステムリソースを必要とします。インストルメンテーションによるリソースの使用は、インストルメンテーションのオーバーヘッドまたはパフォーマンスのオーバーヘッドとして知られています。
Splunk Distribution of OpenTelemetry .NET は、.NET アプリケーションをインストルメンテーションする際にシステムパフォーマンスへの影響を最小限に抑えますが、最終的なインストルメンテーションのオーバーヘッドは複数の要因に依存します。インストルメンテーションのオーバーヘッドを増加させる可能性のある要因には、物理的なマシンアーキテクチャー、CPU の周波数、メモリの量と速度、システム温度などの環境要因があります。その他の要因としては、仮想化とコンテナ化、オペレーティングシステムとそのライブラリ、.NETバージョン、ソフトウェアのアルゴリズム設計、ソフトウェアの依存関係などがあります。
最新のソフトウェアは複雑であり、デプロイメントシナリオも多様であるため、インストルメンテーションのオーバーヘッドを1つで見積もることは不可能です。特定のデプロイメントにおけるインストルメンテーションのオーバーヘッドを求めるには、実験を実施し、直接測定を収集する必要があります。したがって、パフォーマンスに関するすべての記述は、特定のシステムで評価される一般的な情報およびガイドラインとして扱われなければなりません。
以下のセクションでは、OpenTelemetry .NET インストルメンテーションの Splunk ディストリビューションの最小要件、パフォーマンスに影響を与える潜在的な制約、インストルメンテーションのパフォーマンスを最適化しトラブルシューティングするためのガイドラインについて説明します。
本番導入のための最低要件 🔗
Splunk Distribution of OpenTelemetry .NETは、以下の .NET バージョンをサポートしています：
トレースとメトリクスのためのインストルメンテーション：
.NET 8.0（サポート終了：2026年11月10日）
.NET 6.0（サポート終了：2024年11月12日）
.NET Framework 4.7以上
.NET Framework 4.6.2（サポート終了：2027年1月12日）
AlwaysOn Profiling:
.NET 8.0（サポート終了：2026年11月10日）
.NET 6.0（サポート終了：2024年11月12日）
注釈
.NET Framework is not supported for AlwaysOn Profiling.
注釈
.NET 7 reached End of Life on May 14, 2024. Best effort support is provided for the last version only, 7.0.19, which was tested using Splunk Distribution of OpenTelemetry .NET version 1.5.0.
このディストリビューションは以下のアーキテクチャーをサポートしています：
x86
AMD64 (x86-64)
注釈
ARMアーキテクチャーはサポートされていません。
インストルメンテーションのオーバーヘッドを削減するためのガイドライン 🔗
以下のベストプラクティスとテクニックは、.NETインストルメンテーションによるオーバーヘッドを減らすのに役立つかもしれません。
トレースサンプリングの設定 🔗
インストルメンテーションによって処理されるスパンの量は、インストルメンテーションのオーバーヘッドに影響する可能性があります。スパン量を調整し、リソース使用量を削減するために、トレースサンプリングを設定することができます。サンプリング設定とその効果の詳細については、サンプラーの設定 を参照してください。
特定のインストルメンテーションをオフにする 🔗
インストルメンテーションのオーバーヘッドとスパン量をさらに削減するために、必要でないインストルメンテーションや、多すぎるスパンを生成しているインストルメンテーションをオフにすることを検討してください。インストルメンテーションをオフにするには、OTEL_DOTNET_AUTO_TRACES_{name}_INSTRUMENTATION_ENABLED 環境変数を使用します。{name} はインストルメンテーションの名前です。
例えば、以下のオプションは、SqlClient インストルメンテーションをオフにします：
OTEL_DOTNET_AUTO_TRACES_SQLCLIENT_INSTRUMENTATION_ENABLED=false
注釈
Splunk APM のトレースアナライザを使用して、アプリケーションからのスパンを探索し、不要なインストルメンテーションを特定します。詳細は Splunk APMのTrace Analyzerを使用してトレースを調査する を参照してください。
手作業によるインストルメンテーションを最小限に抑える 🔗
手動インストルメンテーションは、インストルメンテーションのオーバヘッドを増加させる非効率性をもたらすかもしれません。例えば、すべてのメソッドでアクティビティを開始すると、スパンボリュームが大きくなり、データのノイズが増加し、システムリソースが消費されます。適切または必要な場合にのみ、手動インストルメンテーションを使用してください。
適切なリソースの提供 🔗
インストルメンテーションと Collector に十分なリソースを用意してください。メモリやディスクなどのリソースの量は、アプリケーションのアーキテクチャーやニーズによって異なります。例えば、一般的なセットアップは、Splunk Distribution of OpenTelemetry Collector と同じホスト上でインストルメンテーションアプリケーションを実行することです。その場合、Collector のリソースのサイズ変更と設定の最適化を検討してください。サイジングとスケーリング を参照してください。
.NETインストルメンテーションのパフォーマンスに影響する制約事項 🔗
一般的に、アプリケーションから収集するテレメトリが多ければ多いほど、インストルメンテーションのオーバーヘッドに与える影響は大きくなります。例えば、アプリケーションに関係のないメソッドをトレースしても、インストルメンテーションオーバーヘッドはかなり発生します。同様に、メトリクスでカーディナリティの高いタグを使用すると、メモリ使用量が増加する場合があります。デバッグロギングも、ディスクへの書き込み操作とメモリ使用量を増加させます。
インストルメンテーションのオーバーヘッド問題のトラブルシューティング 🔗
インストルメンテーションのオーバヘッドの問題をトラブルシューティングする場合は、以下のようにしてください：
最低条件を確認します。本番導入のための最低要件 を参照してください。
.NETインストルメンテーションの最新の互換バージョンを使用します。
最新の.NET互換バージョンを使用します。
インストルメンテーションのオーバヘッドを減らすために、以下の措置を講じることを検討します：
アプリケーションがメモリ制限に近づいている場合は、より多くのメモリを与えることを検討してください。
アプリケーションがすべてのCPUを使用している場合は、水平方向にスケーリングすることをお勧めします。
メトリクスをオフにするか、チューニングしてみてください。インストルメンテーション設定 を参照してください。
スパン量を減らすためにトレースサンプリング設定を調整します。サンプラーの設定 を参照してください。
特定のインストルメンテーションをオフにします。特定のインストルメンテーションをオフにする を参照してください。
不要なスパンが発生していないか、手動インストルメンテーションを見直します。
インストルメンテーションのオーバーヘッドを測定するためのガイドライン 🔗
独自の環境やデプロイメントでインストルメンテーションのオーバーヘッドを測定することで、アプリケーションやサービスのパフォーマンスに対するインストルメンテーションの影響に関する正確なデータを得ることができます。以下のガイドラインでは、信頼性の高いインストルメンテーションオーバーヘッドの測定を収集し、比較するための一般的な手順を説明します。
何を測定したいかを決める 🔗
アプリケーションやサービスのユーザーによって、インストルメンテーションのオーバーヘッドに気づく側面は異なる可能性があります。例えば、エンドユーザーはサービスのレイテンシの低下に気づくかもしれませんが、重いワークロードを持つパワーユーザーはCPUオーバーヘッドにより注意を払います。一方、弾力的なワークロードなどで頻繁にデプロイするユーザーは、起動時間の方を注意します。
無関係な情報を含むデータセットを生成しないように、測定はアプリケーションのユーザーエクスペリエンスに確実に影響する要素に絞ります。測定値の例には、次のようなものがあります：
ユーザー平均、ユーザーピーク、マシン平均CPU使用率
総割り当てメモリと最大ヒープ使用量
ガベージコレクション休止時間
起動時間（ミリ秒
平均およびパーセンタイル95（p95）のサービス遅延
ネットワークの読み取りと書き込みの平均スループット
適切なテスト環境を準備する 🔗
管理されたテスト環境でインストルメンテーションのオーバーヘッドを測定することにより、性能に影響を与える要因をより適切に管理し、特定することができます。テスト環境を準備する際には、以下のことを行ってください：
テスト環境の構成が本番環境に似ていることを確認します。
テスト対象のアプリケーションを、干渉する可能性のある他のサービスから隔離します。
アプリケーションホスト上の不要なシステムサービスをすべてオフにするか、削除します。
アプリケーションに、テスト作業負荷を処理するのに十分なシステムリソースがあることを確認します。
現実的なテストのバッテリーを作る 🔗
テスト環境に対して実行するテストは、できるだけ典型的なワークロードに似せて設計します。たとえば、サービスの REST API エンドポイントが大量のリクエストの影響を受けやすい場合、大量のネットワークトラフィックをシミュレートするテストを作成します。
.NETアプリケーションでは、測定を開始する前にウォームアップフェーズを使用します。.NETは非常に動的なマシンで、ジャストインタイムコンパイル（JIT）により多数の最適化を実行します。ウォームアップフェーズは、アプリケーションのクラスロードの大部分を終了させ、JITコンパイラに最適化の大部分を実行させる時間を与えます。
多くのリクエストを実行し、テストパスを何度も繰り返すようにしてください。この繰り返しは、代表的なデータサンプルの確保に役立ちます。テストデータにエラーシナリオを含めます。通常の作業負荷と同様のエラー率をシミュレートします（通常2％～10％）。
比較可能な測定値を集める 🔗
性能に影響を与え、インストルメンテーションのオーバーヘッドを引き起こしている可能性のある要因を特定するには、1つの要因や条件を変更した後、同じ環境で計測を収集します。
例えば、インストルメンテーションの有無と設定だけが異なる2種類の計測を行うことができる：
条件A：インストルメンテーションまたはベースラインなし
条件B：インストルメンテーションあり
インストルメンテーションのオーバーヘッドデータを分析する 🔗
複数のパスからデータを収集した後、単純な統計検定を使って平均値を比較し、有意差をチェックしたり、結果をグラフにプロットしたりすることができます。
スタック、アプリケーション、環境が異なれば、運用特性も異なり、インストルメンテーションのオーバーヘッド測定結果も異なる可能性があることを考慮してください。
サポートを受ける方法 🔗
Splunk Observability Cloudをご利用のお客様で、Splunk Observability Cloudでデータを確認できない場合は、以下の方法でサポートを受けることができます。
Splunk Observability Cloudをご利用のお客様
Splunk サポートポータル でケースを送信する
Contact Splunk Support .
見込み客および無料トライアルユーザー様
Splunk Answers のコミュニティサポートで質問し、回答を得る
Splunk #observability ユーザーグループの Slack チャンネルに参加して、世界中の顧客、パートナー、Splunk 社員とのコミュニケーションを図る。参加するには、Get Started with Splunk Community マニュアルの チャットグループ を参照してください。