Application Performance Monitoring (APM)

2 minutes

目標

このラボでは、AppDynamicsを使用してアプリケーションサービスの健全性を監視する方法を学びます。このワークショップの他のラボを開始する前に、まずこのラボを完了する必要があります。

このラボを完了すると、以下のことができるようになります

AppDynamics Java APM Agentをダウンロードする
AppDynamics Java APM Agentをインストールする
サンプルアプリケーションに負荷を発生させる
AppDynamics APMの基本概念を理解する
Controllerで収集設定を構成する
アプリケーションの健全性を監視する
アプリケーションのパフォーマンス問題をトラブルシューティングして根本原因を特定する
AppDynamicsがキャプチャしたデータに基づいてAppDynamicsの監視サービスでアラートを監視する

ワークショップ環境

ワークショップ環境には2つのホストがあります

1つ目のホストはAppDynamics Controllerを実行しており、以降はControllerと呼びます。
2つ目のホストはラボで使用するSupercar Traderアプリケーションを実行しています。ここにAppDynamicsエージェントをインストールするホストであり、以降はApplication VMと呼びます。

Controller

このワークショップでは AppDynamics SE Lab Controller を使用します。

Application VM

Supercar TraderはJavaベースのWebアプリケーションです。

Supercar-Traderコレクションの目的は、AppDynamics Controllerのための動的なトラフィック（Business Transactions）を生成することです。

1. Java Agent のダウンロード

この演習では、WebブラウザからAppDynamics Controllerにアクセスし、Java APMエージェントをダウンロードします。

Controller へのログイン

Ciscoの資格情報を使用して AppDynamics SE Lab Controller にログインします。

アプリケーションの設定

左側のナビゲーションパネルで Overview を選択します
Getting Started タブをクリックします
Getting Started Wizard ボタンをクリックします

Javaアプリケーションタイプを選択します

Java Agent のダウンロード

JVMタイプとして Sun/JRockit - Legacy を選択します
Controller接続のデフォルト設定を受け入れます
Set Application and Tier で Create a new Application: を選択します
アプリケーション名として Supercar-Trader-YOURINITIALS を入力します
新しいTierとして Web Portal を入力します
Node Nameとして Web-Portal_Node-01 を入力します
Continue をクリックします
Click Here to Download をクリックします

Warning

アプリケーション名は一意である必要があります。アプリケーション名にイニシャルを追加するか、一意の識別子を追加してください

ブラウザにエージェントがローカルファイルシステムにダウンロードされていることを示すプロンプトが表示されます。ファイルがダウンロードされた場所と完全なファイル名をメモしておいてください。

2. Java Agent のインストール

この演習では、以下のアクションを実行します

JavaエージェントファイルをEC2インスタンスにアップロードする
ファイルを特定のディレクトリに解凍する
JavaエージェントのXML設定ファイルを更新する（オプション）
Apache Tomcatの起動スクリプトを変更してJavaエージェントを追加する

Application VM への Java Agent のアップロード

この時点で、このワークショップで使用するEC2インスタンスに関する情報を受け取っているはずです。EC2インスタンスのIPアドレス、インスタンスにSSH接続するために必要なユーザー名とパスワードを確認してください。

ローカルマシンでターミナルウィンドウを開き、Javaエージェントファイルがダウンロードされたディレクトリに移動します。以下のコマンドを使用してファイルをEC2インスタンスにアップロードします。これには時間がかかる場合があります。

インスタンスのIPアドレスまたはパブリックDNSを更新してください。
ファイル名を正確なバージョンに合わせて更新してください。

cd ~/Downloads
scp -P 2222 AppServerAgent-22.4.0.33722.zip splunk@i-0b6e3c9790292be66.splunk.show:/home/splunk

(splunk@44.247.206.254) Password:
AppServerAgent-22.4.0.33722.zip                                                                    100%   22MB 255.5KB/s   01:26

Java Agent の解凍

インストラクターから割り当てられたインスタンスとパスワードを使用してEC2インスタンスにSSH接続します。

ssh -P 2222 splunk@i-0b6e3c9790292be66.splunk.show

Javaエージェントバンドルを新しいディレクトリに解凍します。

cd /opt/appdynamics
mkdir javaagent
cp /home/splunk/AppServerAgent-*.zip /opt/appdynamics/javaagent
cd /opt/appdynamics/javaagent
unzip AppServerAgent-*.zip

Tip

ControllerのGetting Started Wizardを使用してJavaエージェントを事前設定しました。AppDynamics Portalからエージェントをダウンロードした場合は、JavaエージェントのXML設定ファイルを手動で更新する必要があります。

Javaエージェントの設定プロパティを設定するには、主に3つの方法があります。これらは以下の順序で優先されます

システム環境変数
コマンドラインで渡されるJVMプロパティ
controller-info.xml ファイル内のプロパティ

Tomcat Server への Java Agent の追加

まず、Tomcatサーバーが実行されていないことを確認します

cd /usr/local/apache/apache-tomcat-9/bin
./shutdown.sh

次に、catalinaスクリプトを変更してJavaエージェントの環境変数を設定します。

cd /usr/local/apache/apache-tomcat-9/bin
nano catalina.sh

125行目（最初のコメントの後）に以下の行を追加してファイルを保存します

export CATALINA_OPTS="$CATALINA_OPTS -javaagent:/opt/appdynamics/javaagent/javaagent.jar"

サーバーを再起動します

./startup.sh

Tomcatサーバーが実行されていることを確認します。これには数分かかる場合があります

curl localhost:8080

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <title>Apache Tomcat/9.0.50</title>
        <link href="favicon.ico" rel="icon" type="image/x-icon" />
        <link href="tomcat.css" rel="stylesheet" type="text/css" />
    </head>

    <body>
        <div id="wrapper"
....

3. アプリケーション負荷の生成

この演習では、以下のアクションを実行します

サンプルアプリが実行されていることを確認する
サンプルアプリケーションの負荷生成を開始する
Controllerでトランザクション負荷を確認する

サンプルアプリケーションが実行されていることの確認

サンプルアプリケーションのホームページには、以下の形式のURLを使用してWebブラウザからアクセスできます。EC2インスタンスのIPアドレスに置き換えて、ブラウザのナビゲーションバーにURLを入力してください。

http://[ec2-ip-address]:8080/Supercar-Trader/home.do

Supercar Traderアプリケーションのホームページが表示されるはずです。

負荷生成の開始

EC2インスタンスにSSH接続し、負荷生成を開始します。すべてのスクリプトが実行されるまで数分かかる場合があります。

cd /opt/appdynamics/lab-artifacts/phantomjs
./start_load.sh

Cleaning up artifacts from previous load...
Starting home-init-01
Waiting for additional JVMs to initialize... 1
Waiting for additional JVMs to initialize... 2
Waiting for additional JVMs to initialize... 3
Waiting for additional JVMs to initialize... 4
Waiting for additional JVMs to initialize... 5
Waiting for additional JVMs to initialize... 6
Waiting for additional JVMs to initialize... 7
Waiting for additional JVMs to initialize... 8
Waiting for additional JVMs to initialize... 9
Waiting for additional JVMs to initialize... 10
Waiting for additional JVMs to initialize... 11
Waiting for additional JVMs to initialize... 12
Waiting for additional JVMs to initialize... 13
Waiting for additional JVMs to initialize... 14
Waiting for additional JVMs to initialize... 15
Waiting for additional JVMs to initialize... 16
Waiting for additional JVMs to initialize... 17
Waiting for additional JVMs to initialize... 18
Waiting for additional JVMs to initialize... 19
Waiting for additional JVMs to initialize... 20
Starting slow-query-01
Starting slow-query-02
Starting slow-query-03
Starting slow-query-04
Starting sessions-01
Starting sessions-02
Starting sell-car-01
Starting sell-car-02
Starting sessions-03
Starting sessions-04
Starting search-01
Starting request-error-01
Starting mem-leak-insurance
Finished starting load generator scripts                                                                100%   22MB 255.5KB/s   01:26

Controller でのトランザクション負荷の確認

WebブラウザでGetting Started Wizardがまだ開いている場合、エージェントが接続され、Controllerがデータを受信していることが確認できるはずです。

Continue をクリックすると、Application Flow Map に移動します（以下のFlow Mapの画像にジャンプできます）。

Controllerのブラウザウィンドウを以前に閉じた場合は、Controllerに再度ログインしてください。

Overviewページ（ランディングページ）から、左側のナビゲーションパネルの Applications タブをクリックします。
Applications ページでは、アプリケーションを手動で検索するか、右上の検索バーを使用して検索を絞り込むことができます。

アプリケーション名をクリックすると、Application Flow Map に移動します。12分後にすべてのアプリケーションコンポーネントが表示されるはずです。

12分経ってもすべてのアプリケーションコンポーネントが表示されない場合は、さらに数分待ってからブラウザタブを更新してください。

エージェントのダウンロード手順で、TomcatサーバーのTier名とNode名を割り当てました。

<tier-name>Web-Portal</tier-name>
<node-name>Web-Portal_Node-01</node-name>

他の4つのサービスのTier名とNode名がどのように割り当てられたか疑問に思うかもしれません。サンプルアプリケーションは、最初のTomcat JVMから4つの追加JVMを動的に作成し、4つのサービスそれぞれのJVM起動コマンドに -Dプロパティとしてこれらのプロパティを渡すことでTier名とNode名を割り当てます。JVM起動コマンドラインに含まれる -Dプロパティは、Javaエージェントの controller-info.xml ファイルで定義されたプロパティよりも優先されます。

動的に起動された4つのサービスそれぞれに使用されるJVM起動パラメータを確認するには、EC2インスタンスのターミナルウィンドウで以下のコマンドを実行します。

ps -ef | grep appdynamics.agent.tierName

splunk     47131   46757  3 15:34 pts/1    00:08:17 /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -javaagent:/opt/appdynamics/javaagent/javaagent.jar -Dappdynamics.controller.hostName=se-lab.saas.appdynamics.com -Dappdynamics.controller.port=443 -Dappdynamics.controller.ssl.enabled=true -Dappdynamics.agent.applicationName=Supercar-Trader-AppD-Workshop -Dappdynamics.agent.tierName=Api-Services -Dappdynamics.agent.nodeName=Api-Services_Node-01 -Dappdynamics.agent.accountName=se-lab -Dappdynamics.agent.accountAccessKey=hj6a4d7h2cuq -Xms64m -Xmx512m -XX:MaxPermSize=256m supercars.services.api.ApiService
splunk     47133   46757  2 15:34 pts/1    00:08:11 /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -javaagent:/opt/appdynamics/javaagent/javaagent.jar -Dappdynamics.controller.hostName=se-lab.saas.appdynamics.com -Dappdynamics.controller.port=443 -Dappdynamics.controller.ssl.enabled=true -Dappdynamics.agent.applicationName=Supercar-Trader-AppD-Workshop -Dappdynamics.agent.tierName=Inventory-Services -Dappdynamics.agent.nodeName=Inventory-Services_Node-01 -Dappdynamics.agent.accountName=se-lab -Dappdynamics.agent.accountAccessKey=hj6a4d7h2cuq -Xms64m -Xmx512m -XX:MaxPermSize=256m supercars.services.inventory.InventoryService
splunk     47151   46757  1 15:34 pts/1    00:04:58 /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -javaagent:/opt/appdynamics/javaagent/javaagent.jar -Dappdynamics.controller.hostName=se-lab.saas.appdynamics.com -Dappdynamics.controller.port=443 -Dappdynamics.controller.ssl.enabled=true -Dappdynamics.agent.applicationName=Supercar-Trader-AppD-Workshop -Dappdynamics.agent.tierName=Insurance-Services -Dappdynamics.agent.nodeName=Insurance-Services_Node-01 -Dappdynamics.agent.accountName=se-lab -Dappdynamics.agent.accountAccessKey=hj6a4d7h2cuq -Xms64m -Xmx68m -XX:MaxPermSize=256m supercars.services.insurance.InsuranceService
splunk     47153   46757  3 15:34 pts/1    00:08:17 /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -javaagent:/opt/appdynamics/javaagent/javaagent.jar -Dappdynamics.controller.hostName=se-lab.saas.appdynamics.com -Dappdynamics.controller.port=443 -Dappdynamics.controller.ssl.enabled=true -Dappdynamics.agent.applicationName=Supercar-Trader-AppD-Workshop -Dappdynamics.agent.tierName=Enquiry-Services -Dappdynamics.agent.nodeName=Enquiry-Services_Node-01 -Dappdynamics.agent.accountName=se-lab -Dappdynamics.agent.accountAccessKey=hj6a4d7h2cuq -Xms64m -Xmx512m -XX:MaxPermSize=256m supercars.services.enquiry.EnquiryService
splunk    144789   46722  0 20:09 pts/1    00:00:00 grep --color=auto appdynamics.agent.tierName

フローマップにすべてのコンポーネントが表示されると、Insurance-Services Tierによって呼び出される3つのHTTPバックエンドを表すHTTPクラウドアイコンが表示されるはずです。

以下の手順に従って、3つのHTTPバックエンドのグループ化を解除します。

3 HTTP backendsとラベル付けされたHTTPクラウドアイコンを右クリックします
ドロップダウンメニューから Ungroup Backends を選択します

HTTPバックエンドのグループ化が解除されると、以下の画像のように3つすべてのHTTPバックエンドが表示されます。

4. AppDynamics の基本概念

このセクションでは、Splunk AppDynamics APM機能の基本概念について学びます。このセクションを終了すると、以下の概念を理解できるようになります

Application Flow Maps
Business Transactions (BTs)
Snapshots
Call Graphs

Flow Maps

AppDynamicsアプリエージェントは、最も一般的なアプリケーションフレームワークとサービスを自動的に検出します。組み込みのアプリケーション検出および設定を使用して、エージェントはアプリケーションデータとメトリクスを収集し、Flow Mapsを構築します。

AppDynamicsはすべてのトランザクションを自動的にキャプチャしてスコアリングします。Flow Mapsは、選択した時間枠のコンテキストで、監視対象のアプリケーション環境のコンポーネントとアクティビティを動的に視覚化して表示します。

Flow Mapのさまざまな機能に慣れてください。

さまざまなレイアウトオプションを試してみてください（Flow Map上の各アイコンをクリックしてドラッグして位置を変更することもできます）。
スライダーとマウスのスクロールホイールを使用してズームレベルを調整してみてください。
Transaction Scorecardを確認してください。
Flow Mapを編集するオプションを探索してください。

Flow Mapsの詳細についてはこちらをご覧ください。

Business Transactions

AppDynamicsモデルでは、Business Transactionはリクエスト（通常はユーザーリクエスト）のデータ処理フローを表します。現実世界では、アプリケーション内の多くの異なるコンポーネントが相互作用して、以下のようなタイプのリクエストを処理するサービスを提供します

eコマースアプリケーションでは、ユーザーのログイン、商品の検索、カートへの商品追加
コンテンツポータルでは、スポーツ、ビジネス、エンターテインメントニュースなどのコンテンツのリクエスト
株式取引アプリケーションでは、株価の取得、株式の売買などの操作

AppDynamicsはBusiness Transactionsを中心にパフォーマンス監視を行うため、ユーザーの視点からアプリケーションコンポーネントのパフォーマンスに集中できます。コンポーネントがすぐに利用可能かどうか、またはパフォーマンスの問題が発生しているかどうかをすばやく特定できます。たとえば、ユーザーがログインできるか、チェックアウトできるか、データを表示できるかを確認できます。ユーザーの応答時間と、問題が発生した場合の原因を確認できます。

Business Transactionsの詳細についてはこちらとこちらをご覧ください。

Business Transactions の確認

以下の手順に従って、Business Transactionsが自動的に検出されていることを確認します。

左側のメニューで Business Transactions オプションをクリックします。
Business Transactionsのリストとそのパフォーマンスを確認します。

Snapshots

AppDynamicsは、計装された環境内のすべてのBusiness Transactionの実行を監視し、メトリクスはそれらすべての実行を反映します。ただし、トラブルシューティングの目的で、AppDynamicsは問題が発生しているトランザクションの特定のインスタンスのスナップショット（詳細な診断情報を含む）を取得します。

以下の手順に従って、トランザクションスナップショットが自動的に収集されていることを確認します。

左側のメニューで Application Dashboard オプションをクリックします。
Transaction Snapshots タブをクリックします。
Exe Time (ms) 列をクリックして、実行時間が最も長いスナップショットでソートします。
Business Transactionスナップショットをダブルクリックしてスナップショットビューアを表示します

トランザクションスナップショットは、単一のトランザクション呼び出しの処理フローをクロスティアビューで表示します。

Potential Issues パネルは、遅いメソッドと遅いリモートサービスコールを強調表示し、パフォーマンス問題の根本原因を調査するのに役立ちます。

Drill Downs と Call Graphs

Call graphsとdrill downsは、Tierでのトランザクション実行に関する重要な情報を提供します。これには、最も遅いメソッド、エラー、リモートサービスコールが含まれます。drill downには、部分的または完全なcall graphが含まれる場合があります。Call graphsは、特定のTierでのBusiness Transactionの処理をコードレベルで表示します。

Business TransactionスナップショットのFlow Mapで、Drill DownリンクがあるTierは、AppDynamicsがそのTierのcall graphを取得したことを示しています。

以下の手順に従って、トランザクションスナップショットのcall graphにドリルダウンします。

左側のPotential Issuesリストで遅いコールをクリックします。
Drill Down into Call Graph をクリックします。

call graphビューには、以下の詳細が表示されます。

メソッド実行シーケンスは、このノードでBusiness Transactionの処理に参加したクラスとメソッドの名前を、制御フローの進行順序で表示します。
各メソッドについて、処理に費やされた時間と割合、およびソースコード内の行番号を確認でき、トランザクションのパフォーマンスに影響を与えている可能性のあるコード内の場所を特定できます。
call graphは、データベースクエリやWebサービスコールなど、他のコンポーネントへの発信コールを行うメソッドのexit callリンクを表示します。

Transaction Snapshotsの詳細についてはこちらをご覧ください。

Call Graphsの詳細についてはこちらをご覧ください。

5. Controller 設定の構成

この演習では、以下のタスクを完了します

Business Transaction設定を調整する
Call Graph設定を調整する
Business Transactionの変更を確認する

Business Transaction 設定の調整

前の演習で、Business Transactionsが自動検出されていることを確認しました。Business Transactionの自動検出ルールを最適な状態に調整したい場合があります。これは、古いApache Strutsフレームワーク上に構築されたサンプルアプリケーションの場合に当てはまります。

以下の画像で強調表示されているBusiness Transactionsは、各ペアにStruts Action（.execute）とServletタイプ（.jsp）があることを示しています。これら2種類のトランザクションが1つに統合されるように、トランザクション検出ルールの設定を調整します。

AppDynamics UIに時間枠セレクターが表示されている場合、表示されるビューは選択した時間枠のコンテキストを表します。事前定義された時間枠の1つを選択するか、表示したい特定の日付と時間範囲でカスタム時間枠を作成できます。

過去1時間の時間枠を選択します。
マウスを青いアイコンの上に移動して、トランザクションのEntry Point Typeを確認します。

以下の手順に従ってトランザクション検出を最適化します

左下のメニューで Configuration オプションをクリックします。
Instrumentation リンクをクリックします。
Instrumentationメニューから Transaction Detection を選択します。
Java Auto Discovery Rule を選択します。
Edit をクリックします。
Rule Editorで Rule Configuration タブを選択します。
Struts Action セクションのすべてのボックスのチェックを外します。
Web Service セクションのすべてのボックスのチェックを外します。
下にスクロールしてServlet設定を見つけます。
Enable Servlet Filter Detection ボックスにチェックを入れます（Servlet設定では3つのボックスすべてにチェックが入っている必要があります）。
Save をクリックして変更を保存します。

Transaction Detection Rulesの詳細についてはこちらをご覧ください。

Call Graph 設定の調整

以下に示すCall Graph Settingsウィンドウで、トランザクションスナップショット内のcall graphsでキャプチャされるデータを制御できます。このステップでは、各SQLクエリのパラメータが完全なクエリと共にキャプチャされるようにSQL Capture設定を変更します。以下の手順に従ってSQL Capture設定を変更できます。

Instrumentationウィンドウから Call Graph Settings タブを選択します。これは、前の演習で移動した Instrumentation 設定内にあります。
設定内で Java タブが選択されていることを確認します。
SQL Capture Settings が表示されるまで下にスクロールします。
Capture Raw SQL オプションをクリックします。
Save をクリックします。

Call Graph設定の詳細についてはこちらをご覧ください。

Business Transaction の変更の確認

新しいBusiness Transactionsが以前のトランザクションを置き換えるまでに最大30分かかる場合があります。新しいトランザクションが検出されると、Business Transactionsのリストは以下の例のようになります。

左側のメニューで Business Transactions をクリックします。
時間範囲ピッカーを調整して last 15 minutes を確認します

6. 遅いトランザクションのトラブルシューティング

この演習では、以下のタスクを完了します

アプリケーションダッシュボードとフローマップを監視する
遅いトランザクションスナップショットをトラブルシューティングする

アプリケーションダッシュボードとフローマップの監視

前の演習では、Application Flow Mapの基本的な機能をいくつか見てきました。Application DashboardとFlow Mapを使用してアプリケーション内の問題を即座に特定する方法をより深く見ていきましょう。

Health Rule Violations、Node Healthの問題、およびBusiness Transactionsの健全性は、選択した時間枠についてこのエリアに常に表示されます。ここで利用可能なリンクをクリックして詳細にドリルダウンできます。
Transaction Scorecardは、正常、遅い、非常に遅い、停止、エラーのあるトランザクションの数と割合を表示します。スコアカードには、例外タイプの高レベルのカテゴリも表示されます。ここで利用可能なリンクをクリックして詳細にドリルダウンできます。
異なるアプリケーションコンポーネントを接続する青い線のいずれかを左クリック（シングルクリック）すると、2つのコンポーネント間のインタラクションの概要が表示されます。
Tierの色付きリング内を左クリック（シングルクリック）すると、Flow Mapに留まりながらそのTierに関する詳細情報が表示されます。
ダッシュボードの下部にある3つのチャート（Load、Response Time、Errors）のいずれかの時系列にマウスを合わせると、記録されたメトリクスの詳細が表示されます。

次に、Dynamic Baselinesとダッシュボードの下部にあるチャートのオプションを見てみましょう。

チャートのメトリクスを、各メトリクスに対して自動的に計算されたDynamic Baselineと比較します。
Dynamic Baselineは、以下の画像に示すように、負荷と応答時間のチャートに青い点線で表示されます。
ダッシュボードの下部にある3つのチャートのいずれかでスパイクを強調表示するには、マウスボタンを押したまま左から右にドラッグします。
マウスボタンを離し、ポップアップメニューの3つのオプションのいずれかを選択します。

AppDynamics独自のDynamic Baseliningの精度は時間の経過とともに向上し、アプリケーション、そのコンポーネント、およびビジネストランザクションの状態を正確に把握できるようになります。これにより、事態が深刻な状態になる前にプロアクティブにアラートを受け取り、エンドユーザーに影響が及ぶ前に対処できます。

AppDynamics Dynamic Baselinesの詳細についてはこちらをご覧ください。

遅いトランザクションスナップショットのトラブルシューティング

以下の手順に従って、Business Transactionsを確認し、非常に遅いトランザクションが最も多いものを見つけましょう。

左側のメニューで Business Transactions オプションをクリックします。
View Options ボタンをクリックします。
以下の画像と一致するようにオプションのボックスのチェックを入れたり外したりします
/Supercar-Trader/car.doという名前のBusiness Transactionを見つけ、そのBusiness TransactionのVery Slow Transactionsの数をクリックして、非常に遅いトランザクションスナップショットにドリルダウンします。

Tip

/Supercar-Trader/car.do BTにVery Slow Transactionsがない場合は、それがあるBusiness Transactionを見つけて、その列の数字をクリックしてください。今後のスクリーンショットは若干異なる場合がありますが、概念は同じです。

![Very Slow Transaction](images/very-slow-transaction.png)

非常に遅いトランザクションスナップショットのリストが表示されるはずです。以下に示すように、最も応答時間が長いスナップショットをダブルクリックします。

トランザクションスナップショットビューアが開くと、この特定のトランザクションの一部であったすべてのコンポーネントのフローマップビューが表示されます。このスナップショットは、トランザクションが以下のコンポーネントを順番に通過したことを示しています。
- Web-Portal Tier
- Api-Services Tier
- Enquiry-Services Tier
- MySQL Database
左側のPotential Issuesパネルは、遅いメソッドと遅いリモートサービスを強調表示します。Potential Issuesパネルを使用してcall graphに直接ドリルダウンすることもできますが、この例ではスナップショット内のFlow Mapを使用して完全なトランザクションを追跡します。
スナップショットのFlow Mapに表示されているWeb-Portal Tierの Drill Down をクリックします。

開いたタブにはWeb-Portal Tierのcall graphが表示されます。ほとんどの時間がアウトバウンドHTTPコールによるものであることがわかります。
ブロックをクリックして、問題が発生しているセグメントにドリルダウンします。HTTPリンクをクリックしてダウンストリームコールの詳細を表示します。

ダウンストリームコールの詳細パネルは、Web-Portal TierがApi-Services TierへのアウトバウンドHTTPコールを行ったことを示しています。HTTPコールを追跡してApi-Services Tierに進みます。
Drill Down into Downstream Call をクリックします。

次に開くタブにはApi-Services Tierのcall graphが表示されます。時間の100%がアウトバウンドHTTPコールによるものであることがわかります。
HTTPリンクをクリックしてダウンストリームコールの詳細パネルを開きます。

ダウンストリームコールの詳細パネルは、Api-Services TierがEnquiry-Services TierへのアウトバウンドHTTPコールを行ったことを示しています。HTTPコールを追跡してEnquiry-Services Tierに進みます。
Drill Down into Downstream Call をクリックします。

次に開くタブにはEnquiry-Services Tierのcall graphが表示されます。トランザクションに問題を引き起こしたデータベースへのJDBCコールがあったことがわかります。
最も時間がかかったJDBCリンクをクリックして、JDBCコールの詳細パネルを開きます。

JDBC exitコールの詳細パネルには、最も時間がかかった特定のクエリが表示されます。SQLパラメータ値とともに完全なSQLステートメントを確認できます。

まとめ

このラボでは、まずBusiness Transactionsを使用して、トラブルシューティングが必要な非常に遅いトランザクションを特定しました。次に、call graphを調べて、遅延を引き起こしているコードの特定の部分を特定しました。その後、ダウンストリームサービスとデータベースにドリルダウンして、遅延の根本原因をさらに分析しました。最後に、パフォーマンスの問題の原因となっている非効率なSQLクエリを正確に特定することに成功しました。この包括的なアプローチは、AppDynamicsがトランザクションのボトルネックを効果的に分離して解決するのにどのように役立つかを示しています。

7. エラーと例外のトラブルシューティング

この演習では、アプリケーション内のエラーを効果的に検出および診断して根本原因を特定する方法を学びます。さらに、パフォーマンスが低下しているか、エラーが発生している特定のノードを特定し、これらのパフォーマンスの問題を解決するためのトラブルシューティング手法を適用する方法を探ります。このハンズオン体験により、アプリケーションの健全性を維持し、最適なパフォーマンスを確保する能力が向上します。

アプリケーション内の特定のエラーの検出

AppDynamicsを使用すると、アプリケーション内のエラーと例外を簡単に見つけることができます。Errors ダッシュボードを使用して、エラーのあるトランザクションスナップショットを確認し、最も頻繁に発生している例外を見つけることができます。エラーを迅速に特定することで、アプリケーションの安定性とユーザーエクスペリエンスを向上させる修正の優先順位付けに役立ちます。例外のタイプと頻度を理解することで、最も影響の大きい問題に集中できます。

左側のメニューで Troubleshoot オプションをクリックします。
左側のメニューで Errors オプションをクリックします。これにより、エラーのあるBusiness Transactionsをすばやく特定できるErrorsダッシュボードに移動します。
いくつかのエラートランザクションスナップショットを調べます。スナップショットを確認すると、エラーが発生したときの正確なコンテキストとフローを確認できます。
Exceptions タブをクリックして、タイプ別にグループ化された例外を表示します。例外タイプ別にグループ化することで、繰り返し発生する問題とパターンを特定できます。

Exceptions タブには、アプリケーション内で最も多く発生している例外のタイプが表示されるため、最も影響の大きいものの修正を優先できます。
Exceptions per minute と Exception count（6）を確認して、エラーの頻度を把握します。高頻度の例外は、即座に対応が必要な重大な問題を示していることが多いです。
例外が発生している Tier を確認して、アプリケーションアーキテクチャ内で問題を特定します。影響を受けているTierを知ることで、根本原因を絞り込むことができます。
MySQLIntegrityConstraintViolationExceptionタイプをダブルクリックして、より深くドリルダウンします。
この例外タイプが発生したスナップショットを示す概要ダッシュボードを確認します。
Stack Traces for this Exception というラベルのタブには、この例外タイプによって生成された一意のスタックトレースの集約リストが表示されます。スタックトレースは、エラーを引き起こしている正確なコードパスを提供し、デバッグに不可欠です。
スナップショットをダブルクリックして開き、コンテキスト内でエラーを確認します。これにより、トランザクションフローとエラーが発生した場所が表示されます。

例外画面からエラースナップショットを開くと、スナップショットはエラーが発生したスナップショット内の特定のセグメントで開きます。
赤いテキストで表示されているexitコールに注目してください。これはエラーまたは例外を示しています。
exitコールにドリルインして、詳細なエラー情報を表示します。
Error Details をクリックして、完全なスタックトレースを表示します。完全なスタックトレースは、開発者がバグを追跡して修正するために不可欠です。

Tip

エラー処理と例外について詳しく知りたい場合は、次のリンクの公式AppDynamicsドキュメントを参照してください：こちら

ノードの問題のトラブルシューティング

ノードの健全性は、アプリケーションのパフォーマンスと可用性に直接影響します。ノードの問題を早期に検出することで、停止を防ぎ、スムーズな運用を確保できます。AppDynamicsはUI全体で視覚的なインジケーターを提供し、問題をすばやく特定しやすくしています。

Application Dashboardの3つのエリアでノードの問題のインジケーターを確認できます。

Application Dashboard でノードの問題の視覚的なインジケーターを確認します。色の変化とアイコンは、問題に対する即座のアラートを提供します。
Events パネルには、Node Healthに関連するものを含むHealth Rule Violationsが表示されます。
Node Health パネルには、ノードで発生している重大または警告の問題の数が表示されます。Node Health パネルのNode Healthリンクをクリックして、Tiers & Nodes dashboard にドリルダウンします。
または、左側のメニューで Tiers & Nodes をクリックして Tiers & Nodes dashboard にアクセスすることもできます。
Grid Viewに切り替えて、整理されたノードのリストを表示します。Grid viewを使用すると、警告のあるノードをスキャンして見つけやすくなります。
Insurance-Services_Node-01ノードの警告アイコンをクリックします。
Health Rule Violationsのサマリーを確認し、違反の説明をクリックします。
Details ボタンをクリックして詳細を表示します。

Health Rule Violation 詳細ビューアには以下が表示されます
違反の現在の状態。
違反が発生していた時間のタイムライン。
違反の詳細と、それをトリガーした条件。
View Dashboard During Health Rule Violation をクリックして、問題発生時のノードメトリクスを確認します。違反とパフォーマンスメトリクスを関連付けることで、診断に役立ちます。

View Dashboard During Health Rule Violation ボタンをクリックすると、デフォルトでNodeダッシュボードの Server タブが開きます。
AppDynamics Server Visibility Monitoringエージェントをまだインストールしていない場合、ノードのホストのリソースメトリクスは表示されません。これらのメトリクスは次のラボで確認できます。AppDynamics Javaエージェントは、JMX経由でJVMからメモリメトリクスを収集します。
以下の手順でJVMヒープデータを調査します。
Memory タブをクリックします。
現在のヒープ使用率を確認します。
発生しているMajor Garbage Collectionsに注目します。

注：Memory画面の表示に問題がある場合は、別のブラウザを試してください（FirefoxはWindows、Linux、Macで正しくレンダリングされるはずです）。

![Memory Dashboard](images/memory-dashboard.png)

外側のスクロールバーを使用して、画面の下部までスクロールします。
PS Old Gen のメモリ使用量が高い場合は、メモリリークまたは非効率なガベージコレクションの潜在的な兆候として注意してください。メモリ圧力を早期に特定することで、停止を防ぐことができます。

NodeとJVMの監視の詳細についてはこちらとこちらをご覧ください。

まとめ

このラボでは、AppDynamicsを効果的に使用してアプリケーションエラーとノードの健全性の問題を特定およびトラブルシューティングする方法を学びました。まず、Errorsダッシュボードを使用して特定のエラーと例外を見つけ、その頻度、タイプ、およびアプリケーションへの影響を理解しました。エラースナップショットとスタックトレースにドリルダウンして、障害の根本原因を特定しました。

次に、Application Dashboardの視覚的なインジケーターを解釈し、Health Rule Violationsを調査することで、ノードの健全性監視を探りました。ガベージコレクションとヒープ使用量に関連する潜在的なパフォーマンスボトルネックを検出するために、JVMメモリメトリクスを分析する方法を学びました。

これらのスキルを組み合わせることで、アプリケーションのパフォーマンスと信頼性を維持するためのプロアクティブな監視と迅速なトラブルシューティングが可能になります。