Splunk Distribution of OpenTelemetry .NET のパフォーマンスリファレンス

Splunk OTel .NET インストルメンテーションの最小要件、パフォーマンスに影響を与える潜在的な制約、インストルメンテーションのパフォーマンスを最適化しトラブルシューティングするためのガイドライン。

Splunk Distribution of OpenTelemetry .NET は、同じ .NET AppDomain 内で実行することでアプリケーションをインストルメンテーションします。他のソフトウェアインストルメンテーションと同様に、.NET インストルメンテーションでは、 CPU、メモリ、ネットワーク帯域幅などのシステムリソースが必要です。インストルメンテーションによるリソースの使用は、インストルメンテーションのオーバーヘッドまたはパフォーマンスのオーバーヘッドと呼ばれます。

Splunk Distribution of OpenTelemetry .NET インストルメンテーションでは、.NET アプリケーションをインストルメンテーションする際のシステムパフォーマンスへの影響は最小限となります。ただし、最終的なインストルメンテーションのオーバーヘッドは、複数の要因に依存します。インストルメンテーションのオーバーヘッドを増加させる可能性のある要因は、物理マシンのアーキテクチャ、 CPU の周波数、メモリの量と速度、システムの温度、環境などです。その他の要因には、仮想化とコンテナ化、オペレーティングシステムとそのライブラリ、.NET バージョン、ソフトウェアのアルゴリズム設計、およびソフトウェアの依存関係があります。

最新のソフトウェアの複雑さとデプロイメントシナリオの幅広い多様性により、単一のインストルメンテーションのオーバーヘッドの見積もりを提示することは不可能です。特定のデプロイメントでのインストルメンテーションのオーバーヘッドを見つけるには、実験を実施して測定値を直接収集する必要があります。したがって、パフォーマンスに関するステートメントはすべて、特定のシステムでの評価に依存する一般的な情報およびガイドラインとして扱う必要があります。

以下のセクションでは、OpenTelemetry .NET インストルメンテーションの Splunk ディストリビューションの最小要件、パフォーマンスに影響を与える潜在的な制約、インストルメンテーションのパフォーマンスを最適化しトラブルシューティングするためのガイドラインについて説明します。

本番導入のための最低要件

Splunk Distribution of OpenTelemetry .NETは、以下の .NET バージョンをサポートしています：

トレースとメトリクスのためのインストルメンテーション：
- .NET 9.0（サポート終了：2026年5月12日）
- .NET 8.0（サポート終了：2026年11月10日）
- .NET Framework 4.7以上
- .NET Framework 4.6.2（サポート終了：2027年1月12日）
AlwaysOn Profiling:
- .NET 9.0（サポート終了：2026年5月12日）
- .NET 8.0（サポート終了：2026年11月10日）
  
  注: .NET FrameworkはAlwaysOn Profilingに対応していません。

注意: Splunk Distribution of OpenTelemetry .NET バージョン 1.9.0 は、すでにサポートが終了している .NET 6 または .NET 7 と互換性がありません。.NET 6 または .NET 7 サービスのインストルメンテーションを継続する場合は、Splunk Distribution of OpenTelemetry .NET バージョン 1.8.0 以下を使用してください。Splunk Distribution of OpenTelemetry .NET のベストエフォートサポートは、.NET 6（バージョン 6.0.36）および .NET 7（バージョン 7.0.20）の最新バージョンに対してのみ、2025 年 11 月 12 日まで提供されます。

このディストリビューションは以下のアーキテクチャをサポートしています：

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 の Trace Analyzer を使用して、アプリケーションからのスパンを探索し、不要なインストルメンテーションを特定します。「Splunk APM の Trace Analyzer を使用してトレースを調査する」を参照してください。

手作業によるインストルメンテーションを最小限に抑える

手作業によるインストルメンテーションでは、非効率性が生じ、インストルメンテーションのオーバーヘッドが増加する可能性があります。たとえば、すべてのメソッドでアクティビティを開始すると、スパンボリュームが大きくなり、データのノイズが増加し、より多くのシステムリソースが消費されます。手作業によるインストルメンテーションは、適切または必要な場合にのみ活用してください。

適切なリソースの提供

インストルメンテーションと Collector に十分なリソースをプロビジョニングしてください。メモリやディスクなどのリソースの量は、アプリケーションのアーキテクチャとニーズによって異なります。たとえば、一般的なセットアップでは、Splunk Distribution of OpenTelemetry Collector と同じホストでインストルメンテーションされたアプリケーションを実行します。その場合は、Collector のリソースの適切なサイズ設定とその設定の最適化を検討してください。「サイジングとスケーリング」を参照してください。

.NETインストルメンテーションのパフォーマンスに影響する制約事項

一般に、アプリケーションから収集されるテレメトリが多くなるほど、インストルメンテーションのオーバーヘッドへの影響が大きくなります。たとえば、アプリケーションと関連しないメソッドをトレースする場合などは、メソッド自体を実行するよりも計算コストがかかるため、インストルメンテーションに大きなオーバーヘッドが発生する可能性があります。同様に、メトリクスの基数が高いと、メモリ使用率が高くなる可能性があります。デバッグロギングにより、ディスクおよびメモリ使用量への書き込み操作も増加します。

インストルメンテーションのオーバーヘッド問題のトラブルシューティング

インストルメンテーションのオーバヘッドの問題をトラブルシューティングする場合は、以下のようにしてください：

最低条件を確認してください。「本番導入のための最低要件」を参照してください。
.NETインストルメンテーションの最新の互換バージョンを使用します。
最新の.NET互換バージョンを使用します。

インストルメンテーションのオーバヘッドを減らすために、以下の措置を講じることを検討します：

アプリケーションがメモリ制限に近づいている場合は、より多くのメモリを与えることを検討してください。
アプリケーションがすべてのCPUを使用している場合は、水平方向にスケーリングすることをお勧めします。
メトリクスをオフにするか、チューニングしてみてください。「インストルメンテーション設定」を参照してください。
スパン量を減らすためにトレースサンプリング設定を調整します。「サンプラーの設定」を参照してください。
特定のインストルメンテーションをオフにします。「特定のインストルメンテーションをオフにする」を参照してください。
不要なスパンが発生していないか、手動インストルメンテーションを見直します。

インストルメンテーションのオーバーヘッドを測定するためのガイドライン

独自の環境やデプロイメントでインストルメンテーションのオーバーヘッドを測定することで、アプリケーションやサービスのパフォーマンスに対するインストルメンテーションの影響に関する正確なデータを得ることができます。次のガイドラインでは、信頼性の高いインストルメンテーションオーバーヘッドの測定値を収集して比較するための一般的な手順について説明します。

何を測定したいかを決める

さまざまなユーザーがアプリケーションやサービスを使用することで、インストルメンテーションのオーバーヘッドのさまざまな側面が明らかになる場合があります。たとえば、エンドユーザーはサービス遅延の低下に気付く可能性がある一方で、高負荷のワークロードを持つパワーユーザーは CPU オーバーヘッドに注意を払います。一方で、柔軟性のあるワークロードなどのために、頻繁にデプロイするユーザーは、スタートアップ時間により多くの注意を払う必要があります。

無関係な情報を含むデータセットを生成しないように、測定はアプリケーションのユーザーエクスペリエンスに確実に影響する要素に絞ります。測定の例には、次のものがあります。

ユーザー平均、ユーザーピーク、マシン平均CPU使用率
総割り当てメモリと最大ヒープ使用量
ガベージコレクション休止時間
起動時間（ミリ秒
平均およびパーセンタイル95（p95）のサービス遅延
ネットワークの読み取りと書き込みの平均スループット

適切なテスト環境を準備する

コントロールされたテスト環境でインストルメンテーションのオーバーヘッドを測定すると、パフォーマンスに影響する要因をさらにコントロールして、特定することができます。テスト環境を準備する場合は、次のことを行います。

テスト環境の構成が本番環境に似ていることを確認します。
テスト対象のアプリケーションを、干渉する可能性のある他のサービスから隔離します。
アプリケーションホスト上の不要なシステムサービスをすべてオフにするか、削除します。
アプリケーションに、テスト作業負荷を処理するのに十分なシステムリソースがあることを確認します。

現実的なテストのバッテリーを作る

可能な限り一般的なワークロードと類似するように、テスト環境に対して実行するテストを設計します。たとえば、サービスの REST API エンドポイントが大量のリクエストの影響を受けやすい場合、大量のネットワークトラフィックをシミュレートするテストを作成します。

.NET アプリケーションの場合は、測定を開始する前にウォームアップフェーズを使用します。.NET は高度にダイナミックなマシンで、Just-In-Time コンパイル（JIT）を通じて多数の最適化を実行します。ウォームアップフェーズは、アプリケーションがそのクラスのロードの大部分を完了するのに役立ち、JIT コンパイラが最適化の大部分を実行するために必要な時間を与えます。

大量の要求を実行し、テストの成功を何回も繰り返してください。この繰り返しにより、代表的なデータサンプルを確保できます。テストデータにエラーシナリオを含めます。通常のワークロードの場合と同様のエラー率をシミュレートします（通常は 2% ～ 10%）。

比較可能な測定値を集める

性能に影響を与え、インストルメンテーションのオーバーヘッドを引き起こしている可能性のある要因を特定するには、1つの要因や条件を変更した後、同じ環境で計測を収集します。

例えば、インストルメンテーションの有無と設定だけが異なる2種類の計測を行うことができる：

条件A：インストルメンテーションまたはベースラインなし
条件B：インストルメンテーションあり

インストルメンテーションのオーバーヘッドデータを分析する

複数のパスからデータを収集した後、単純な統計検定を使って平均値を比較し、有意差をチェックしたり、結果をグラフにプロットしたりすることができます。

スタック、アプリケーション、環境が異なれば、運用特性も異なり、インストルメンテーションのオーバーヘッド測定結果も異なる可能性があることを考慮してください。

サポートを受ける方法

__ ___ ___ _ ______ _____________ _____ ________ ___ ___ ___ ____ __ ___ ____ ____ __ ______ _____________ ______ ___ ___ ___ ____ __ ___ _________ _____

_________ __ ______ _____________ _____ _________

______ _ ____ __ ___ ______ _______ _______
_______ ______ ________

_________ __ ___________ _________ ___ ____ _____ _____

___ _ ________ ___ ___ _______ _______ _________ _______ __ ______ ________
____ ___ ______ ______________ ____ _____ _____ _______ __ ___________ ____ __________ _________ ___ ______ _________ __________ __ _____ ___ ____ _______