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

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

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

以下のベストプラクティスとテクニックは、.NETインストルメンテーションによるオーバーヘッドを減らすのに役立つかもしれません。

トレースサンプリングの設定

インストルメンテーションによって処理されるスパンの量は、インストルメンテーションのオーバーヘッドに影響を与える可能性があります。トレースサンプリングを構成して、スパンボリュームを調整し、リソース使用量を削減できます。サンプリング設定とその影響の詳細については、「サンプラーの設定」を参照してください。

特定のインストルメンテーションをオフにする

インストルメンテーションのオーバーヘッドとスパン量をさらに削減するために、不要なインストルメンテーションや、多すぎるスパンを生成しているインストルメンテーションをオフにすることを検討してください。インストルメンテーションをオフにするには、 OTEL_DOTNET_AUTO_TRACES_{name}_INSTRUMENTATION_ENABLED 環境変数を使用します。{name} はインストルメンテーションの名前です。

例えば、以下のオプションは、SqlClient インストルメンテーションをオフにします：

OTEL_DOTNET_AUTO_TRACES_SQLCLIENT_INSTRUMENTATION_ENABLED=false

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

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

適切なリソースの提供

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

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

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

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

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

• 最低条件を確認してください。「本番導入のための最低要件」を参照してください。

• .NETインストルメンテーションの最新の互換バージョンを使用します。

• 最新の.NET互換バージョンを使用します。

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

• アプリケーションがメモリ制限に近づいている場合は、より多くのメモリを与えることを検討してください。

• アプリケーションがすべてのCPUを使用している場合は、水平方向にスケーリングすることをお勧めします。

• メトリクスをオフにするか、チューニングしてみてください。 「インストルメンテーション設定」を参照してください。

• スパン量を減らすためにトレースサンプリング設定を調整します。 「サンプラーの設定」を参照してください。

• 特定のインストルメンテーションをオフにします。「特定のインストルメンテーションをオフにする」を参照してください。

• 不要なスパンが発生していないか、手動インストルメンテーションを見直します。

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

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

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

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

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

• ユーザー平均、ユーザーピーク、マシン平均CPU使用率

• 総割り当てメモリと最大ヒープ使用量

• ガベージコレクション休止時間

• 起動時間（ミリ秒

• 平均およびパーセンタイル95（p95）のサービス遅延

• ネットワークの読み取りと書き込みの平均スループット

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

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

1. テスト環境の構成が本番環境に似ていることを確認します。

2. テスト対象のアプリケーションを、干渉する可能性のある他のサービスから隔離します。

3. アプリケーションホスト上の不要なシステムサービスをすべてオフにするか、削除します。

4. アプリケーションに、テスト作業負荷を処理するのに十分なシステムリソースがあることを確認します。

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

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

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

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

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

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

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

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

• 条件B：インストルメンテーションあり

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

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

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

サポートを受ける方法