Splunk OTel Node.js エージェントのパフォーマンスリファレンス

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

エージェントのオーバーヘッドを削減するためのガイドライン

以下のベストプラクティスとテクニックは、Node.jsエージェントによるオーバーヘッドを削減するのに役立つ可能性があります。

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

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

次の例は、unwanted という名前のスパンをドロップするように、コード内でトレースサンプリングを設定する方法を示しています：

const { start } = require("@splunk/otel");
const { SamplingDecision } = require("@opentelemetry/sdk-trace-base");

start({
tracing: {
   tracerConfig: {
      sampler: {
        shouldSample: (context, traceId, spanName, spanKind, attributes, links) => {
           if (spanName ===  "unwanted") {
              return { decision: SamplingDecision.NOT_RECORD };
           }

           return { decision: SamplingDecision.RECORD };
        },
        toString: () => return "CustomSampler",
      }
   },
},
});

必要なインストルメンテーションだけをオンにする

エージェントのオーバーヘッドとスパンの量をさらに減らすために必要なインストルメンテーションのみをオンにすることを検討してください。デフォルトのインストルメンテーションをすべてオフにするには、OTEL_INSTRUMENTATION_COMMON_DEFAULT_ENABLED を false に設定し、OTEL_INSTRUMENTATION_<NAME>_ENABLED 環境変数を使用して特定のインストルメンテーションを有効にします。<NAME> はインストルメンテーションの名前です。

たとえば、次のオプションは、他のすべてのインストルメンテーションを非アクティブにしたまま、Bunyanインストルメンテーションをオンにします：

export OTEL_INSTRUMENTATION_COMMON_DEFAULT_ENABLED=false
export OTEL_INSTRUMENTATION_BUNYAN_ENABLED=true

前の設定は、デフォルトで Splunk Distribution of OpenTelemetry JS によってロードされたインストルメンテーションにのみ適用されます。プログラム API を使用してユーザー指定のインストルメンテーションのリストを提供する場合、以前の設定は効果がありません。使用可能なインストルメンテーションの完全なリストについては、「要件」を参照してください。

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

手動インストルメンテーションでは、非効率的になることでエージェントのオーバーヘッドが増加する可能性があります。たとえば、タイトなループでスパンを作成すると、何百万ものスパンを生成することになり、ホストに大きな負担をかけることになる可能性があります。

適切なリソースの提供

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

Node.jsエージェントのパフォーマンスに影響を与える制約

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

たとえば JDBC や Redis のようないくつかのインストルメンテーションは、エージェントのオーバーヘッドを増加させる高いスパンボリュームを生成します。不要なインストルメンテーションをオフにする方法の詳細については、「必要なインストルメンテーションのみをオンにする」を参照してください。

エージェントのオーバーヘッド問題のトラブルシューティング

エージェントのオーバーヘッドの問題をトラブルシューティングする場合は、次のようにしてください：

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

• 互換性のある最新のNode.jsエージェントを使用してください。

• 互換性のあるNode.jsの最新バージョンを使用します。

エージェントのオーバーヘッドを減少させるために、以下の措置を講じることを検討します：

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

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

• CPU またはメモリのプロファイリングをオフにするか、チューニングしてみてください。 「AlwaysOn Profiling の Node.js 設定」を参照してください。

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

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

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

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

• イベントループの遅延をチェックするために、ランタイムメトリクスをオンにします。「メトリクスコレクションを有効にする」を参照してください。

エージェントのオーバーヘッドを測定するためのガイドライン

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

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

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

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

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

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

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

• 起動時間（ミリ秒

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

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

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

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

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

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

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

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

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

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

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

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

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

どの要因がパフォーマンスに影響を与え、エージェントのオーバーヘッドを引き起こしているかを特定するために、1つの要因や条件を変更した後に、同じ環境で測定を収集します。

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

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

• 条件 B：AlwaysOn Profilingを使用しないインストルメンテーション

• 条件 C: AlwaysOn Profiling によるインストルメンテーション

エージェントのオーバーヘッドデータを分析する

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

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

また、https://opentelemetry.io/ja/docs/languages/js/benchmarks/ にある公式の OpenTelemetry JS ベンチマークと結果を比較することもできます。

サポートを受ける方法