ラボの前提条件

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

• WebブラウザからAppDynamics Controllerにアクセスする
• アプリケーションへのトランザクション負荷を確認する
• 必要に応じてアプリケーションとトランザクション負荷を再起動する

Controller へのログイン

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

アプリケーションへのトランザクション負荷の確認

アプリケーションフローマップを確認します

1. last 1 hour の時間枠を選択します。
2. フローマップに5つの異なるティアが表示されていることを確認します。
3. 過去1時間にわたって一貫した負荷があったことを確認します。

ビジネストランザクションのリストを確認します

1. 左メニューの Business Transactions オプションをクリックします。
2. 以下に示す11個のビジネストランザクションが表示されていることを確認します。
3. 過去1時間にいくらかの呼び出し回数があることを確認します。

注意: Calls 列が表示されていない場合は、View Options ツールバーボタンをクリックしてその列を表示できます。

ノードのエージェントステータスを確認します

1. 左メニューの Tiers & Nodes オプションをクリックします。
2. Grid View をクリックします。
3. 過去1時間の各ノードの App Agent Status が90%を超えていることを確認します。

必要に応じてアプリケーションと負荷生成を再起動

前のステップで行った確認のいずれかが検証できなかった場合は、Application VM にSSH接続し、以下の手順に従ってアプリケーションとトランザクション負荷を再起動します。

以下のコマンドを使用して、実行中のApache Tomcatインスタンスを停止します。

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

以下のコマンドを使用して、まだ実行中のアプリケーションJVMがないか確認します。

ps -ef | grep Supercar-Trader

まだ実行中のアプリケーションJVMがある場合は、以下のコマンドを使用して残りのJVMを停止します。

sudo pkill -f Supercar-Trader

以下のコマンドを使用して、アプリケーションの負荷生成を停止します。すべてのプロセスが停止するまで待ちます。

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

Tomcatサーバーを再起動します

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

2分間待ってから、以下のコマンドを使用してApache Tomcatがポート8080で実行されていることを確認します。

sudo netstat -tulpn | grep LISTEN

以下の画像のような出力が表示され、ポート8080がApache Tomcatによって使用されていることが確認できます。

以下のコマンドを使用して、アプリケーションの負荷生成を開始します。

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

以下の画像のような出力が表示されます。

Database Agent のダウンロード

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

Controller へのログイン

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

Database Agent のダウンロード

1. 画面左上のHomeタブを選択します。
2. Getting Started タブを選択します。
3. Getting Started Wizard をクリックします。

1. Databases をクリックします。

Database Agent のダウンロード

1. Select Database Typeドロップダウンメニューから MySQL を選択します。
2. Controller接続のデフォルト設定を受け入れます。
3. Click Here to Download をクリックします。

Database Visibility Agentファイルをローカルファイルシステムに保存します。

ブラウザから、以下の画像のようにエージェントファイルをローカルファイルシステムに保存するよう求められます（OSによって表示が異なる場合があります）。

Database Agent のインストール

AppDynamics Database Agentは、データベースインスタンスとデータベースサーバーのパフォーマンスメトリクスを収集するスタンドアロンのJavaプログラムです。Database Agentは、Java 1.8以上が動作する任意のマシンにデプロイできます。そのマシンは、AppDynamics Controllerと監視対象のデータベースインスタンスへのネットワークアクセスが必要です。

16 GBのメモリを搭載した標準的なマシンで実行されるDatabase Agentは、約25個のデータベースを監視できます。より大きなマシンでは、Database Agentは最大200個のデータベースを監視できます。

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

• Database VisibilityエージェントファイルをApplication VMにアップロードする
• ファイルシステムの特定のディレクトリにファイルを解凍する
• Database Visibilityエージェントを起動する

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

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

ローカルマシンでターミナルウィンドウを開き、Database Agentファイルがダウンロードされたディレクトリに移動します。以下のコマンドを使用して、ファイルをEC2インスタンスにアップロードします。これには時間がかかる場合があります。Windows OSを使用している場合は、WinSCPなどのプログラムを使用する必要があるかもしれません。

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

cd ~/Downloads
scp -P 2222 db-agent-*.zip splunk@i-0267b13f78f891b64.splunk.show:/home/splunk

splunk@i-0267b13f78f891b64.splunk.show's password:
db-agent-25.7.0.5137.zip                                                                                                                               100%   70MB   5.6MB/s   00:12

Database Agent のインストール

Database Agentのzipファイルを解凍するディレクトリ構造を作成します。

cd /opt/appdynamics
mkdir dbagent

以下のコマンドを使用して、Database Agentのzipファイルをディレクトリにコピーし、ファイルを解凍します。Database Agentファイルの名前は、以下の例とは若干異なる場合があります。

cp ~/db-agent-*.zip /opt/appdynamics/dbagent/
cd /opt/appdynamics/dbagent
unzip db-agent-*.zip

Database Visibility エージェントの起動

以下のコマンドを使用して、Database Agentを起動し、起動したことを確認します。

DB エージェント名にイニシャルを追加してください。これは次のセクションで使用します。例：DBMon-Lab-Agent-IO

cd /opt/appdynamics/dbagent
nohup java -Dappdynamics.agent.maxMetrics=300000 -Ddbagent.name=DBMon-Lab-Agent-YOURINITIALS -jar db-agent.jar &
ps -ef | grep db-agent

以下の画像のような出力が表示されます。

Database Collector の構成

Database Collector の構成

Database Agent Collectorは、Database Agent内で実行され、データベースインスタンスとデータベースサーバーのパフォーマンスメトリクスを収集するプロセスです。1つのコレクターは1つのデータベースインスタンスのメトリクスを収集します。1つのDatabase Agentで複数のコレクターを実行できます。Database AgentがControllerに接続されると、Controllerで1つ以上のコレクターを構成できます。

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

• WebブラウザからAppDynamics Controllerにアクセスする
• ControllerでDatabase Collectorを構成する
• Database Collectorがデータを収集していることを確認する

Controller へのログイン

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

Controller での Database Collector の構成

以下の手順に従って、クエリリテラルの設定を変更し、コレクター構成に移動します。

1. 左メニューの Databases タブをクリックします。
2. 左下の Configuration タブをクリックします。
3. Remove literals from the queries のチェックボックスのチェックを外します。
4. Collectors オプションをクリックします。

以下の手順に従って、新しいDatabase Collectorを構成します。

1. Add ボタンをクリックします。
2. データベースタイプとして MySQL を選択します。
3. Database Agentとして DBMon-Lab-Agent を選択し、以下のパラメータを入力します。
4. Collector Name: Supercar-MySQL-YOURINITIALS
5. Hostname or IP Address: localhost
6. Listener Port: 3306

1. Username: root
2. Password: Welcome1!

1. Advanced Options の下にある Monitor Operating System チェックボックスを選択します。
2. オペレーティングシステムとして Linux を選択し、以下のパラメータを入力します。
3. SSH Port: 22
4. Username: splunk
5. Password: EC2 インスタンスに SSH 接続するためにインストラクターから提供されたパスワード
6. OK をクリックしてコレクターを保存します。

Database Collector がデータを収集していることの確認

コレクターが実行されてデータを送信するまで10分間待ってから、以下の手順に従ってDatabase Collectorがデータベースに接続し、データベースメトリクスを収集していることを確認します。

1. 左メニューの Databases タブをクリックします。
2. 前のセクションで作成したCollectorを検索します：Supercar-MySQL-YOURINITIALS
3. ステータスが緑色で、エラーが表示されていないことを確認します。
4. Supercar-MySQLリンクをクリックしてデータベースの詳細を表示します。

注意：コレクターを構成してから Top 10 SQL Wait States と Queries タブのクエリが表示されるまで、最大18分かかる場合があります。

Database Collectorの構成の詳細については、こちらを参照してください。

監視とトラブルシューティング - パート1

監視とトラブルシューティング - パート1

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

• データベースとサーバーのパフォーマンス全体ダッシュボードの確認
• メインデータベースダッシュボードの確認
• データベースアクティビティウィンドウのレポートの確認

データベースとサーバーのパフォーマンス全体ダッシュボードの確認

データベースとサーバーのパフォーマンス全体ダッシュボードでは、各データベースの健全性を一目で確認できます。

1. Filters：健全性、負荷、データベースの時間、またはタイプでフィルタリングするオプションを探索できます。
2. Actions：このウィンドウのデータを .csv形式のファイルでエクスポートします。
3. View Options：スパークチャートのオン/オフを切り替えます。
4. View：カードビューとリストビューを切り替えます。
5. Sort：ソートオプションを表示します。
6. Supercar-MySQL：メインデータベースダッシュボードにドリルダウンします。

メインデータベースダッシュボードの確認

メインデータベースダッシュボードには、以下を含むデータベースの主要なインサイトが表示されます

• データベースを実行しているサーバーの健全性
• 指定された時間期間中の合計呼び出し回数
• 任意の時点での呼び出し回数
• 指定された時間期間中にSQL文の実行に費やされた合計時間
• 上位10件のクエリ待機状態
• 平均接続数
• データベースタイプまたはベンダー
• ダッシュボードの機能を探索します

1. ヘルスステータスの円をクリックして、サーバーの健全性の詳細を確認します

• Green（緑）：サーバーは正常
• Yellow（黄）：警告レベルの違反があるサーバー
• Red（赤）：重大レベルの違反があるサーバー

1. データベースタイプまたはベンダーは常にここに表示されます。
2. 指定された時間期間中にSQL文の実行に費やされた合計時間を確認します。
3. 指定された時間期間中の合計実行回数を確認します。
4. チャート上の時系列にマウスを合わせて、記録されたメトリクスの詳細を確認します。

データポイントの上部にあるオレンジ色の円をクリックすると、選択した時間の前後15分のクエリ実行時間と待機状態を表示する時間比較レポートが表示されます。

1. チャートに表示されるスパイクを強調表示するには、マウスの左ボタンを押したまま左から右にドラッグします。
2. 構成ボタンをクリックして、上位10件から不要な待機状態を除外します。
3. 各待機状態のラベルにマウスを合わせて、より詳細な説明を確認します。
4. 選択した時間期間中にクエリを実行しているアクティブな接続の平均数を確認します。

選択した時間期間のDBサーバーのOSメトリクスを表示するには

1. 右側のスクロールバーを使用してダッシュボードの下部にスクロールします
2. CPU
3. Memory
4. Disk IO
5. Network IO

データベースアクティビティウィンドウのレポートの確認

Database Visibilityのデータベースアクティビティウィンドウには、最大9種類のレポートがあります。利用可能なレポートは、監視対象のデータベースプラットフォームによって異なります。この演習では、最も一般的な3つのレポートを確認します。

• Wait State Report
• Top Activity Report
• Query Wait State Report

Wait State Report

このレポートは、データベース内のWait Events（待機状態）の時系列データを表示します。各待機状態は色分けされており、Y軸は秒単位の時間を表示します。このレポートは、テーブル形式でもデータを表示し、各SQL文の各待機状態に費やされた時間を強調表示します。

最も時間を消費している待機状態は、パフォーマンスのボトルネックを示している可能性があります。たとえば、db file sequential readsは、インデックスのセグメントヘッダー競合またはディスク競合が原因である可能性があります。

Top Activity Report

このレポートは、データベースSQL文の上位の時間を時系列ビューで表示します。このレポートは、テーブル形式でもデータを表示し、上位10件のSQL文それぞれがデータベースで費やした時間を強調表示します。

このレポートを使用して、どのSQL文が最もデータベース時間を使用しているかを確認します。これにより、特定のSQL文がシステム全体のパフォーマンスに与える影響を判断でき、データベースパフォーマンスに最も影響を与えている文にチューニングの努力を集中させることができます。

Query Wait State Report

このレポートは、上位（10、50、100、200）クエリの待機時間を表示します。このレポートは、テーブル形式でもデータを表示し、各クエリが異なる待機状態で費やしている時間を強調表示します。列を使用して、異なる待機状態でクエリをソートします。

データベースアクティビティウィンドウのレポートの詳細については、こちらを参照してください。

監視とトラブルシューティング - パート2

クエリダッシュボードの確認

Queriesウィンドウには、データベースで最も時間を消費しているSQL文とストアドプロシージャが表示されます。クエリの重みをSQL待機時間などの他のメトリクスと比較して、チューニングが必要なSQLを特定できます。

1. Queries タブ：クエリウィンドウを表示します。
2. Top Queries ドロップダウン：上位5、10、100、または200件のクエリを表示します。
3. Filter by Wait States：クエリリストをフィルタリングする待機状態を選択できます。
4. Group Similar：同じ構文を持つクエリをグループ化します。
5. Weight (%) が最も大きいクエリをクリックします。
6. View Query Details：クエリの詳細にドリルダウンします。

コストの高いクエリの詳細確認

Database Queriesウィンドウでデータベースで最も時間を費やしている文を特定したら、それらのSQL文をチューニングするのに役立つ詳細をさらに掘り下げることができます。データベースインスタンスのQuery Detailsウィンドウには、Database Queriesウィンドウで選択したクエリの詳細が表示されます。

1. Resource consumption over time：クエリがリソースを使用してデータベースで費やした時間、実行回数、および消費したCPU時間を表示します。
2. Wait states：選択したSQL文をデータベースが処理するのにかかる時間に寄与するアクティビティです。最も時間を消費している待機状態は、パフォーマンスのボトルネックを示している可能性があります。
3. Components Executing Similar Queries：このクエリに類似したクエリを実行しているノードを表示します。
4. Business Transactions Executing Similar Queries：このクエリに類似したクエリを実行しているJavaビジネストランザクションを表示します。

1. 右側の外側のスクロールバーを使用して下にスクロールします。
2. Clients：選択したSQL文を実行したマシンと、各マシンが文の実行に要した合計時間の割合を表示します。
3. Sessions：各データベースインスタンスの使用状況のセッションです。
4. Query Active in Database：このSQLによってアクセスされたスキーマを表示します。
5. Users：このクエリを実行したユーザーを表示します。
6. Query Hashcode：データベースサーバーがキャッシュ内でこのSQL文をより迅速に見つけるための一意のIDを表示します。
7. Query：選択したSQL文の完全な構文を表示します。Queryカードの右上隅にある鉛筆アイコンをクリックして、識別しやすいようにクエリ名を編集できます。
8. Execution Plan：クエリ実行プランウィンドウを表示します。

コストの高いクエリのトラブルシューティング

Database Query Execution Planウィンドウは、クエリに最も効率的な実行プランを決定するのに役立ちます。問題のある可能性のあるクエリを発見したら、EXPLAIN PLAN文を実行して、データベースが作成した実行プランを確認できます。

クエリの実行プランは、クエリがインデックスの使用を最適化し、効率的に実行されているかどうかを示します。この情報は、実行が遅いクエリのトラブルシューティングに役立ちます。

1. Execution Plan タブをクリックします。
2. Type 列の結合タイプが各テーブルでALLであることに注目してください。
3. 結合タイプの1つにマウスを合わせて、結合タイプの説明を確認します。
4. Extras 列のエントリを調べます。
5. 各エントリにマウスを合わせて、エントリの説明を確認します。

次に、Object Browserを使用してテーブルのインデックスを調査しましょう。

1. Object Browser オプションをクリックして、テーブルのスキーマの詳細を表示します。
2. Database オプションをクリックします。
3. supercars スキーマをクリックして、テーブルのリストを展開します。
4. CARS テーブルをクリックして、テーブルの詳細を表示します。
5. CAR_ID列が主キーとして定義されていることがわかります。

1. 外側のスクロールバーを使用してページを下にスクロールします。
2. テーブルに定義された主キーインデックスに注目してください。

1. MANUFACTURER テーブルをクリックして、その詳細を表示します。
2. MANUFACTURER_ID 列が主キーとして定義されていないことに注目してください。
3. ページを下にスクロールして、テーブルにインデックスが定義されていないことを確認します。

MANUFACTURER_ID列には、テーブルに対するクエリのパフォーマンスを向上させるためにインデックスを作成する必要があります。異なるクエリを分析した場合、根本的な問題は異なる可能性がありますが、このラボで示される最も一般的な問題は、クエリがMANUFACTURERテーブルとの結合を実行しているか、そのテーブルを直接クエリしていることが原因です。