アプリケーションのトラブルシューティング

構成済みのエラー検出ルールに従ってコントローラ UI の選択した時間内で検出されたすべてのトランザクションエラーは、[Errors] ページの [Error Transactions] タブに表示されます。

Splunk AppDynamics のデフォルトでは、トランザクションのコンテキストで以下のいずれかのタイプのイベントが検出された場合に、ビジネストランザクションがエラーであると見なされます。

• 未処理の例外またはエラー。発生した後キャッチされなかった例外や、ビジネストランザクションの終了後にキャッチされた例外は、トランザクションエラーとなり、Splunk AppDynamics に表示されます。ビジネストランザクションのコンテキスト内で発生しキャッチされた例外はトランザクションエラーとは見なされず、Splunk AppDynamics でキャプチャされません。
• Web サービスやデータベースコールなどの exit コールでキャッチされた例外。
• ステータスコード404または500の応答などのHTTPエラー応答。

• カスタム構成のエラーメソッドおよびエラーメッセージ。

エラー検出の構成については、「エラー検出」を参照してください。

ダウンストリームティアで発生し、発生元のティアに伝播されないエラーはビジネス トランザクション エラーにはなりません。たとえば、発生元のクライアントが 200 Success 応答を受信した場合、ビジネストランザクションはエラーとみなされません。ダウンストリームティアに含まれるエラーは、継続するセグメントの「1 分あたりのエラー数」メトリックにはカウントされます。

ビジネストランザクションにエラーが発生した場合は、エラートランザクションとしてのみカウントされます。トランザクションが遅延または停滞していた場合でも、遅い、非常に遅い、または停滞するトランザクションとしてカウントされません。

Splunk AppDynamics では、登録されたエラータイプの数を（エラーログイベント、例外チェーンなどに基づき）4000 までに制限しています。登録されたエラータイプの統計情報のみが保持されます。

制限に達すると、CONTROLLER_ERROR_ADD_REG_LIMIT_REACHED イベントが生成されます。上限を増やすことは可能ですが、キャプチャする必要がないエラーが無視されるようにデフォルトのエラー検出ルールを絞り込み、エラー登録数を減らすことを推奨します。

詳細については、「エラー検出」でログのエラーと例外を無視する構成に関する情報を参照してください。

ノードダッシュボードの [Memory] タブで [Automatic Leak Detection] にアクセスできます。[Automatic Leak Detection] はデフォルトで無効になっています。これは、JVM のオーバーヘッドが増加するためです。メモリリークの問題が疑われる場合にのみリーク検知モードを有効化してください。リークの原因を特定したら、[Automatic Leak Detection] は無効にします。

自動リーク検知は、On Demand Capture Sessionsを使用して、キャプチャ期間内に積極的に使用されるコレクション（JDK Map または Collection インターフェイスを実装するクラス）をキャプチャします。デフォルトのキャプチャ期間は10分です。

Splunk AppDynamics は、以下の基準を満たすすべての Java コレクションを追跡します。

• コレクションが少なくとも 30 分間有効である
• コレクションに少なくとも 1000 個のエレメントがある。
• コレクションのディープサイズは少なくとも 5 MB。エージェントは、コレクションのすべてのオブジェクトについて再帰的にオブジェクトグラフを横断し、ディープサイズを計算します。

リーク検知基準のデフォルトは、以下のノードプロパティで定義されます。

• minimum-age-for-evaluation-in-minutes

• minimum-number-of-elements-in-collection-to-deep-size

• minimum-size-for-evaluation-in-mb

「アプリケーション エージェントのノードプロパティ」を参照してください。

Javaエージェントはコレクションを追跡し、線形回帰モデルを使ってリークの可能性を識別します。一定期間のコレクションへの頻繁なアクセスを追跡することで、リークの根本原因を特定できます。

コレクションが基準を満たすと、Splunk AppDynamics はコレクションのサイズの長期的な成長傾向をモニタリングします。プラスの成長は、コレクションがメモリリークの元である可能性を示しています。

Splunk AppDynamics がリーク元コレクションを特定すると、Java エージェントは 30 分ごとに自動的に診断をトリガーします。診断では、コードパスのシャローコンテンツダンプとアクティビティトレース、およびコレクションにアクセスするビジネストランザクションがキャプチャされます。エージェントによってモニタリングされるリーク元コレクションをドリルダウンすることで、コンテンツサマリキャプチャセッションとアクセストラッキングセッションを手動でトリガーできます。

また、カスタムメモリ構造のメモリリークをモニタリングすることもできます。通常、カスタムメモリ構造はキャッシングソリューションとして使用されます。分散環境では、キャッシングがメモリリークの主な原因になりやすい傾向があります。そのため、こうしたメモリ構造のメモリ統計を管理および追跡することが重要です。それには、事前にカスタムメモリ構造を構成する必要があります。「Javaのカスタムメモリ構造」を参照してください。

[Node] ダッシュボードを使用してメモリリークを特定します。メモリリークの可能性は、ヒープの増加傾向とOld/Tenured世代のメモリプールからわかります。

急激に増加に傾いている場合、オブジェクトは自動的にリークの可能性があるオブジェクトとしてマークされます。

[Automatic Memory Leak] ダッシュボードには、次のものが表示されます。

• Collection Size：コレクションのエレメントの数。
• Potentially Leaking：リークしている可能性のあるコレクションは赤で表示される。リークの可能性があるオブジェクトに対して診断セッションを開始する必要がある。
• Status：診断セッションがオブジェクトで開始された場合に示される。
• Collection Size Trend：急激に増加に傾いている場合はメモリリークの可能性がある。

キャプチャされたコレクションが表示されない場合は、潜在的なメモリリークを検出するための構成が正しいことを確認してください。

コレクションでメモリスラッシング問題が特定されたら、問題が疑われるクラスにドリルダウンして診断セッションを開始します。

モニターするクラス名を選択し、オブジェクト インスタンス トラッキング ダッシュボード上部にある [Drill Down] をクリックするか、クラス名を右クリックし、[Drill Down] オプションを選択します。

ドリルダウンアクションがトリガーされると、オブジェクトインスタンスのデータコレクションが毎分実行されます。このデータコレクションは診断セッションと見なされ、そのクラスのオブジェクト インスタンス トラッキング ダッシュボードのアイコン（）が更新され、診断セッションが進行中であることが示されます。

オブジェクト インスタンス トラッキング ダッシュボードは、メモリスラッシングの可能性を示します。オブジェクト インスタンス トラッキング ダッシュボードに表示されるメモリスラッシング問題の主な指標は以下のとおりです。

• Current Instance Count：大きな数は、数多くある一時オブジェクトの割り当ての可能性を示す。
• Shallow Size：クラスのすべてのインスタンスが使用する大まかなメモリ。シャローサイズが大きいとメモリスラッシングの可能性がある。
• Instance Count Trend：のこぎり状の波型はメモリスラッシングを示す。

この時点でメモリスラッシングの問題が疑われる場合は、そのことを確認する必要があります。「メモリスラッシングの確認」を参照してください。

マルチスレッドの開発環境では通常複数のロックを使用します。しかし、デッドロックが発生することがあります。考えられる原因を次に示します。

• ロックの順番が最適でない
• コールされるコンテキストが正しくない（たとえば、コールバック内）
• 2つのスレッドがお互いにイベントの知らせを待機している可能性がある

イベントリストにコードデッドロックを表示するには、[Filter By Event Type] リストで [Code Problems]（または [Code Deadlock]）を選択します。

コードデッドロックを検証するには、イベントリストのデッドロックイベントをダブルクリックし、コードデッドロックの [Summary] タブをクリックします。デッドロックの詳細が [詳細（Details）] タブに表示されます。 イベントのモニタリングイベントのモニタリング

マルチスレッド プログラミング手法は、非同期処理を必要とするアプリケーションで一般的に使用されています。このようなアプリケーションでは、各スレッドに固有のコールスタックがありますが、スレッドからロック、キャッシュ、カウンタなどの共有リソースにアクセスしなければならないこともあります。「スレッド相関の有効化」を参照してください。

このような場合、同期の手法を使ってスレッドの干渉を防ぐこともできますが、今度はスレッドどうしが共有リソースへのアクセスを奪い合う場合があります。その結果、アプリケーション パフォーマンスの低下やデータ整合性の問題が発生する可能性があります。

Splunk AppDynamics では、ビジネストランザクションとサービスエンドポイントのスレッドの競合に関する問題を特定して解決できます。JavaのマルチスレッドトランザクションのトレースJavaのマルチスレッドトランザクションのトレース

Splunk AppDynamics は、インストゥルメント化されたアプリケーションのスレッドの状態に基づいてスレッドの競合を検出します。

JVMにおける以下のブロック状態（待ち状態）が識別されます。

• ロックの取得（MONITOR_WAIT）
• 条件の待機（CONDOR_WAIT）
• スリープ状態（OBJECT_WAIT）
• ブロッキングI/Oオペレーション

Object.wait

• Thread.sleep
• Object.wait
• Thread.join
• LockSupport.parkNanos
• LockSupport.parkUntil
• LockSupport.park

ビジネス トランザクション フロー マップの [Potential Issues] ペインに、潜在的なスレッドの競合の問題に関するコントローラからの警告が表示されます。ここからブラウザを使用して、ビジネストランザクションまたはサービスエンドポイントのブロックされたスレッドと待機中のスレッドに関する追加情報にアクセスし、パフォーマンス問題の原因を特定できます。

以下のセクションでは、ブラウザを使用してビジネストランザクションとサービスエンドポイントの競合情報を表示する方法について説明します。

スレッドの競合情報を表示するには

1. トランザクション スナップショットのナビゲーションページで、[Potential Issues] ペインから Thread Contention の問題としてラベル付けされた項目を探します。時間の列には、ブロックされた時間（待ち時間）が表示されます。
2. ブロックされたメソッドの詳細情報を表示するには、スレッドの競合項目をクリックし、[Drill Down into Call Graph.] を選択します。コールグラフには、スレッドの競合に関連する次の情報が表示されます。
   • [Call Graph] ヘッダーの [Wait Time] および [Block Time] は、ビジネストランザクションの 1 つのセグメントにおけるスレッドの集約測定値を示します。
   • [Call Graph] ヘッダーの [Node] は、競合するスレッドをホストするノードの名前を指定します（上記の例では PojoNode）。
   • [Time] 列は、メソッドの合計セルフ時間を示します。
   • [Percent%] 列は、メソッドで費やされた時間を、スレッドの全体的な時間の割合として表示します。

   • [Thread State] 列は、メソッドのスレッド競合問題の程度を示します。灰色は問題なしを意味し、黄色から赤色までの網かけは、競合に関する問題のシビラティ（重大度）を表す。（バーの上にマウスを合わせると、スレッドの状態を構成する要素が表示される。これにはデフォルトでブロック時間と待ち時間が含まれる。スレッドの状態の詳細に CPU 時間を含めるには、開発モードを有効にする必要がある。）

3. ブロック時間または待機時間を示すスレッド状態の任意のメソッドを右クリックし、[View Details.] を選択します。[Thread Contention] 詳細ペインが表示されます。

   [Thread Contention] 詳細ペインでは、ブロックされたメソッドの名前が左上に表示され、[Thread Contention] の表に以下の情報が追加されます。

   エレメント	意味
   ブロックしているスレッド	ブロックしているオブジェクトのロックを保持するスレッド
   ブロックしているオブジェクト	ブロックされたスレッドがアクセスを待っているオブジェクト。
   ブロック時間	オブジェクトへアクセスするための待ち時間合計。
   行番号	ブロックされたメソッドで、ブロックしているオブジェクトがアクセスされる行番号。上記の例では、run は行 114 でロックされたオブジェクトにアクセスしようとしています。

   この表で、ブロックしているスレッドの表示順は重要ではなく、コールの順番や時系列を表すものではありません。

Splunk AppDynamics では、サービス エンドポイント メソッドのスレッドの競合情報を表示できます。サービス エンドポイント メソッドは、コールグラフにアイコン で表されます。

サービス端末ごとのスレッドの競合情報を表示するには、メニューバーから [More] > [Service Endpoints] の順に選択します。

Node.js プロセスのイベントループは、着信接続をポーリングし、すべてのアプリケーションコードを実行する単一スレッドです。Node.js リクエストによって外部データベース、リモートサービス、またはファイルシステムが呼び出されると、イベントループはアプリケーションの制御フローを他のタスク（他の接続やコールバックを含む）に自動的に割り当てます。

CPU集約型オペレーションはイベントループをブロックするため、イベントループで受信リクエストの処理や既存のリクエストの完了ができなくなります。あるビジネストランザクションの CPU 集約型オペレーションによって、別のビジネストランザクションで遅延が発生する可能性があります。

プロセススナップショットは、インストゥルメント化されたNode.jsノードにおけるCPUプロセスのインスタンスを表します。これにより、構成可能な時間範囲におけるNode.jsプロセスの、プロセス全体のフレームグラフが生成されます。

プロセススナップショットは、プロセススナップショットの期間中にすべてのビジネストランザクションで発生した Node.js イベントループを可視化します。プロセススナップショットは、待機時間の原因が別のビジネストランザクションに含まれる CPU 集約型オペレーションであるために、主なトラブルシューティング ツール（ビジネス トランザクション スナップショットなど）で結論が得られない場合に便利です。プロセススナップショットのリストを使用して、CPU 時間の長いプロセスを特定できます。CPU をブロックしているコードの関数を正確に特定するプロセススナップショットをリストから選択し、調査できます。

特定の Node.js ノードまたはティアに関して、ノードまたはティアダッシュボードの [Process Snapshots] タブからプロセススナップショットのリストを確認できます。プロセス スナップショット リストにフィルタを使用して、必要なスナップショットのみを表示することも可能です。実行時間、スナップショットがアーカイブ済みかどうか、リクエストの GUID により絞り込むことができます。ティアダッシュボードからリストにアクセスする場合は、ノードごとにフィルタを使用できます。

プロセススナップショットの生成方法と構成方法については、「Node.jsプロセススナップショットの管理」を参照してください。

プロセススナップショットとビジネス トランザクション スナップショットの作成方法については、「」を参照してください。

プロセススナップショットは、通常14日間有効です。アーカイブすると永久に閲覧可能になります。

プロセススナップショットには、以下のタブが含まれます。

• 概要
• Flame Graph
• Call Graph
• Allocation Call Graphs
• Hot Spots

このページでは、プロセススナップショットの生成および表示の方法について説明します。

このページでは、によって作成されるトランザクション スナップショットとプロセススナップショットの関係について説明します。