Splunk4Ninjas AppDynamics

2 minutes

はじめに

Splunk AppDynamicsは、ビジネスクリティカルなアプリケーション向けのフルスタックパフォーマンス監視ソリューションであり、以下の機能を提供します

従来型、ハイブリッド、クラウドネイティブなど、環境を問わない一貫したエンドツーエンドのアプリケーション監視
クラウド移行の加速と、デプロイ先を問わないエンタープライズグレードのエンドツーエンドインサイト
パフォーマンス問題がビジネス上の問題になる前に迅速に解決できる統合監視（3クリックで根本原因を特定）

従来型、クラウド、またはハイブリッドデプロイメントにおいて、AppDynamicsプラットフォームの既存の人員、プロセス、トレーニングを活用することで、総所有コストを最適化できます。

ワークショップ概要

このワークショップでは、Splunk AppDynamicsの基本について説明します。Splunk AppDynamicsを使用して、アプリケーションサービス、Webアプリケーション、データベースなどの健全性を監視する方法を紹介します。このワークショップを完了すると、以下のことができるようになります

AppDynamics Java APM Agentのダウンロードとインストール
Controllerでの収集設定の構成
アプリケーションのパフォーマンス健全性の監視とトラブルシューティング
AppDynamicsがキャプチャしたデータに基づくAppDynamics監視サービスでのアラート監視
サーバーの健全性監視と問題のトラブルシューティング
BRUMを使用したブラウザベースアプリケーションの健全性監視
データベースパフォーマンスの監視とトラブルシューティング
Splunk AppDynamics Business IQによるユーザーに関するより深いインサイトの取得

今後追加予定の内容

ヘルスルールに関するセクションの追加（既存のヘルスルールの確認方法、新規ヘルスルールの作成方法）
Application Security

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メモリメトリクスを分析する方法を学びました。

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

Server Visibility Monitoring

2 minutes

前提条件

このラボはApplication Performance Monitoringラボの続きです。アプリケーションが実行中であり、過去1時間にわたって負荷がかかっていることを確認してください。必要に応じて、Generate Application Loadセクションに戻ってロードジェネレーターを再起動してください。

目標

このラボでは、AppDynamics Server Visibility MonitoringとService Availability Monitoringについて学びます。

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

AppDynamics Server Visibility Agentをダウンロードする
AppDynamics Server Visibility Agentをインストールする
サーバーの健全性を監視する
エージェントの拡張ハードウェアメトリクスを理解する
アプリケーションパフォーマンスに影響を与えている基盤インフラストラクチャの問題を迅速に確認する

ワークショップ環境

ラボ環境には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に対して動的なトラフィック（ビジネストランザクション）を生成することです。

Machine Agent のデプロイ

5 minutes

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

Machine Agentをインストールするスクリプトを実行する
Machine Agentを設定する
Machine Agentを起動する

注意

スクリプトを使用してMachine AgentをEC2インスタンスにダウンロードします。通常は https://accounts.appdynamics.com/ にログインしてMachine Agentをダウンロードする必要がありますが、アクセス制限の可能性があるため、ポータルから直接ダウンロードするスクリプトを使用します。AppDynamicsポータルにアクセスでき、Machine Agentをダウンロードしたい場合は、以下のステップに従ってダウンロードし、APMラボのInstall Agentセクションで使用したステップを参照してVMにSCPしてください。

AppDynamics Portal にログインします
左側のメニューで Downloads をクリックします
Type で Machine Agent を選択します
Operating System で Linux を選択します
Machine Agent Bundle - 64-bit linux (zip) を見つけて Download ボタンをクリックします
Install Agentセクションのステップに従って、ダウンロードしたファイルをEC2インスタンスにSCPします
zipファイルを /opt/appdynamics/machineagentディレクトリに解凍し、このラボの設定セクションに進みます

インストールスクリプトの実行

以下のコマンドを使用して、スクリプトが配置されているディレクトリに移動します。スクリプトはMachine Agentをダウンロードして解凍します。

cd /opt/appdynamics/lab-artifacts/machineagent/

以下のコマンドを使用してインストールスクリプトを実行します。

chmod +x install_machineagent.sh
./install_machineagent.sh

以下の画像のような出力が表示されるはずです。

Server Agent の設定

Java Agentの “controller-info.xml” から以下の設定プロパティ値を取得し、次のステップで使用できるようにしておきます。

cat /opt/appdynamics/javaagent/conf/controller-info.xml

controller-host
controller-port
controller-ssl-enabled
account-name
account-access-key

Machine Agentの “controller-info.xml” ファイルを編集し、Java Agent設定ファイルから取得した以下のプロパティの値を挿入します。

controller-host
controller-port
controller-ssl-enabled
account-name
account-access-key

“sim-enabled” プロパティをtrueに設定してファイルを保存する必要があります。ファイルは以下の画像のようになります。

cd /opt/appdynamics/machineagent/conf
nano controller-info.xml

Server Visibility Agent の起動

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

cd /opt/appdynamics/machineagent/bin
nohup ./machine-agent &
ps -ef | grep machine

以下の画像のような出力が表示されるはずです。

サーバーの健全性を監視する

2 minutes

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

Server Mainダッシュボードを確認する
Server Processesダッシュボードを確認する
Server Volumesダッシュボードを確認する
Server Networkダッシュボードを確認する
サーバーとアプリケーションのコンテキスト間を移動する

Server Main Dashboard の確認

Machine Agentがインストールされたので、Server Visibilityモジュールで利用可能な機能のいくつかを見てみましょう。Application Dashboard から Servers タブをクリックし、以下のステップに従ってサーバーメインダッシュボードにドリルダウンします。

左側のメニューで Servers タブをクリックします。
サーバーの左側にある checkbox をチェックします。
View Details をクリックします。

これでサーバーダッシュボードを探索できます。このダッシュボードでは、以下のタスクを実行できます

選択した監視対象サーバーの主要なパフォーマンスメトリクスのチャートを表示します。これには以下が含まれます

サーバーの可用性
CPU、メモリ、ネットワーク使用率
サーバープロパティ
ディスク、パーティション、ボリュームのメトリクス
CPUリソースとメモリを消費している上位10プロセス

Server Mainダッシュボードについて詳しくはこちらをご覧ください。

ダッシュボードの Top Pane を確認します。以下の情報が表示されます

Host Id: Splunk AppDynamics Controllerで一意のサーバー IDです
Health: サーバーの全体的な健全性を表示します
Hierarchy: サーバーをグループ化するための任意の階層です。詳細についてはこちらのドキュメントをご覧ください

サーバーの健全性アイコンをクリックして Violations & Anomalies パネルを表示します。パネルを確認して潜在的な問題を特定します
Current Health Rule Evaluation Status をクリックして、このサーバーに対して現在アラートが発生している問題があるかどうかを確認します

CPU Usage too high ルールをクリックします
Edit Health Rule をクリックします。Edit Health Rule パネルが開きます

このパネルではHealth Ruleを設定できます。別のラボでHealth Ruleの作成とカスタマイズについて詳しく説明します。ここでは既存のルールを確認するだけにします。

Warning Criteria をクリックします

この例では、CPUが5%を超えたときに警告条件が設定されていることがわかります。これが、Health Ruleが正常な状態ではなく警告を表示している理由です。Edit Health Rule パネルをキャンセルして Server Dashboard に戻ります。

Server Processes Dashboard の確認

Processes タブをクリックします。
View Options をクリックして異なるデータカラムを選択します。表示可能なKPIを確認します。

これでサーバープロセスダッシュボードを探索できます。このダッシュボードでは、以下のタスクを実行できます

選択した期間中にアクティブなすべてのプロセスを表示します。プロセスはServerMonitoring.ymlファイルで指定されたクラスごとにグループ化されます。
Command Lineカラムのプロセスエントリにマウスを合わせると、このプロセスを開始したフルコマンドラインを表示できます。
プロセスクラスを展開して、そのクラスに関連するプロセスを確認できます。
View Optionsを使用して、チャートに表示するカラムを設定できます。
表示されるメトリクスの期間を変更できます。
カラムをソートキーとして使用してチャートをソートできます。スパークラインチャート（CPU TrendとMemory Trend）ではソートできません。
CPUとメモリの使用傾向を一目で確認できます。

Server Processesダッシュボードについて詳しくはこちらをご覧ください。

Server Volumes Dashboard の確認

Volumes タブをクリックします。

これでサーバーボリュームダッシュボードを探索できます。このダッシュボードでは、以下のタスクを実行できます

ボリュームのリスト、使用率、およびディスク、パーティション、またはボリュームで利用可能な総ストレージ容量を確認できます。
ディスク使用量とI/O使用率、レート、1秒あたりの操作数、待機時間を確認できます。
収集および表示されるメトリクスの期間を変更できます。
チャート上の任意のポイントをクリックして、その時点のメトリクス値を確認できます。

Server Volumesダッシュボードについて詳しくはこちらをご覧ください。

Server Network Dashboard の確認

Network タブをクリックします。

これで Server Network ダッシュボードを探索できます。このダッシュボードでは、以下のタスクを実行できます

各ネットワークインターフェースのMAC、IPv4、IPv6アドレスを確認できます。
ネットワークインターフェースが有効かどうか、機能しているかどうか、イーサネットケーブルが接続された動作状態、全二重または半二重モードで動作しているか、ネットワークインターフェースが渡すことができる最大プロトコルデータユニットの最大転送単位（MTU）またはサイズ（バイト単位）、Mbit/sec単位のイーサネット接続速度を確認できます。
ネットワークスループット（キロバイト/秒）とパケットトラフィックを表示できます。
表示されるメトリクスの期間を変更できます。
チャート上の任意のポイントにマウスを合わせると、その時点のメトリクス値を確認できます。

Server Networkダッシュボードについて詳しくはこちらをご覧ください。

サーバーと APM の相関

3 minutes

サーバーとアプリケーションのコンテキスト間の移動

Server Visibility Monitoringエージェントは、同じホスト上で実行されているSplunk AppDynamics APMエージェントと自動的に関連付けられます。

Server Visibilityを有効にすると、アプリケーションのコンテキストでサーバーパフォーマンスメトリクスにアクセスできます。さまざまな方法でサーバーとアプリケーションのコンテキストを切り替えることができます。以下のステップに従って、サーバーメインダッシュボードからサーバー上で実行されているNodeの1つに移動します。

Dashboard タブをクリックしてメインのServer Dashboardに戻ります。
APM Correlation リンクをクリックします。

リストされているTierの1つで下矢印をクリックします。
TierのNodeリンクをクリックします。

これで Node Dashboard に移動しました。

Server タブをクリックして関連するホストメトリクスを確認します。

Server Visibility Monitoringエージェントがインストールされている場合、ホストメトリクスは関連するNodeのコンテキスト内で常に利用可能です。

サーバーとアプリケーションのコンテキスト間の移動について詳しくはこちらをご覧ください。

Business iQ

2 minutes

目標

このラーニングラボでは、AppDynamics Business iQについて学習します。

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

新しいエージェントレスAnalytics Java Agent（v 4.5.15以降）でAnalyticsを有効化する。
HTTPデータコレクターを設定する。
メソッド呼び出しデータコレクターを設定する。
ダッシュボードコンポーネントを理解する。
ビジネスダッシュボードを構築する。

ワークショップ環境

ラボ環境には2つのホストがあります

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

Controller VM

Application VM

ラボの前提条件

3 minutes

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

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

Controllerへのログイン

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

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

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

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

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

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

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

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

左メニューの Tiers & Nodes オプションをクリックします。
Grid View をクリックします。
各Nodeの App Agent Status が過去1時間で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で実行されていることを確認します。

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"
....

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

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

以下の画像のような出力が表示されるはずです。

アプリケーションでAnalyticsを有効化

2 minutes

Analyticsは以前、Machine Agentにバンドルされた別のエージェントが必要でした。しかし、現在Analyticsはエージェントレスで、Controller 4.5.16以降の.NET Agent 20.10以降およびJava Agent 4.5.15以降のAPM Agentに組み込まれています。

この演習では、WebブラウザからAppDynamics Controllerにアクセスし、エージェントレスAnalyticsを有効化します。

Controllerへのログイン

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

Analytics設定への移動

** 画面左上の Analytics タブを選択します。
** 左側の Configuration タブを選択します。
** Transaction Analytics - Configuration タブを選択します。
** アプリケーション Supercat-Trader-YOURINITIALS の横にあるチェックボックスをオンにします。
** Save ボタンをクリックします。

Transaction Summaryの検証

Analyticsがそのアプリケーションで機能し、トランザクションが表示されていることを確認します。

左メニューの Analytics tab タブを選択します。
Home タブを選択します。
Transactions from でアプリケーション Supercar-Trader-YOURINITIALS にフィルターします。

HTTPデータコレクターの設定

2 minutes

データコレクターを使用すると、ビジネストランザクションとTransaction Analyticsデータをアプリケーションデータで補完できます。アプリケーションデータは、ビジネストランザクションのパフォーマンス問題にコンテキストを追加できます。例えば、パフォーマンス問題の影響を受けたビジネストランザクションの特定のパラメータや戻り値（特定のユーザー、注文、製品など）を表示します。

HTTPデータコレクターは、ビジネストランザクションで交換されるHTTPメッセージのURL、パラメータ値、ヘッダー、Cookieをキャプチャします。

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

すべてのHTTPデータコレクターを有効化する。
関連するHTTPデータコレクターを観察して選択する。
HTTPパラメータを使用してAnalyticsでビジネスデータをキャプチャする。
HTTPパラメータのAnalyticsを検証する。

すべてのHTTPデータコレクターの有効化

最初に、すべてのHTTPデータコレクターをキャプチャして、Analyticsにキャプチャしてダッシュボードで使用できる有用なパラメータを把握します。

Tip

このステップは本番環境ではなく、UAT環境で実行することを強く推奨します。

画面左上の Applications タブを選択します。
Supercar-Trader-YOURINITIALS アプリケーションを選択します。
左側の Configuration タブを選択します。
Instrumentation リンクをクリックします。
Data Collectors タブを選択します。
HTTP Request Data Collectors の Add ボタンをクリックします。

次に、すべてのHTTPパラメータをキャプチャするHTTPデータコレクターを設定します。Transaction Analyticsに必要な正確なパラメータを特定するまで、オーバーヘッドを避けるためにTransaction Snapshotsでのみ有効にします。

Name に All HTTP Param を指定します。
Enable Data Collector for で Transaction Snapshots のチェックボックスをオンにします。
Transaction Analyticsは有効にしないでください。
HTTP Parametersセクションで + Add をクリックします。
新しいパラメータのDisplay Nameに All を指定します。
HTTP Parameter nameにアスタリスク * を指定します。
Save をクリックします。

“Ok"をクリックしてデータコレクターを確認します。
/Supercar-Trader/sell.do トランザクションを有効にします。
Save をクリックします。

HTTPパラメータを使用したAnalyticsでのビジネスデータのキャプチャ

次に、HTTPデータコレクターを再度設定しますが、今回は有用なHTTPパラメータのみをキャプチャしてTransaction Analyticsで有効にします。新しいHTTP Data Collectorを追加します：Application -> Configuration -> Instrumentation -> Data Collectorタブ -> HTTP Request Data Collectors セクションで Add をクリックします。

Nameに CarDetails を指定します。
Transaction Snapshots を有効にします。
Transaction Analytics を有効にします。
HTTP Parametersセクションで + Add をクリックします。
新しいパラメータのDisplay Nameに CarPrice_http を指定します。
HTTP Parameter nameに carPrice を指定します。
以下に示すように、残りのCarパラメータについても同様に繰り返します。
Save をクリックします。
Ok をクリックしてData Collectorの実装を確認します。

/Supercar-Trader/sell.do トランザクションを有効にします。
Save をクリックします。

All HTTP Param コレクターをクリックして選択し、Delete ボタンをクリックして削除します。

HTTPパラメータのAnalyticsの検証

次に、ビジネスデータがHTTPデータコレクターによってAppDynamics Analyticsでキャプチャされたかどうかを検証します。

画面左上の Analytics タブを選択します。
Searches タブを選択します。
+ Add ボタンをクリックし、新しい Drag and Drop Search を作成します。

+ Add Criteria をクリックします。
Application を選択し、アプリケーション名 Supercar-Trader-YOURINITIALS を検索します。
Fields パネルで、Business Parameters がCustom HTTP Request Dataのフィールドとして表示されていることを確認します。
CarPrice_http のチェックボックスをオンにし、フィールドにデータがあることを確認します。

メソッドデータコレクターの設定

2 minutes

メソッド呼び出しデータコレクターは、メソッド引数、変数、戻り値などのコードデータをキャプチャします。HTTPデータコレクターに十分なビジネスデータがない場合でも、コード実行からこれらの情報をキャプチャできます。

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

メソッドを発見する。
ディスカバリーセッションを開く。
メソッドパラメータを発見する。
コード内のオブジェクトにドリルダウンする。
メソッド呼び出しデータコレクターを作成する。
メソッド呼び出しデータコレクターのAnalyticsを検証する。

ディスカバリーセッションを開く

ソースコードからメソッドやパラメータを特定するアプリケーション開発者がいない場合があります。しかし、AppDynamicsから直接アプリケーションメソッドとオブジェクトを発見するアプローチがあります。

画面左上の Applications タブを選択します。
Supercar-Trader-YOURINITIALS アプリケーションを選択します。
Configuration タブを選択します。
Instrumentation リンクをクリックします。
Transaction Detection タブを選択します。
右側の Live Preview Button をクリックします。

Start Discovery Session ボタンをクリックします。
ポップアップウィンドウで Web-Portal Node を選択します。調査しているメソッドが実行されているのと同じNodeである必要があります。
Ok をクリックします。

右側のトグルで Tools を選択します。
ドロップダウンリストで Classes/Methods を選択します。
Search セクションで Classes with nameを選択します。
テキストボックスにクラス名 supercars.dataloader.CarDataLoader を入力します。クラス名を見つけるには、コールグラフを検索するか、理想的にはソースコードで見つけます。
Apply をクリックして一致するクラスメソッドを検索します。
結果が表示されたら、検索に一致するクラスを展開します。
同じメソッド saveCar を探します。

saveCar メソッドは入力パラメータとして CarForm オブジェクトを取ることに注意してください。

オブジェクトへのドリルダウン

メソッドを見つけたら、そのパラメータを調べて車の詳細プロパティを取得できる場所を見つけます。

saveCar メソッドは入力パラメータとして複合オブジェクト CarForm を取ることがわかりました。このオブジェクトにはアプリケーションWebページで入力されたフォームデータが保持されます。次に、そのオブジェクトを検査して、車の詳細をどのように取得できるかを見つける必要があります。

テキストボックスに入力オブジェクトのクラス名 supercars.form.CarForm を入力します。
Apply をクリックしてクラスメソッドを検索します。
結果が表示されたら、検索に一致する supercars.form.CarForm クラスを展開します。
必要な車の詳細を返すメソッドを探します。price、model、colorなどの get メソッドが見つかります。

メソッド呼び出しデータコレクターの作成

前の演習で得た知見を使用して、実行時に実行中のコードから車の詳細を直接取得するメソッド呼び出しデータコレクターを設定できます。

Applications タブを選択します。
Supercar-Trader-YOURINITIALS アプリケーションを選択します。
Configuration タブを選択します。
Instrumentation リンクをクリックします。
Data Collectors タブを選択します。
Method Invocation Data Collectors の Add をクリックします。

車の詳細をキャプチャするメソッド呼び出しデータコレクターを作成します。

Name に SellCarMI-YOURINITIALS を指定します。
Transaction Snapshots を有効にします。
Transaction Analytics を有効にします。
with a Class Name that を選択します。
Class Name に supercars.dataloader.CarDataLoader を追加します。
Method Name に saveCar を追加します。

観察したように、SaveCarメソッドのインデックス0の入力パラメータはクラス CarForm のオブジェクトであり、そのオブジェクト内には getPrice() などの車の詳細プロパティを返すGetterメソッドがあります。

MIDCでその値をどのように取得したかを説明すると、以下のようになります

MIDCパネルの下部にある Add をクリックして、収集する新しいデータを指定します。
Display Nameに CarPrice_MIDC を指定します。
Collect Data Fromで、CarForm Object である Method Parameter of Index 0 を選択します。
Operation on Method Parameter で Use Getter Chain を選択します。CarForm内のメソッドを呼び出して車の詳細を返します。
次に、価格を返す CarForm クラス内のGetterメソッド getPrice() を指定します。
Save をクリックします。

color、modelなど、データを収集したいすべてのプロパティについて、上記の手順を繰り返します。

MIDC を保存し、"/Supercar-Trader/sell.do" ビジネストランザクションに適用します。

MIDCの実装にはJVMの再起動が必要です

EC2インスタンスにSSH接続します。
Tomcatサーバーをシャットダウンします。

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

まだ実行中のアプリケーションJVMが見つかった場合は、以下のコマンドを使用して残りのJVMを終了します。

sudo pkill -f Supercar-Trader

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

./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"
....

MDパラメータのAnalyticsの検証

Webサイトにアクセスし、Sell Carページでフォームを数回送信して手動で負荷をかけます。

次に、ビジネスデータがHTTPデータコレクターによってAppDynamics Analyticsでキャプチャされたかどうかを検証します。

Analytics タブを選択します。
Searches タブを選択し、新しい Drag and Drop Search を追加します。
+ Add ボタンをクリックし、新しい Drag and Drop Search を作成します。
+ Add Criteria をクリックします。
Application を選択し、アプリケーション名 Supercar-Trader-YOURINITIALS を検索します。
Business Parameters が Custom Method Data のフィールドとして表示されていることを確認します。
CarPrice Field にデータがあることを確認します。

まとめ

これで、実行時にNodeからSell Carトランザクションのビジネスデータをキャプチャしました。このデータは、AppDynamicsのAnalyticsおよびダッシュボード機能で使用でき、ビジネスにより多くのコンテキストを提供し、ITがビジネスに与える影響を測定できます。

ダッシュボードコンポーネント

2 minutes

ダッシュボードを構築する機能は、AppDynamicsの機能と価値の重要なコンポーネントです。この演習では、魅力的なダッシュボードを構築するために使用できるダッシュボードコンポーネントのいくつかを操作します。

新しいダッシュボードの作成

Dashboard & Reports タブを選択します。
Create Dashboard をクリックします。
SuperCar-Dashboard-YOURINITIALS などのダッシュボード名を入力します。
Canvas Type として Absolute Layout を選択します。
OK をクリックします。

新しく作成した空のダッシュボードを開きます。次に、さまざまなウィジェットタイプを追加します。

ダッシュボードコンポーネント：カスタムウィジェットビルダー

カスタムウィジェットビルダーは、数値ビュー、時系列、円グラフなど、データの表現を生成できる非常に柔軟なツールです。AppDynamics ADクエリ言語に基づいています。

ウィジェットを作成するには、以下の手順に従います

ダッシュボードの左上隅にある Edit Mode を切り替えます。
Add Widget をクリックします。
左側の Analytics タブを選択します。
Custom Widget Builder をクリックします。

カスタムウィジェットビルダーでは、多くのチャートタイプを作成できます。情報をドラッグアンドドロップするか、Advancedペインでクエリを作成できます。

ここでは、数値チャート、棒グラフ、円グラフについて説明します。

数値チャート

演習： エラーによって影響を受けた金額を定量化することで、ITパフォーマンスがビジネス収益に与える影響を示すことができます。

Numeric チャートタイプを選択します。
Applicationフィールドにフィルターを追加し、アプリケーション名 Supercar-Trader-YOURINITIALS を選択します。
/Supercar-Trader/sell.do ビジネストランザクションにフィルターを追加します。
User Experienceフィールドにフィルターを追加し、Error のみを選択してエラーの影響を表示します。
左側のパネルで CarPrice_MIDC フィールドを見つけ、Y軸にドラッグアンドドロップします。SUMがモデルごとの合計価格をキャプチャするために使用される集計であることに注意してください。
見やすくするためにフォントの色を赤に変更します。
Save をクリックします。

User ExperienceフィルターをNORMAL、SLOW、VERY SLOWのみに変更することで、正常に処理された金額についても同様のことができます。

また、Analyticsモジュールでカスタムメトリクスを作成し、影響を受けた金額がベースライン以上かどうかを示すヘルスルールを定義することで、このメトリクスをベースライン化することもできます。通貨のラベルを追加することもできます。

棒グラフ

演習： 次に、影響を受けた車種のトップを視覚化する棒グラフを作成します。このチャートは、User Experienceで分類されたすべての SellCar トランザクションの車種を表示します。

+ Add Widget、Analytics、Custom Widger Builder をクリックして新しいウィジェットを作成します。
Column チャートタイプを選択します。
以下のフィルターを追加します：Application = Supercar-Trader-YOURINITIALS およびBusiness Transaction = /Supercar-Trader/sell.do。
X軸に CarModel_MIDC と User Experience を追加します。
Save をクリックします。

このチャートタイプは、ニーズに応じて調整できます。例えば、X軸を顧客タイプ、会社、組織などでグループ化できます。以下の例を参照してください。

円グラフ

次に、sellCar トランザクションによって報告されたすべての車種とモデルごとの価格の合計を表示する円グラフを作成します。これにより、アプリケーションで最も需要の高いモデルが表示されます。

新しいウィジェットを作成します。
Pie チャートタイプを選択します。
以下のフィルターを追加します：Application = Supercar-Trader-YOURINITIALS およびBusiness Transaction = /Supercar-Trader/sell.do。
X軸に CarModel_MIDC を追加します。
Y軸に CarPrice_MIDC を追加します。SUM がモデルごとの合計価格をキャプチャするために使用される集計であることに注意してください。
タイトルに Sold by Car Model を追加します。
Save をクリックします。

円グラフウィジェットのその他の使用例については、以下の例を参照してください。

ダッシュボードコンポーネント：コンバージョンファネル

コンバージョンファネルは、複数のステップからなるプロセスを通じたユーザーまたはイベントのフローを視覚化するのに役立ちます。これにより、より成功した収束のためにどのステップを最適化できるかをより良く理解できます。また、コンバージョンファネルを使用して各ステップのITパフォーマンスを調べ、ユーザーエクスペリエンスへの影響とユーザー離脱の原因を理解することもできます。

ファネルは、その特定の順序でこのパスを実行したユーザーに基づいてフィルタリングされており、ステップごとの総訪問数ではないことに注意してください。

ファネル作成の最初のステップは、ファネルを通じた各ユーザーナビゲーションを表すことができるトランザクションの一意の識別子を選択することです。通常、Session IDはファネルの各ステップを通じて永続するため、最良の選択です。

Session IDはトランザクションからキャプチャできます。ファネルトランザクションのカウンターとして使用するには、SessionId データコレクターが必要です。

Javaアプリケーションの場合、AppDynamicsにはデフォルトのHTTPデータコレクターでSession IDをキャプチャする機能があります。有効になっていることを確認し、すべてのビジネストランザクションに適用してすべてのトランザクションでSession IDをキャプチャします。

Applications タブを選択します。
Supercar-Trader-YOURINITIALS アプリケーションを選択します。
左側の Configuration タブを選択します。
Instrumentation をクリックします。
Data Collectors タブを選択します。
Default HTTP Request Request Data Collectors を編集します。
Transaction Analytics を選択します。
SessionID が選択されていることを確認します。
Save をクリックします。

次に、/Supercar-Trader/home.do ページから複数回ナビゲートして負荷をかけます。その後、アプリケーションの /Supercar-Trader/sell.do ページに直接ナビゲートします。

ダッシュボードに戻ってファネルウィジェットを作成します。

Edit スライダーを切り替えます。
Add Widget をクリックします。
Analytics タブを選択します。
Funnel Analysis をクリックします。
ドロップダウンリストから Transactions を選択します。
Count Distinct of でドロップダウンリストから uniqueSessionId を選択します。
Add Step をクリックします。Home Page と名前を付けます。
Add Criteria をクリックします。以下の条件を追加します：Application: Supercar-Trader-YOURINITIALS & Business Transactions: /Supercar-Trader/home.do。
Add Step をクリックします。SellCar Page と名前を付けます。
Add Criteria をクリックします。以下の条件を追加します：Application: Supercar-Trader-YOURINITIALS & Business Transactions: /Supercar-Trader/sell.do。
右側のパネルで Show Health チェックボックスを選択して、フローマップでトランザクションの正常性を視覚化します。
Save をクリックします。

ダッシュボードを構築する

20 minutes

演習 - 独自のダッシュボードを構築する

このラーニングラボの締めくくりとして、前の演習でメソッド呼び出しデータコレクターを使用してキャプチャしたビジネスデータとダッシュボードコンポーネントの理解を使用して、ITビジネスインパクトダッシュボードを構築します。

以下の例を参照し、同じデータとウィジェットを使用して独自のダッシュボードを構築してください。

おめでとうございます！BusinessIQ Fundamentalsラーニングラボを完了しました！

Browser Real User Monitoring (BRUM)

2 minutes

目標

このラーニングラボでは、AppDynamicsを使用してブラウザベースのアプリケーションの正常性を監視する方法を学習します。

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

Controllerでブラウザアプリケーションを作成する
Browser Real User Monitoring (BRUM) エージェントを設定してWebアプリケーションの正常性を監視する
パフォーマンス問題をトラブルシューティングし、ブラウザ側またはサーバー側のどちらで発生したかにかかわらず根本原因を見つける

ワークショップ環境

ワークショップ環境には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の動的なトラフィック（ビジネストランザクション）を生成することです。

BRUMラボの前提条件

2 minutes

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

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

Controllerへのログイン

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

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

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

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

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

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

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

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

左メニューの Tiers & Nodes オプションをクリックします。
Grid View をクリックします。
各Nodeの App Agent Status が過去1時間で90%以上であることを確認します。

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

以下のコマンドを使用して、実行中の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

以下の画像のような出力が表示されるはずです。

ブラウザアプリケーションの作成

2 minutes

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

WebブラウザからAppDynamics Controllerにアクセスする。
ControllerでBrowser Applicationを作成する。
Browser Applicationを設定する。

Controllerへのログイン

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

ControllerでのBrowser Applicationの作成

以下の手順に従って、新しいブラウザアプリケーションを作成します。

Note

下記のステップ5で、ブラウザアプリケーションに一意の名前を作成することが非常に重要です。

トップメニューの User Experience タブをクリックします。
User Experience の下にある Browser Apps オプションをクリックします。
Add App をクリックします。
Create an Application manually オプションを選択します。
Supercar-Trader-Web-<your_initials_or_name>-<four_random_numbers> の形式でブラウザアプリケーションの一意の名前を入力します。
- 例1: Supercar-Trader-Web-JFK-3179
- 例2: Supercar-Trader-Web-JohnSmith-0953
OK をクリックします。

これで Supercar-Trader-Web-##-#### アプリケーションの Browser App Dashboard が表示されるはずです。

左メニューの Configuration タブをクリックします。
Instrumentation オプションをクリックします。

以下の手順に従って、ブラウザ監視エージェントによってキャプチャされるデータと一緒にIPアドレスが保存されるようにデフォルト設定を変更します。

Settings タブをクリックします。
右側のスクロールバーを使用して画面の下部までスクロールします。
Store IP Address チェックボックスをオンにします。
Save をクリックします。

Browser RUM用のController UIの設定について詳しくは、こちらをご覧ください。

エージェントインジェクションの設定

3 minutes

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

JavaScript Agentインジェクションを有効化する。
インジェクション用のビジネストランザクションを選択する。

JavaScript Agentインジェクションの有効化

AppDynamicsはJavaScript Agentをインジェクトするさまざまな方法をサポートしていますが、このラボではAuto-Injection方式を使用します。以下の手順に従ってJavaScript Agentの自動インジェクションを有効化します。

左メニューの Applications タブをクリックし、Supercar-Trader-##アプリケーションにドリルダウンします。
下部にある左メニューの Configuration タブをクリックします。
User Experience App Integration オプションをクリックします。

JavaScript Agent Injection タブをクリックします。
Enable をクリックして青色に切り替えます。
Supercar-Trader-Web-##-#### が選択されたブラウザアプリであることを確認します。前のセクションで作成したアプリケーションを選択してください。
Enable JavaScript Injection の下にある Enable チェックボックスをオンにします。
Save をクリックします。

Auto-Injectionが潜在的なビジネストランザクションを検出するまで数分かかります。この間に、以下の手順でBusiness Transaction Correlationを有効化します。新しいAPMエージェントでは、これは自動的に行われます。

Business Transaction Correlation タブをクリックします。
Manually Enable Business Transactions セクションの下にある Enable ボタンをクリックします。
Save をクリックします。

インジェクション用のビジネストランザクションの選択

以下の手順に従って、Auto-Injection用のビジネストランザクションを選択します。

JavaScript Agent Injection タブをクリックします。
検索ボックスに .do と入力します。
すべての9つのBTが表示されるまで Refresh List リンクをクリックします。
右側のリストボックスからすべてのビジネストランザクションを選択します。
矢印ボタンをクリックして左側のリストボックスに移動します。
すべてのビジネストランザクションが左側のリストボックスに移動されていることを確認します。
Save をクリックします。

JavaScript Agentの自動インジェクションの設定について詳しくは、こちらをご覧ください。

ブラウザアプリケーションに負荷が表示され始めるまで数分待ちます。

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

2 minutes

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

Browser Application Overviewダッシュボードをレビューする
Browser Application Geoダッシュボードをレビューする
Browser Application Usage Statsダッシュボードをレビューする
Supercar-Traderアプリケーションのウェブページをナビゲートする

Browser Application Overviewダッシュボードのレビュー

User Experienceダッシュボードに移動し、以下の手順に従ってブラウザアプリケーションのOverviewダッシュボードにドリルダウンします。

左メニューの User Experience タブをクリックします。
Webアプリケーション Supercar-Trader-Web-##-### を検索します。
Details をクリックするか、アプリケーション名をダブルクリックします。

Overviewダッシュボードには、設定可能なウィジェットのセットが表示されます。デフォルトのウィジェットには、アプリケーションパフォーマンスの一般的な高レベル指標を含む複数のグラフとリストが含まれています

End User Response Time Distribution
End User Response Time Trend
Total Page Requests by Geo
End User Response Time by Geo
Top 10 Browsers
Top 10 Devices
Page Requests per Minute
Top 5 Pages by Total Requests
Top 5 Countries by Total Page Requests

ダッシュボードの機能を探索します。

+ をクリックして、ダッシュボードに追加するグラフとウィジェットを選択します。
任意のウィジェットの右下隅をクリックしてドラッグしてサイズを変更します。
任意のウィジェットの枠線部分を選択して、ダッシュボード上で移動して配置します。
任意のウィジェットのタイトルをクリックして、詳細ダッシュボードにドリルダウンします。
任意のウィジェットの右上隅にある X をクリックしてダッシュボードから削除します。

ダッシュボードウィジェットのレイアウトに加えた変更は自動的に保存されます。

Browser Application Overviewダッシュボードについて詳しくは、こちらをご覧ください。

Browser Application Geoダッシュボードのレビュー

Geoダッシュボードは、ページロードに基づいて地理的な場所ごとに主要なパフォーマンスメトリクスを表示します。ダッシュボード全体に表示されるメトリクスは、マップまたはグリッドで現在選択されているリージョンのものです。マップビューは、右側のパネルに表示されるキータイミングメトリクスの国に対してラベル付きの負荷円を表示します。ただし、一部の国とリージョンはグリッドビューでのみ表示されます。

Browser Application Geoダッシュボードに移動し、以下に説明するダッシュボードの機能を探索します。

Geo Dashboard オプションをクリックします。
負荷円の1つをクリックしてリージョンにドリルダウンします。
リージョンの1つにカーソルを合わせてリージョンの詳細を表示します。
ズームスライダーを使用してズームレベルを調整します。
Configuration をクリックしてマップオプションを探索します。
グリッドビューとマップビューを切り替えます。

Browser Application Geoダッシュボードについて詳しくは、こちらをご覧ください。

Browser Application Usage Statsダッシュボードのレビュー

Usage Stats ダッシュボードは、ユーザーのブラウザタイプとデバイス/プラットフォームに基づいて集約されたページロード使用データを表示します。

Browser Application Usage Statsダッシュボードは、以下のことを発見するのに役立ちます

合計エンドユーザー応答時間の面で最も遅いブラウザ。
応答ページをレンダリングするのに最も遅いブラウザ。
エンドユーザーの大半が使用しているブラウザ。
特定の国やリージョンでエンドユーザーの大半が使用しているブラウザ。

Browser Application Usage Statsダッシュボードに移動し、以下に説明するダッシュボードの機能を探索します。

Usage Stats オプションをクリックします。
Show Versions オプションをクリックします。
負荷ごとにさまざまなブラウザとバージョンを確認します。
円グラフのセクションにカーソルを合わせて詳細を確認します。

以下の手順を使用して、ブラウザとバージョンごとのその他のメトリクスを探索します。

右側のスクロールバーを使用してページの下部までスクロールします。
ブラウザとバージョンごとの利用可能なメトリクスを探索します。
国ごとの利用可能なメトリクスを探索します。

Devicesダッシュボードに移動し、以下に説明するダッシュボードの機能を探索します。

Devices オプションをクリックします。
デバイス別の負荷の内訳を確認します。
円グラフのセクションにカーソルを合わせて詳細を確認します。
デバイス別の利用可能なパフォーマンスメトリクスを探索します。

Browser Application Usage Statsダッシュボードについて詳しくは、こちらをご覧ください。

Supercar-TraderアプリケーションのWebページのナビゲート

Browser Real User Monitoringエージェントを設定し、最初の一連の機能を探索したので、Supercar-TraderアプリケーションのWebページをナビゲートして追加の負荷を生成し、ユニークなブラウザセッションを記録しましょう。

Webブラウザでアプリのメインページを開きます。以下の例のURLでは、Application VMのIPアドレスまたは完全修飾ドメイン名を置き換えてください。

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

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

利用可能なフェラーリのリストを開きます。

トップメニューの Supercars タブをクリックします。
フェラーリのロゴをクリックします。

フェラーリのリストが表示されるはずです。

最初のフェラーリの画像をクリックします。

View Enquiries をクリックします。
Enquire をクリックします。

車に関する問い合わせを送信します。

問い合わせフォームのフィールドに適切なデータを入力します。
Submit をクリックします。

車を検索し、サイトの閲覧を続けます。

トップメニューの Search タブをクリックします。
検索ボックスに文字 A を入力し、Search をクリックします。
残りのタブをクリックしてWebサイトを探索します。

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

2 minutes

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

作成したBrowser Sessionをレビューする。
Pages & AJAX Requestsダッシュボードをレビューする。
特定のBase Pageのダッシュボードをレビューする。
Browser Snapshotをトラブルシューティングする。

作成したBrowser Sessionのレビュー

セッションは、ユーザーがアプリケーションとやり取りする体験を分析するための時間ベースのコンテキストと考えることができます。ブラウザセッションを調べることで、アプリケーションがどのように動作しているか、ユーザーがどのようにアプリケーションとやり取りしているかを理解できます。これにより、UIの変更やサーバー側のパフォーマンスの最適化など、アプリケーションをより適切に管理および改善できます。

Sessionsダッシュボードに移動し、前の演習でWebアプリケーションのページをナビゲートして作成したブラウザセッションを見つけます。以下の手順に従います。

Note

Webアプリケーションの最後のページにアクセスしてからブラウザセッションがセッションリストに表示されるまで、10分程度待つ必要がある場合があります。10分経ってもセッションが表示されない場合は、使用中のJava Agentのバージョンに問題がある可能性があります。

左メニューの Sessions タブをクリックします。
Session FieldsリストでIPアドレスのチェックをオンにします。
IPアドレスで作成したセッションを見つけます。
セッションをクリックし、View Details をクリックします。

作成したセッションを見つけて開いたら、以下の手順に従ってセッションビューのさまざまな機能を探索します。

注意: ステップ5に示されているように、セッション内のどのページにも View Snapshot リンクがない場合があります。後でこの演習で、リンクがあるセッションを見つけて探索します。

Session Summary リンクをクリックしてサマリーデータを表示します。
左側に表示されているページをクリックすると、右側にそのページの詳細が表示されます。
左側のリストで選択したページの完全名を常に確認できます。
ウォーターフォールビューの水平の青いバーをクリックすると、そのアイテムの詳細が表示されます。
一部のページには、サーバー側でキャプチャされた相関スナップショットへのリンクがある場合があります。
設定アイコンをクリックして、ページリストに表示される列を変更します。

Browser RUM Sessionsについて詳しくは、こちらをご覧ください。

Pages & AJAX Requestsダッシュボードのレビュー

Pages & AJAX Requestsダッシュボードに移動し、そこにあるオプションを確認し、以下の手順に従って特定のBase Pageダッシュボードを開きます。

左メニューの Pages & AJAX Requests タブをクリックします。
ツールバーのオプションを探索します。
localhost:8080/supercar-trader/car.do ページをクリックします。
Details をクリックしてBase Pageダッシュボードを開きます。

特定のBase Pageのダッシュボードのレビュー

Base Pageダッシュボードの上部には、Controller UIの右上隅にあるタイムフレームドロップダウンで選択された期間全体のEnd User Response Time、Load、Cache Hits、Page Views with JS errorsなどの主要なパフォーマンス指標が表示されます。Cache Hitsは、ソースからではなくCDNなどのキャッシュから取得されたリソースを示します。

Timing Breakdownセクションには、ページロードプロセスの各側面に必要な平均時間を表示するウォーターフォールグラフが表示されます。各メトリクスが何を測定するかについての詳細情報は、左側の名前にカーソルを合わせると定義がポップアップ表示されます。より詳細な情報については、Browser RUM Metricsを参照してください。

以下の手順に従って、localhost:8080/supercar-trader/car.do Base Pageの詳細を確認します。

タイムフレームドロップダウンを last 2 hours に変更します。
主要なパフォーマンス指標を探索します。
ウォーターフォールビューのメトリクスを探索します。
垂直スクロールバーを使用してページを下にスクロールします。
すべてのKPI Trendsのグラフを探索します。

Base Pageダッシュボードについて詳しくは、こちらをご覧ください。

Browser Snapshotのトラブルシューティング

Note

アプリケーションにブラウザスナップショットがない場合があり、その場合はワークフロー全体を実行できません。このセクションを別のデモアプリケーションで実行したい場合は、ブラウザアプリケーション AD-Ecommerce-Browser に切り替えることができます。

Browser Snapshotsリストダッシュボードに移動し、以下の手順に従って特定のBrowser Snapshotを開きます。

Browser Snapshots オプションをクリックします。
End User Response Time 列ヘッダーを2回クリックして、最も長い応答時間を上部に表示します。
左から3番目の列にグレーまたは青のアイコンがあるブラウザスナップショットをクリックします。
Details をクリックしてブラウザスナップショットを開きます。

ブラウザスナップショットを開いたら、詳細を確認し、以下の手順に従って長い応答時間の根本原因を見つけます。

ウォーターフォールビューを確認して、応答時間がどこで影響を受けたかを理解します。
Server Time メトリクスが長くなっていることに注意してください。Server Time のラベルにカーソルを合わせてその意味を理解します。
ブラウザスナップショットに自動的にキャプチャされ相関付けられたサーバー側トランザクションをクリックします。
View Details をクリックして、関連するサーバー側スナップショットを開きます。

相関するサーバー側スナップショットを開いたら、以下の手順を使用してパフォーマンス低下の根本原因を特定します。

ブラウザで費やされたトランザクション時間の割合が最小限であることがわかります。
ブラウザとWeb-Portal Tier間のタイミングは、ブラウザからの初期接続から完全な応答が返されるまでを表しています。
JDBCコールが最も時間がかかっていたことがわかります。
Drill Down をクリックして、Enquiry-Services Tier内のコードレベルビューを確認します。

Enquiry-Services Tierのスナップショットセグメントを開くと、データベースへのJDBCコールがトランザクションの問題を引き起こしていたことがわかります。

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

Browser Snapshotsについて詳しくは、こちらとこちらをご覧ください。

Database Monitoring

2 minutes

目標

このラボでは、AppDynamics Database Visibility Monitoringについて学びます。

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

AppDynamics Database Visibility Agentのダウンロード
AppDynamics Database Visibility Agentのインストール
ControllerでのDatabase Collectorの構成
データベースの健全性監視
データベースパフォーマンス問題のトラブルシューティング

ワークショップ環境

ラボ環境には2つのホストがあります

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

Controller VM

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

Application VM

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

Supercar-Traderコレクションの目的は、AppDynamics Controller向けに動的なトラフィック（ビジネストランザクション）を生成することです。

ラボの前提条件

3 minutes

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

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

Controller へのログイン

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

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

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

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

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

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

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

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

左メニューの Tiers & Nodes オプションをクリックします。
Grid View をクリックします。
過去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 のダウンロード

2 minutes

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

Controller へのログイン

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

Database Agent のダウンロード

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

Databases をクリックします。

Database Agent のダウンロード

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

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

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

Database Agent のインストール

2 minutes

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 の構成

2 minutes

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 の構成

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

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

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

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

Username: root
Password: Welcome1!

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

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

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

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

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

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

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

2 minutes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

右側のスクロールバーを使用してダッシュボードの下部にスクロールします
CPU
Memory
Disk IO
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を特定できます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SmartAgent Deployment

2 minutes

はじめに

AppDynamics Smart Agent は、インフラストラクチャの包括的な監視機能を提供する軽量でインテリジェントなエージェントです。このセクションでは、4つの異なるデプロイアプローチについて説明します。これにより、組織のニーズと既存のツールに最適な方法を選択できます。

Smart Agent とは

Smart Agentは、AppDynamicsの次世代監視エージェントであり、以下を提供します

統合監視：インフラストラクチャ、アプリケーション、サービスを単一のエージェントで監視
軽量設計：最小限のリソースフットプリント
自動検出：アプリケーションを自動的に検出して監視
ネイティブ計装：アプリケーションパフォーマンスへの深い可視性
柔軟なデプロイ：複数のインストールと管理オプション

デプロイアプローチ

このセクションでは、Smart Agentを大規模にデプロイするための4つの異なるアプローチについて説明します

1. リモートインストール（smartagentctl）

SSH経由でデプロイするための smartagentctl CLIツールを使用する最も直接的なアプローチです。

最適な用途：

中程度の数のホストへの迅速なデプロイ
既存のCI/CDインフラストラクチャがない環境
テストおよび概念実証シナリオ
デプロイプロセスの直接制御

主な機能：

SSHベースの直接デプロイ
シンプルなYAML構成
追加のツールが不要
同時実行のサポート

2. Jenkins 自動化

完全なライフサイクル管理のためのJenkinsパイプラインを使用したエンタープライズグレードのデプロイです。

最適な用途：

すでにJenkinsを使用している組織
複雑なデプロイワークフロー
承認ゲートが必要な環境
既存のCI/CDパイプラインとの統合

主な機能：

パラメータ化されたパイプライン
数千のホストへのバッチ処理
完全なライフサイクル管理
集中ログとレポート

3. GitHub Actions 自動化

セルフホストランナーを使用したGitHub Actionsワークフローによる最新のCI/CDアプローチです。

最適な用途：

バージョン管理にGitHubを使用しているチーム
クラウドネイティブ環境
GitOpsワークフロー
Webベースの管理を好む分散チーム

主な機能：

11の専用ワークフロー
VPC内のセルフホストランナー
GitHubシークレット統合
スケーラビリティのための自動バッチ処理

4. Ansible 自動化

Infrastructure as CodeのためのAnsibleプレイブックを使用した構成管理アプローチです。

最適な用途：

構成管理にAnsibleを使用しているチーム
宣言的なインフラストラクチャ定義
フリート全体での一貫した状態管理

主な機能：

Infrastructure as Code（IaC）
冪等性のあるプレイブック
インベントリ管理
ロールベースの構成

適切なアプローチの選択

要素	リモートインストール	Jenkins	GitHub Actions	Ansible
セットアップの複雑さ	低	中	中	低
スケーラビリティ	良好（数百ホスト）	優秀（数千）	優秀（数千）	優秀（数千）
前提条件	SSH アクセスのみ	Jenkins サーバー	GitHub アカウント	Ansible Control Node
学習曲線	最小	中程度	中程度	低/中程度
自動化レベル	手動実行	完全自動化	完全自動化	完全自動化
最適なユースケース	迅速なデプロイ	エンタープライズ CI/CD	モダン DevOps	Infrastructure as Code

すべてのアプローチに共通する機能

どのデプロイ方法を選択しても、すべてのアプローチで以下の項目が提供されます

✅ リモートホストへの SSH ベースのデプロイ
✅ より高速なデプロイのための 同時実行
✅ 完全なライフサイクル管理（インストール、開始、停止、アンインストール）
✅ コントローラー設定の 構成管理
✅ エラー処理 とログ
✅ 数百から数千のホストへの スケーラビリティ

ワークショップ構成

各デプロイアプローチには専用のセクションがあります

リモートインストール - CLIベースの直接デプロイ
Jenkins 自動化 - パイプラインベースのエンタープライズデプロイ
GitHub Actions - 最新のワークフローベースのデプロイ
Ansible 自動化 - Infrastructure as Codeデプロイ

ニーズに応じて、1つまたはすべてのアプローチに従うことができます。

Tip

Smart Agentのデプロイが初めての場合は、より自動化されたソリューションに進む前に、基本を理解するために リモートインストール アプローチから始めることをお勧めします。

前提条件

いずれのデプロイアプローチに進む場合でも、以下の項目を確認してください

コントローラーアクセスを持つAppDynamicsアカウント
アカウント名とアクセスキー
SSHアクセスを持つターゲットホスト
ホストからAppDynamics Controllerへのネットワーク接続
ターゲットホストでの適切な権限

次のステップ

お好みのデプロイアプローチを選択し、そのセクションに進んでください

シンプルに始める：基礎を学ぶためにリモートインストールから始める
Jenkins でスケール：エンタープライズグレードの自動化のためにJenkinsに移行
GitHub でモダン化：クラウドネイティブワークフローのためにGitHub Actionsを採用
Ansible で自動化：宣言的な構成管理のためにAnsibleを使用

各セクションでは、Smart Agentを大規模にデプロイするための完全なハンズオンガイダンスを提供します。

リモートインストール

2 minutes

はじめに

このワークショップでは、smartagentctl コマンドラインツールを使用して、複数のリモートホストに同時に AppDynamics Smart Agent をインストールおよび管理する方法を紹介します。このアプローチは、JenkinsやGitHub Actionsなどの追加の自動化ツールを必要とせずに、SSHベースのリモート実行を使用してサーバーフリートにSmart Agentを迅速にデプロイするのに最適です。

学習内容

このワークショップでは、以下の方法を学びます

remote.yaml ファイルを使用した リモートホストの構成
config.ini を使用した Smart Agent 設定の構成
SSH経由で複数のホストに同時に Smart Agent をデプロイ
インフラストラクチャ全体でリモートから エージェントの開始と停止
すべてのリモートホストでの エージェントステータスの確認
一般的なインストールと接続の問題の トラブルシューティング

主な機能

🚀 SSH による直接デプロイ - 追加の自動化プラットフォームが不要
🔄 完全なライフサイクル管理 - エージェントのインストール、開始、停止、アンインストール
🏗️ Configuration as Code - YAMLおよびINIベースの構成ファイル
🔐 セキュア - SSHキーベースの認証
📈 同時実行 - 並列デプロイのための構成可能な同時実行性
🎛️ シンプルな CLI - 使いやすいsmartagentctlコマンドラインインターフェース

アーキテクチャ概要

┌─────────────────────────────────────────────────────────────────┐
│                  Remote Installation Architecture                │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  Control Node (smartagentctl) ──▶ SSH Connection               │
│                                          │                       │
│                                          ├──▶ Host 1 (SSH)      │
│                                          ├──▶ Host 2 (SSH)      │
│                                          ├──▶ Host 3 (SSH)      │
│                                          └──▶ Host N (SSH)      │
│                                                                  │
│  All hosts send metrics ──▶ AppDynamics Controller             │
└─────────────────────────────────────────────────────────────────┘

ワークショップの構成

このワークショップには以下が含まれます

前提条件 - 必要なアクセス、ツール、権限
構成 - config.ini と remote.yaml のセットアップ
インストールと起動 - リモートホストへのSmart Agentのデプロイと起動
トラブルシューティング - 一般的な問題と解決策

前提条件

smartagentctlがインストールされたControl Node
すべてのリモートホストへのSSHアクセス
認証用に構成されたSSH秘密鍵
Control Nodeでのsudo権限
SSHが有効になっているリモートホスト
AppDynamicsアカウントの認証情報

利用可能なコマンド

smartagentctl ツールは、以下のリモート操作をサポートしています

start --remote - リモートホストにSmart Agentをインストールして起動
stop --remote - リモートホストのSmart Agentを停止
status --remote - リモートホストのSmart Agentステータスを確認
install --remote - 起動せずにSmart Agentをインストール
uninstall --remote - リモートホストからSmart Agentを削除
--service フラグ - systemdサービスとしてインストール

すべてのコマンドは、詳細なログのための --verbose フラグをサポートしています。

Tip

このワークショップを進める最も簡単な方法は以下を使用することです

このページの右上にある左右の矢印（< | >）
キーボードの左（◀️）と右（▶️）のカーソルキー

1. 前提条件

リモートホストにSmart Agentをインストールする前に、以下の前提条件が満たされていることを確認してください

必要なアクセス

SSH アクセス：Smart Agentをインストールする予定のすべてのリモートホストへのSSHアクセスが必要です
SSH 秘密鍵：認証用に構成されたSSH秘密鍵
Sudo 権限：Control Nodeユーザーはsmartagentctlを実行するためにsudo権限が必要です
リモート SSH：リモートホストでSSHが有効になっており、アクセス可能である必要があります

ディレクトリ構造

Smart Agentのインストールディレクトリは、Control Nodeに設定されている必要があります

cd /home/ubuntu/appdsm

ディレクトリには以下が含まれます

smartagentctl - SmartAgentを管理するためのコマンドラインユーティリティ
smartagent - SmartAgentバイナリ
config.ini - メイン構成ファイル
remote.yaml - リモートホスト構成ファイル
conf/ - 追加の構成ファイル
lib/ - 必要なライブラリ

AppDynamics アカウント情報

AppDynamicsアカウントから以下の情報が必要です

Controller URL：AppDynamics SaaSコントローラーエンドポイント（例：fso-tme.saas.appdynamics.com）
Account Name：AppDynamicsアカウント名
Account Access Key：AppDynamicsアカウントアクセスキー
Controller Port：通常、HTTPS接続の場合は443

ターゲットホストの要件

リモートホストは以下の要件を満たす必要があります

オペレーティングシステム：Ubuntu/Linuxベースのシステム
SSH サーバー：SSHデーモンが実行中で接続を受け入れている状態
ユーザーアカウント：適切な権限を持つユーザーアカウント（通常はroot）
ネットワークアクセス：AppDynamics Controllerに到達できること
ディスク容量：Smart Agentのインストールに十分な容量（通常100MB未満）

セキュリティに関する考慮事項

続行する前に、以下のセキュリティベストプラクティスを確認してください

SSH キー：強力なSSHキーを使用（RSA 4096ビットまたはED25519）
アクセスキー：AccountAccessKeyを安全に保管
ホストキー検証：本番環境では、ホストキーの検証を計画
SSL/TLS：コントローラー通信には常にSSL/TLSを使用
ログファイル：機密情報を含むログファイルへのアクセスを制限

前提条件の確認

SSH 接続の確認

リモートホストへのSSH接続をテストします

ssh -i /home/ubuntu/.ssh/id_rsa ubuntu@<remote-host-ip>

SSH キーのパーミッションの確認

SSHキーに適切なパーミッションがあることを確認します

chmod 600 /home/ubuntu/.ssh/id_rsa

ネットワーク接続の確認

リモートホストが相互に、およびインターネットに到達できることを確認します

ping <remote-host-ip>

Sudo アクセスの確認

sudo権限があることを確認します

sudo -v

すべての前提条件が満たされていれば、構成を開始する準備ができています。

2. 構成

Smart Agentのリモートインストールには、2つの主要な構成ファイルが必要です：Smart Agent設定用の config.ini と、リモートホストと接続パラメータを定義する remote.yaml です。

構成ファイルの概要

両方の構成ファイルは、Smart Agentのインストールディレクトリに配置する必要があります

cd /home/ubuntu/appdsm

構成する2つのファイル

config.ini - すべてのリモートホストにデプロイされるSmart Agent構成
remote.yaml - リモートホストとSSH接続設定

config.ini - Smart Agent 構成

config.ini ファイルには、すべてのリモートホストにデプロイされるメインのSmart Agent構成が含まれています。

場所： /home/ubuntu/appdsm/config.ini

Controller 構成

AppDynamics Controller接続を構成します

ControllerURL    = fso-tme.saas.appdynamics.com
ControllerPort   = 443
FMServicePort    = 443
AccountAccessKey = your-access-key-here
AccountName      = your-account-name
EnableSSL        = true

主要パラメータ：

ControllerURL：AppDynamics SaaSコントローラーエンドポイント
ControllerPort：コントローラーのHTTPSポート（デフォルト：443）
FMServicePort：Flow Monitoringサービスポート
AccountAccessKey：AppDynamicsアカウントアクセスキー
AccountName：AppDynamicsアカウント名
EnableSSL：SSL/TLS暗号化を有効にする（本番環境では true にする必要があります）

Common Configuration

エージェントのIDとポーリング動作を定義します

[CommonConfig]
AgentName            = smartagent
PollingIntervalInSec = 300
Tags                 = environment:production,region:us-east
ServiceName          = my-application

パラメータ：

AgentName：エージェントの名前識別子
PollingIntervalInSec：エージェントがデータをポーリングする頻度（秒単位）
Tags：エージェントを分類するためのカスタムタグ（カンマ区切り）
ServiceName：論理グループ化のためのオプションのサービス名

Telemetry 設定

ログとプロファイリングを構成します

[Telemetry]
LogLevel  = DEBUG
LogFile   = /opt/appdynamics/appdsmartagent/log.log
Profiling = false

パラメータ：

LogLevel：ログの詳細度（DEBUG、INFO、WARN、ERROR）
LogFile：リモートホストでログが書き込まれるパス
Profiling：パフォーマンスプロファイリングを有効にする（true/false）

TLS クライアント設定

プロキシとTLS設定を構成します

[TLSClientSetting]
Insecure        = false
AgentHTTPProxy  =
AgentHTTPSProxy =
AgentNoProxy    =

パラメータ：

Insecure：TLS証明書の検証をスキップ（本番環境では推奨されません）
AgentHTTPProxy：HTTPプロキシサーバー URL（必要な場合）
AgentHTTPSProxy：HTTPSプロキシサーバー URL（必要な場合）
AgentNoProxy：プロキシをバイパスするホストのカンマ区切りリスト

Auto Discovery

自動アプリケーション検出を構成します

[AutoDiscovery]
RunAutoDiscovery          = false
ExcludeLabels             = process.cpu.usage,process.memory.usage
ExcludeProcesses          =
ExcludeUsers              =
AutoDiscoveryTimeInterval = 4h
AutoInstall               = false

パラメータ：

RunAutoDiscovery：アプリケーションを自動的に検出する（true/false）
ExcludeLabels：検出から除外するメトリクス
ExcludeProcesses：監視から除外するプロセス名
ExcludeUsers：監視から除外するユーザーアカウント
AutoDiscoveryTimeInterval：検出を実行する頻度（例：4h、30m）
AutoInstall：検出されたアプリケーションを自動的にインストール

Task Configuration

ネイティブ計装を構成します

[TaskConfig]
NativeEnable        = true
UserPortalUserName  =
UserPortalPassword  =
UserPortalAuth      = none
AutoUpdateLdPreload = true

パラメータ：

NativeEnable：ネイティブ計装を有効にする
AutoUpdateLdPreload：LD_PRELOAD設定を自動的に更新

remote.yaml - リモートホスト構成

remote.yaml ファイルは、Smart Agentがインストールされるリモートホストと接続パラメータを定義します。

場所： /home/ubuntu/appdsm/remote.yaml

構成例

max_concurrency: 4
remote_dir: "/opt/appdynamics/appdsmartagent"
protocol:
  type: ssh
  auth:
    username: ubuntu
    private_key_path: /home/ubuntu/.ssh/id_rsa
    privileged: true
    ignore_host_key_validation: true
    known_hosts_path: /home/ubuntu/.ssh/known_hosts
hosts:
  - host: "172.31.1.243"
    port: 22
    user: root
    group: root
  - host: "172.31.1.48"
    port: 22
    user: root
    group: root
  - host: "172.31.1.142"
    port: 22
    user: root
    group: root
  - host: "172.31.1.5"
    port: 22
    user: root
    group: root

グローバル設定

max_concurrency： 同時に処理するホストの最大数

デフォルト：4
多くのホストへの高速デプロイのために増加
ネットワークまたはリソースの制約がある場合は減少

remote_dir： リモートホストのインストールディレクトリ

デフォルト：/opt/appdynamics/appdsmartagent
絶対パスである必要があります
ユーザーは書き込み権限を持っている必要があります

Protocol 構成

type： 接続プロトコル

値：ssh

auth.username： 認証用のSSHユーザー名

例：ubuntu、ec2-user、centos
リモートホストで構成されているユーザーと一致する必要があります

auth.private_key_path： SSH秘密鍵へのパス

絶対パスである必要があります
キーはアクセス可能で適切なパーミッション（600）を持っている必要があります

auth.privileged： 昇格した権限でエージェントを実行

true：root/systemdサービスとしてインストール
false：ユーザープロセスとしてインストール
推奨：本番デプロイでは true

auth.ignore_host_key_validation： SSHホストキー検証をスキップ

true：検証をスキップ（テストに便利）
false：ホストキーを検証（本番環境で推奨）

auth.known_hosts_path： SSH known_hostsファイルへのパス

デフォルト：/home/ubuntu/.ssh/known_hosts
ホストキー検証が有効な場合に使用

ホスト定義

各ホストエントリには以下が必要です

host： リモートマシンのIPアドレスまたはホスト名

IPv4、IPv6、またはホスト名が使用可能
Control Nodeから到達可能である必要があります

port： SSHポート

デフォルト：22
SSHが非標準ポートで実行されている場合は変更

user： Smart Agentプロセスを所有するユーザーアカウント

システム全体のインストールでは通常 root
ユーザー固有のインストールでは通常のユーザーも可能

group： Smart Agentプロセスを所有するグループ

通常はユーザーと一致（例：root）

ホストの追加

追加のリモートホストを追加するには、hosts リストに追加します

hosts:
  - host: "10.0.1.10"
    port: 22
    user: root
    group: root
  - host: "10.0.1.11"
    port: 22
    user: root
    group: root

Tip

必要な数だけホストを追加できます。max_concurrency 設定で並列処理されるホスト数を制御します。

構成の確認

インストールを進める前に、構成ファイルを確認してください

remote.yaml の確認

cat /home/ubuntu/appdsm/remote.yaml

以下を確認します

すべてのホストIPアドレスが正しいこと
SSHキーパスが有効であること
リモートディレクトリパスが適切であること

config.ini の確認

cat /home/ubuntu/appdsm/config.ini

以下を確認します

Controller URLとアカウント情報が正しいこと
ログファイルパスが有効であること
設定が環境要件に一致していること

YAML 構文の検証

YAMLファイルが正しくフォーマットされていることを確認します

python3 -c "import yaml; yaml.safe_load(open('/home/ubuntu/appdsm/remote.yaml'))"

コマンドがエラーなしで完了すれば、YAML構文は有効です。

構成ファイルの準備ができたら、インストールを進めることができます。

3. インストールと起動

設定ファイルの準備ができたら、smartagentctl コマンドラインツールを使用してリモートホストにSmart Agentをインストールし、起動できます。

インストールプロセスの概要

インストールプロセスは以下の手順で構成されます

接続: 定義されたすべてのホストへのSSH接続を確立します
転送: Smart Agentのバイナリと設定をリモートホストにコピーします
インストール: 各ホストの /opt/appdynamics/appdsmartagent/ にSmart Agentをインストールします
起動: 各リモートホストでSmart Agentプロセスを起動します
ログ出力: コンソールとログファイルに詳細な進捗を出力します

ステップ1: インストールディレクトリに移動

Smart Agentのインストールディレクトリに移動します

cd /home/ubuntu/appdsm

ステップ2: 設定ファイルの確認

インストールを開始する前に、設定ファイルが正しく設定されていることを確認します

リモートホスト設定の確認

cat remote.yaml

すべてのホストIPアドレス、ポート、SSH設定が正しいことを確認します。

エージェント設定の確認

cat config.ini

コントローラーURL、アカウント認証情報、その他の設定が正確であることを確認します。

ステップ3: リモートホストで Smart Agent を起動

以下のコマンドを実行して、remote.yaml で定義されたすべてのリモートホストでSmart Agentを起動します

sudo ./smartagentctl start --remote --verbose

コマンドの内訳

sudo: 特権操作に必要です
./smartagentctl: 制御ユーティリティ
start: Smart Agentを起動するコマンド
--remote: リモートホストにデプロイ（remote.yaml から読み取り）
--verbose: 詳細なデバッグログを有効化

注意

--verbose フラグの使用を強く推奨します。インストールの進捗に関する詳細な出力が提供され、問題の特定に役立ちます。

ステップ4: インストールの監視

--verbose フラグにより、以下の詳細な出力が提供されます

SSH接続ステータス
ファイル転送の進捗
各ホストでのインストール手順
エージェントの起動ステータス
エラーや警告

期待される出力

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

Starting Smart Agent deployment to remote hosts...
Connecting to 172.31.1.243:22...
Connection successful: 172.31.1.243
Transferring Smart Agent binaries...
Installing Smart Agent on 172.31.1.243...
Starting Smart Agent on 172.31.1.243...
Smart Agent started successfully on 172.31.1.243

Connecting to 172.31.1.48:22...
...

ステップ5: インストールの確認

インストールが完了したら、リモートホストでSmart Agentが実行されていることを確認します。

リモートでのステータス確認

statusコマンドを使用してすべてのリモートホストを確認します

sudo ./smartagentctl status --remote --verbose

各ホストに問い合わせて、Smart Agentが実行中かどうかを報告します。

コントロールノードのログ確認

コントロールノードのログを確認します

tail -f /home/ubuntu/appdsm/log.log

リモートホストにSSHで接続して確認

リモートホストにSSHで接続して直接確認することもできます

ssh ubuntu@172.31.1.243
tail -f /opt/appdynamics/appdsmartagent/log.log
ps aux | grep smartagent

その他のコマンド

起動せずにインストールのみ実行

Smart Agentを起動せずにインストールのみ行います

sudo ./smartagentctl install --remote --verbose

バイナリと設定をコピーしますが、エージェントプロセスは起動しません。

Smart Agent の停止

すべてのリモートホストでSmart Agentを停止します

sudo ./smartagentctl stop --remote --verbose

システムサービスとしてインストール

Smart Agentをsystemdサービスとしてインストールします（本番環境で推奨）

sudo ./smartagentctl start --remote --verbose --service

サービスとしてインストールした場合

システム起動時にSmart Agentが自動的に起動します
systemctl コマンドで管理できます
システムログとの統合が向上します

Smart Agent のアンインストール

リモートホストからSmart Agentを完全に削除します

sudo ./smartagentctl uninstall --remote --verbose

警告

uninstallコマンドはリモートホストからすべてのSmart Agentファイルを削除します。重要な設定ファイルやログファイルのバックアップがあることを確認してください。

AppDynamics Controller での確認

リモートホストでSmart Agentを起動した後

AppDynamics Controller にログイン: コントローラーURLに移動します
Servers に移動: Controller UIのServersセクションを確認します
エージェントの確認: Smart Agentがリストに表示されます
Metric の確認: 各ホストからMetricが収集されていることを確認します

期待されるタイムライン

エージェントの登録: エージェントは通常、起動後1～2分以内にControllerに表示されます
初期 Metric: 最初のMetricは通常5分以内に到着します
完全なデータ: 最初のポーリング間隔後に完全なデータ収集が開始されます（config.ini で設定）

ログファイルの場所

ログはコントロールノードとリモートホストの両方に書き込まれます

場所	パス	説明
コントロールノード	`/home/ubuntu/appdsm/log.log`	インストールとデプロイのログ
リモートホスト	`/opt/appdynamics/appdsmartagent/log.log`	エージェントのランタイムログ

同時実行数について

remote.yaml の max_concurrency 設定は並列実行を制御します

低い値（1-2）: 逐次処理、低速だが安全
デフォルト（4）: ほとんどの環境に適したバランス
高い値（8以上）: 多数のホストへの高速デプロイ、より多くのリソースが必要

例: 12台のホストで max_concurrency: 4 の場合

第1バッチ: ホスト1-4を同時に処理
第2バッチ: ホスト5-8を同時に処理
第3バッチ: ホスト9-12を同時に処理

各リモートホストでの処理内容

startコマンドを実行すると、各リモートホストで以下の処理が行われます

ディレクトリの作成: /opt/appdynamics/appdsmartagent/ を作成します
ファイル転送: smartagent バイナリ、config.ini、ライブラリをコピーします
権限の設定: 適切なファイル権限を設定します
プロセスの起動: Smart Agentプロセスを起動します
確認: プロセスが実行中であることを確認します

次のステップ

Smart Agentのインストールと起動が正常に完了した後

AppDynamics Controller UIにエージェントが表示されることを確認します
Metricが収集されていることを確認します
必要に応じてアプリケーションモニタリングを設定します
アラートとDashboardを設定します
エージェントの正常性とパフォーマンスを監視します

問題が発生した場合は、トラブルシューティングセクションに進みます。

4. トラブルシューティング

このセクションでは、Smart Agentをリモートホストにデプロイする際に発生する一般的な問題とその解決方法について説明します。

SSH接続の問題

問題: リモートホストに接続できない

症状:

接続タイムアウトエラー
“Permission denied” メッセージ
ホストキー検証の失敗

解決方法:

1. SSHキーの権限を確認

SSHキーには正しい権限が必要です:

chmod 600 /home/ubuntu/.ssh/id_rsa
chmod 644 /home/ubuntu/.ssh/id_rsa.pub
chmod 700 /home/ubuntu/.ssh

2. SSH接続を手動でテスト

各リモートホストへの接続をテストします:

ssh -i /home/ubuntu/.ssh/id_rsa ubuntu@172.31.1.243

これが失敗する場合、問題はsmartagentctlではなくSSH設定にあります。

3. リモートホストの到達性を確認

ネットワーク接続性を確認します:

ping 172.31.1.243
telnet 172.31.1.243 22

4. SSHユーザーの確認

remote.yaml のユーザー名がSSHユーザーと一致していることを確認します:

protocol:
  auth:
    username: ubuntu  # Must match your SSH user

5. Known Hosts の確認

ホストキー検証が有効な場合、ホストがknown_hostsに登録されていることを確認します:

ssh-keyscan 172.31.1.243 >> /home/ubuntu/.ssh/known_hosts

または、remote.yaml でホストキー検証を一時的に無効化します:

protocol:
  auth:
    ignore_host_key_validation: true

警告

ホストキー検証の無効化はテスト目的でのみ使用してください。本番環境では必ず有効にしてください。

権限の問題

問題: インストール中に権限が拒否される

症状:

ディレクトリ作成時の “Permission denied”
/opt/appdynamics/ への書き込み不可
権限不足エラー

解決方法:

1. コントロールノードでのSudoアクセスを確認

sudo -v

2. Privileged 設定を確認

remote.yaml で privileged: true が設定されていることを確認します:

protocol:
  auth:
    privileged: true

3. リモートユーザーの権限を確認

リモートユーザーにはsudo権限またはroot権限が必要です。リモートホストでテストします:

ssh ubuntu@172.31.1.243
sudo mkdir -p /opt/appdynamics/test
sudo rm -rf /opt/appdynamics/test

4. リモートディレクトリの権限を確認

カスタムインストールディレクトリを使用している場合、書き込み可能であることを確認します:

ssh ubuntu@172.31.1.243
ls -la /opt/appdynamics/

エージェントが起動しない

問題: エージェントのインストールは成功するが起動しない

症状:

インストールはエラーなく完了
リモートホストでエージェントプロセスが実行されていない
コントロールノードのログにエラーなし

解決方法:

1. リモートホストのログを確認

リモートホストにSSHで接続してエージェントのログを確認します:

ssh ubuntu@172.31.1.243
tail -100 /opt/appdynamics/appdsmartagent/log.log

以下を示すエラーメッセージを探します:

設定エラー
ネットワーク接続の問題
依存関係の不足

2. エージェントプロセスの確認

エージェントプロセスが実行中かどうかを確認します:

ssh ubuntu@172.31.1.243
ps aux | grep smartagent

実行されていない場合、手動で起動を試みます:

ssh ubuntu@172.31.1.243
cd /opt/appdynamics/appdsmartagent
sudo ./smartagent

3. 設定ファイルの確認

config.ini が正しく転送されたことを確認します:

ssh ubuntu@172.31.1.243
cat /opt/appdynamics/appdsmartagent/config.ini

以下を確認します:

コントローラーURLが正しいこと
アカウント認証情報が有効であること
必須フィールドがすべて入力されていること

4. コントローラーへの接続テスト

リモートホストからAppDynamics Controllerへの接続を確認します:

ssh ubuntu@172.31.1.243
curl -I https://fso-tme.saas.appdynamics.com

5. システムリソースの確認

リモートホストに十分なリソースがあることを確認します:

ssh ubuntu@172.31.1.243
df -h  # Check disk space
free -m  # Check memory

設定エラー

問題: 無効な設定

症状:

YAML解析エラー
無効な設定パラメーターエラー
設定エラーでエージェントが起動に失敗

解決方法:

1. YAML構文の検証

remote.yaml のYAML構文エラーを確認します:

python3 -c "import yaml; yaml.safe_load(open('/home/ubuntu/appdsm/remote.yaml'))"

一般的なYAMLの問題:

インデントの誤り（タブではなくスペースを使用）
コロンの欠落
引用符で囲まれていない特殊文字

2. INIファイル形式の確認

config.ini の構文エラーを確認します:

cat /home/ubuntu/appdsm/config.ini

一般的なINIの問題:

セクションヘッダーの欠落（例: [CommonConfig]）
無効なパラメーター名
等号の欠落

3. コントローラー認証情報の検証

AppDynamicsの認証情報が正しいことを確認します:

ControllerURL: https:// や /controller を含めないこと
AccountAccessKey: 完全なアクセスキーであること
AccountName: アカウント名と正確に一致すること

正しい形式の例:

ControllerURL    = fso-tme.saas.appdynamics.com
AccountAccessKey = abc123xyz789
AccountName      = fso-tme

エージェントが Controller に表示されない

問題: エージェントが起動するが Controller UI に表示されない

症状:

リモートホストでエージェントプロセスが実行中
エージェントログにエラーなし
Controller UIにエージェントが表示されない

解決方法:

1. 初期登録を待つ

エージェントが起動してからControllerに表示されるまで1～5分かかる場合があります。

2. コントローラー設定の確認

エージェントがコントローラーに到達できることを確認します:

ssh ubuntu@172.31.1.243
ping fso-tme.saas.appdynamics.com
curl -I https://fso-tme.saas.appdynamics.com

3. エージェントログで接続エラーを確認

コントローラー接続エラーを確認します:

ssh ubuntu@172.31.1.243
grep -i "error\|fail\|controller" /opt/appdynamics/appdsmartagent/log.log

4. SSL/TLS設定の確認

config.ini でSSLが有効になっていることを確認します:

EnableSSL = true

5. ファイアウォールルールの確認

リモートホストからControllerへのアウトバウンドHTTPS（ポート443）が許可されていることを確認します。

6. アカウント認証情報の確認

Controller UIでAccountAccessKeyとAccountNameが正しいことを再確認します:

AppDynamics Controllerにログインします
Settings > Licenseに移動します
アカウント名とアクセスキーを確認します

パフォーマンスとスケーリングの問題

問題: デプロイが遅い、またはタイムアウトする

症状:

デプロイに時間がかかりすぎる
多数のホストへのデプロイ時にタイムアウトエラー
システムリソースの枯渇

解決方法:

1. 同時実行数の調整

問題が発生している場合、remote.yaml の max_concurrency を減らします:

max_concurrency: 2  # Lower value for slower, more stable deployment

リソースに余裕がある場合、より高速なデプロイのために増やします:

max_concurrency: 8  # Higher value for faster deployment

2. バッチに分けてデプロイ

非常に大規模なデプロイの場合、ホストを複数のグループに分割します:

remote-batch1.yaml:

hosts:
  - host: "172.31.1.1"
  - host: "172.31.1.2"
  - host: "172.31.1.3"

remote-batch2.yaml:

hosts:
  - host: "172.31.1.4"
  - host: "172.31.1.5"
  - host: "172.31.1.6"

その後、各バッチを個別にデプロイします。

3. ネットワーク帯域幅の確認

デプロイ中のネットワーク使用量を監視します:

iftop

帯域幅が飽和している場合、同時実行数を減らすか、ピーク外の時間帯にデプロイします。

ログ分析

コントロールノードのログ確認

詳細なデプロイログを確認します:

tail -f /home/ubuntu/appdsm/log.log

以下を確認します:

SSH接続の失敗
ファイル転送エラー
権限拒否エラー
タイムアウトメッセージ

リモートホストのログ確認

リモートホストのエージェントランタイムログを確認します:

ssh ubuntu@172.31.1.243
tail -f /opt/appdynamics/appdsmartagent/log.log

以下を確認します:

コントローラー接続エラー
設定エラー
エージェント起動の失敗
ネットワークの問題

ログの詳細度を上げる

より詳細なログが必要な場合、config.ini で LogLevel を DEBUG に設定します:

[Telemetry]
LogLevel = DEBUG

ヘルプの取得

問題が解決しない場合:

ドキュメントの確認: smartagentctlのヘルプを確認します:
```
./smartagentctl --help
./smartagentctl start --help
```
AppDynamics ドキュメントの確認: AppDynamicsドキュメントポータルを参照します
ログファイルの確認: コントロールノードとリモートホストの両方のログを必ず確認します
コンポーネントを個別にテスト:
- SSH接続性を個別にテストします
- 単一のホストでエージェントの起動を手動でテストします
- コントローラーへの接続性を個別に確認します
診断情報の収集:
- コントロールノードのログ
- リモートホストのログ
- 設定ファイル（機密データは削除）
- エラーメッセージとスタックトレース

一般的なエラーメッセージ

エラーメッセージ	原因	解決方法
“Permission denied (publickey)”	SSHキー認証の失敗	SSHキーのパスと権限を確認
“Connection refused”	SSHポートにアクセスできない	ファイアウォールルールとSSHデーモンを確認
“No such file or directory”	設定ファイルが見つからない	設定ファイルの存在とパスが正しいことを確認
“YAML parse error”	無効なYAML構文	YAMLパーサーで構文を検証
“Controller unreachable”	ネットワーク接続の問題	リモートホストからコントローラーへの接続性をテスト
“Invalid credentials”	アカウントキーまたは名前が不正	AppDynamics の認証情報を確認

トラブルシューティングのベストプラクティス

常に –verbose フラグを使用: デバッグのための詳細な出力を提供します
最初に単一のホストでテスト: スケールアウトする前に1台のホストにデプロイします
すぐにログを確認: デプロイ直後にログを確認します
前提条件の確認: デプロイ前にすべての要件が満たされていることを確認します
接続性を個別にテスト: SSHとネットワーク接続性を個別に確認します
手動コマンドを使用: 手動でのSSHとエージェント起動をテストして問題を切り分けます

ヒント

トラブルシューティングでは、より複雑な問題に移る前に、最も簡単なテスト（例: ping、SSH接続性）から始めてください。

Jenkins 自動化

2 minutes

はじめに

このワークショップでは、Jenkins を使用して複数のEC2インスタンスにわたる AppDynamics Smart Agent のデプロイとライフサイクル管理を自動化する方法を紹介します。10台のホストでも10,000台のホストでも、Jenkinsパイプラインを活用したスケーラブルで安全かつ再現性のあるSmart Agent運用方法を説明します。

学習内容

このワークショップでは、以下の内容を学びます:

Jenkinsを使用して複数のホストに同時に Smart Agent をデプロイ する
安全なSSHおよびAppDynamicsアクセスのために Jenkins 認証情報を設定 する
柔軟なデプロイシナリオのために パラメータ化されたパイプラインを作成 する
数千台のホストに対応するために バッチ処理を実装 する
インストール、設定、停止、クリーンアップを含む エージェントの完全なライフサイクルを管理 する
自動エラー追跡とレポートにより 障害を適切に処理 する

主な機能

並列デプロイ - 複数のホストに同時にデプロイ
完全なライフサイクル管理 - エージェントのインストール、アンインストール、停止、クリーンアップ
Infrastructure as Code - すべてのパイプラインをバージョン管理
セキュア - Jenkins認証情報によるSSH鍵ベースの認証
大規模スケーラブル - 自動バッチ処理により数千台のホストにデプロイ
Jenkins Agent - AWS VPC内で実行

アーキテクチャ概要

┌─────────────────────────────────────────────────────────────────┐
│                    Jenkins-based Deployment                      │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  Developer ──▶ Jenkins Master ──▶ Jenkins Agent (AWS VPC)      │
│                                          │                       │
│                                          ├──▶ Host 1 (SSH)      │
│                                          ├──▶ Host 2 (SSH)      │
│                                          ├──▶ Host 3 (SSH)      │
│                                          └──▶ Host N (SSH)      │
│                                                                  │
│  All hosts send metrics ──▶ AppDynamics Controller             │
└─────────────────────────────────────────────────────────────────┘

ワークショップの構成

このワークショップには以下の内容が含まれます:

アーキテクチャと設計 - システム設計とネットワークトポロジーの理解
Jenkins セットアップ - Jenkins、認証情報、エージェントの設定
パイプライン作成 - デプロイパイプラインの作成と設定
デプロイワークフロー - デプロイの実行とインストールの検証

前提条件

Jenkinsサーバー（2.300以降）とPipelineプラグイン
ターゲットEC2インスタンスと同じVPC内のJenkinsエージェント
認証用のSSHキーペア
AppDynamics Smart Agentパッケージ
SSHアクセス可能なターゲットUbuntu EC2インスタンス

GitHub リポジトリ

すべてのパイプラインコードと設定ファイルはGitHubリポジトリで公開されています:

https://github.com/chambear2809/sm-jenkins

リポジトリには以下が含まれます:

完全なJenkinsfileパイプライン定義
詳細なセットアップドキュメント
設定例
トラブルシューティングガイド

ヒント

このワークショップを最も簡単にナビゲートするには、以下を使用します:

このページの右上にある左右の矢印（< | >）
キーボードの左（◀️）および右（▶️）カーソルキー

アーキテクチャと設計

5 minutes

システムアーキテクチャ

JenkinsベースのSmart Agentデプロイシステムは、ハブ・アンド・スポーク型のアーキテクチャを採用しています。AWS VPC内のJenkinsエージェントがSSH経由で複数のターゲットホストへのデプロイを調整します。

全体アーキテクチャ

graph TB
    subgraph "Jenkins Infrastructure"
        JM[Jenkins Master<br/>Web UI + Orchestration]
        JA[Jenkins Agent<br/>EC2 in VPC<br/>Label: linux]
    end

    subgraph "AWS VPC - Private Network"
        subgraph "Target EC2 Instances"
            H1[Host 1<br/>172.31.1.243]
            H2[Host 2<br/>172.31.1.48]
            H3[Host 3<br/>172.31.1.5]
            HN[Host N<br/>172.31.x.x]
        end
    end

    DEV[Developer/Operator]
    APPD[AppDynamics<br/>Controller]

    DEV -->|1. Triggers Pipeline| JM
    JM -->|2. Assigns Job| JA
    JA -->|3. SSH Deploy<br/>Private IPs| H1
    JA -->|3. SSH Deploy<br/>Private IPs| H2
    JA -->|3. SSH Deploy<br/>Private IPs| H3
    JA -->|3. SSH Deploy<br/>Private IPs| HN

    H1 -.->|Metrics| APPD
    H2 -.->|Metrics| APPD
    H3 -.->|Metrics| APPD
    HN -.->|Metrics| APPD

    style JM fill:#d4e6f1
    style JA fill:#a9cce3
    style H1 fill:#aed6f1
    style H2 fill:#aed6f1
    style H3 fill:#aed6f1
    style HN fill:#aed6f1

ネットワークアーキテクチャ

すべてのインフラストラクチャは、共有セキュリティグループを持つ単一のAWS VPC内で稼働します。JenkinsエージェントはプライベートIP経由でターゲットホストと通信するため、ターゲットホストにパブリックIPアドレスは不要です。

VPC レイアウト

┌─────────────────────────────────────────────────────────────────┐
│                        AWS VPC (10.0.0.0/16)                    │
│  ┌───────────────────────────────────────────────────────────┐  │
│  │              Security Group: app-agents-sg                │  │
│  │  Rules:                                                   │  │
│  │  - Inbound: SSH (22) from Jenkins Agent only             │  │
│  │  - Outbound: HTTPS (443) to AppDynamics Controller       │  │
│  └───────────────────────────────────────────────────────────┘  │
│                                                                  │
│  ┌──────────────┐    ┌──────────────┐    ┌──────────────┐      │
│  │ Jenkins Agent│    │  Target EC2  │    │  Target EC2  │      │
│  │              │    │              │    │              │      │
│  │ Private IP:  │───▶│ Private IP:  │    │ Private IP:  │      │
│  │ 172.31.50.10 │SSH │ 172.31.1.243 │    │ 172.31.1.48  │      │
│  │              │───▶│              │    │              │      │
│  │ Label: linux │    │ Ubuntu 20.04 │    │ Ubuntu 20.04 │      │
│  └──────────────┘    └──────────────┘    └──────────────┘      │
│         │                    │                    │             │
│         │                    │                    │             │
│         └────────────────────┴────────────────────┘             │
│                              │                                  │
└──────────────────────────────┼──────────────────────────────────┘
                               │
                               ▼
                    ┌──────────────────┐
                    │   AppDynamics    │
                    │    Controller    │
                    │  (SaaS/On-Prem)  │
                    └──────────────────┘

デプロイフロー

完全なデプロイシーケンス

sequenceDiagram
    participant Dev as Developer
    participant JM as Jenkins Master
    participant JA as Jenkins Agent<br/>(VPC)
    participant TH as Target Hosts<br/>(VPC)
    participant AppD as AppDynamics<br/>Controller

    Dev->>JM: 1. Trigger Pipeline
    JM->>JM: 2. Load Credentials
    JM->>JA: 3. Schedule Job
    JA->>JA: 4. Prepare Batches

    loop For Each Batch
        JA->>TH: 5. SSH Copy Files (SCP)
        JA->>TH: 6. SSH Execute Commands
        TH->>TH: 7. Install/Config Agent
        TH-->>JA: 8. Return Status
    end

    JA->>JM: 9. Report Results
    JM->>Dev: 10. Show Build Status

    TH->>AppD: 11. Send Metrics (Post-Install)
    AppD-->>Dev: 12. View Monitoring Data

コンポーネントの詳細

Jenkins Master

役割:

ユーザー向けWeb UI
パイプラインのオーケストレーション
認証情報の管理
ビルド履歴とログ
ジョブのスケジューリング

要件:

Jenkins 2.300以降
プラグイン: Pipeline、SSH Agent、Credentials、Git
エージェントへのネットワークアクセス

Jenkins Agent

配置場所:

AWS VPC（ターゲットと同一）
プライベートネットワークアクセス

役割:

パイプラインステージの実行
ターゲットホストへのSSH接続
ファイル転送（SCP）
バッチ処理ロジック
エラー収集

要件:

ラベル: linux
Java 11以降
SSHクライアント
ネットワーク: すべてのターゲットへのSSH接続
ディスク: アーティファクト用に約20GB

ターゲットホスト

前提条件:

Ubuntu 20.04以降
SSHサーバーが稼働していること
sudoアクセス権を持つユーザー
SSH鍵が認証済みであること

デプロイ後:

/opt/appdynamics/
└── appdsmartagent/
    ├── smartagentctl
    ├── config.ini
    └── agents/
        ├── machine/
        ├── java/
        ├── node/
        └── db/

セキュリティアーキテクチャ

セキュリティレイヤー

AWS VPC 分離
- エージェント用のプライベートサブネット
- 直接のインターネットアクセスは不要
- VPCフローログの有効化
セキュリティグループ
- Jenkins AgentのIPをホワイトリスト登録
- ポート22（SSH）のみ
- ステートフルファイアウォールルール
SSH 鍵認証
- パスワード認証なし
- Jenkins認証情報に鍵を保存
- 一時鍵ファイル（600パーミッション）
- 各ビルド後に鍵を削除
Jenkins RBAC
- ロールベースのアクセス制御
- パイプラインレベルの権限
- 認証情報のアクセス制限
- 監査ログの有効化
シークレット管理
- コードやログにシークレットを含めない
- 認証情報のバインディングのみ
- 環境変数のマスキング
- 自動シークレットローテーション（オプション）

認証情報のフロー

flowchart LR
    subgraph "Jenkins Master"
        CS[Credentials Store<br/>Encrypted at Rest]
        JM[Jenkins Master]
    end

    subgraph "Jenkins Agent"
        WS[Workspace<br/>Temp Files]
        KEY[SSH Key File<br/>600 permissions]
    end

    subgraph "Target Hosts"
        TH[EC2 Instances<br/>Authorized Keys]
    end

    CS -->|Binding| JM
    JM -->|Secure Copy| KEY
    KEY -->|SSH Auth| TH
    WS -.->|Cleanup| X[Deleted]
    KEY -.->|Cleanup| X

    style CS fill:#fdeaa8
    style KEY fill:#fadbd8
    style X fill:#e8e8e8

バッチ処理

システムは自動バッチ処理を使用して、あらゆるスケールのデプロイに対応します。デフォルトでは、ホストは256台ずつのバッチで処理され、バッチ内のすべてのホストは並列でデプロイされます。

バッチ処理の仕組み

HOST LIST (1000 hosts)              BATCH_SIZE = 256

Host 001: 172.31.1.1                ┌──────────────────┐
Host 002: 172.31.1.2      ────────▶ │   BATCH 1        │
    ...                              │   Hosts 1-256    │ ───┐
Host 256: 172.31.1.256               │   Sequential     │    │
                                     └──────────────────┘    │
Host 257: 172.31.1.257               ┌──────────────────┐    │
Host 258: 172.31.1.258   ────────▶  │   BATCH 2        │    │ SEQUENTIAL
    ...                              │   Hosts 257-512  │    │ EXECUTION
Host 512: 172.31.1.512               │   Sequential     │    │
                                     └──────────────────┘    │
Host 513: 172.31.1.513               ┌──────────────────┐    │
    ...                              │   BATCH 3        │    │
Host 768: 172.31.1.768   ────────▶  │   Hosts 513-768  │ ───┘
                                     └──────────────────┘
Host 769: 172.31.1.769               ┌──────────────────┐
    ...                              │   BATCH 4        │
Host 1000: 172.31.2.232  ────────▶  │   Hosts 769-1000 │
                                     │   (232 hosts)    │
                                     └──────────────────┘

WITHIN EACH BATCH:
┌────────────────────────────────────────┐
│  All hosts deploy in PARALLEL          │
│                                        │
│  Host 1 ──┐                           │
│  Host 2 ──┤                           │
│  Host 3 ──┼─▶ Background processes (&)│
│    ...    │                           │
│  Host 256─┘   └─▶ wait command        │
└────────────────────────────────────────┘

スケーリング特性

デプロイ速度（デフォルト BATCH_SIZE=256）:

10台 → 1バッチ → 約2分
100台 → 1バッチ → 約3分
500台 → 2バッチ → 約6分
1,000台 → 4バッチ → 約12分
5,000台 → 20バッチ → 約60分

速度に影響する要因:

ネットワーク帯域幅（ホストあたり19MBのパッケージ）
SSH接続のオーバーヘッド（ホストあたり約1秒）
ターゲットホストのCPU/ディスク速度
Jenkinsエージェントのリソース

次のステップ

アーキテクチャを理解したところで、Jenkinsのセットアップと認証情報の設定に進みます。

Jenkins セットアップ

10 minutes

前提条件

開始する前に、以下を準備してください:

Jenkinsサーバー（バージョン2.300以降）
ターゲットEC2インスタンスと同じAWS VPC内のJenkinsエージェント
ターゲットホストへの認証用SSHキーペア
AppDynamics Smart Agentパッケージ
SSHアクセス可能なターゲットUbuntu EC2インスタンス

必要な Jenkins プラグイン

Manage Jenkins → Plugins → Available Plugins から以下のプラグインをインストールします:

Pipeline（コアプラグイン、通常はプリインストール済み）
SSH Agent Plugin
Credentials Plugin（通常はプリインストール済み）
Git Plugin（SCMを使用する場合）

インストール手順:

Manage Jenkins → Plugins に移動します
Available タブをクリックします
各プラグインを検索します
選択して Install をクリックします

Jenkins Agent の設定

JenkinsエージェントはプライベートIP経由でターゲットEC2インスタンスに到達できる必要があります。主に2つの方法があります:

オプション A: EC2 インスタンスをエージェントとして使用

ターゲットホストと 同じ VPC に EC2 インスタンスを起動 します

Java をインストール します（Jenkinsに必要）:

sudo apt-get update
sudo apt-get install -y openjdk-11-jdk

Jenkins にエージェントを追加 します:
- Manage Jenkins → Nodes → New Node に移動します
- 名前: aws-vpc-agent（または任意の名前）
- タイプ: Permanent Agent
- 設定:
  - Remote root directory: /home/ubuntu/jenkins
  - Labels: linux（パイプラインのエージェントラベルと一致させる必要があります）
  - Launch method: Launch agent via SSH
  - Host: EC2のプライベートIP
  - Credentials: エージェント用のSSH認証情報を追加

オプション B: 既存の Linux エージェントを使用

エージェントに linux ラベルが設定されていることを確認します
ターゲットホストへのネットワーク接続を確認します
SSHクライアントがインストールされていることを確認します

エージェントラベルの設定

警告

このワークショップのすべてのパイプラインは linux ラベルを使用します。エージェントにこのラベルが設定されていることを確認してください。

ラベルを設定または変更するには:

Manage Jenkins → Nodes に移動します
エージェントをクリックします
Configure をクリックします
Labels を linux に設定します
Save をクリックします

認証情報のセットアップ

Manage Jenkins → Credentials → System → Global credentials (unrestricted) に移動します。

パイプラインを動作させるために、3つの認証情報を作成する必要があります。

1. ターゲットホスト用 SSH 秘密鍵

この認証情報により、JenkinsがターゲットEC2インスタンスにSSH接続できるようになります。

Type: SSH Username with private key

ID: ssh-private-key（正確に一致させる必要があります）
Description: SSH key for EC2 target hosts
Username: ubuntu（または使用するSSHユーザー）
Private Key: 以下のいずれかを選択:
- Enter directly: PEMファイルの内容を貼り付け
- From file: PEMファイルをアップロード
- From Jenkins master: パスを指定

フォーマット例:

-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEA...
...
-----END RSA PRIVATE KEY-----

2. デプロイ対象ホストリスト

この認証情報には、Smart Agentをデプロイするすべてのターゲットホストのリストが含まれます。

Type: Secret text

ID: deployment-hosts（正確に一致させる必要があります）
Description: List of target EC2 host IPs
Secret: 改行区切りのIPアドレスを入力

例:

172.31.1.243
172.31.1.48
172.31.1.5
172.31.10.20
172.31.10.21

重要

フォーマット要件:

1行に1つのIPアドレス
カンマなし
スペースなし
余分な文字なし
Unix改行コード（LF、CRLFではない）を使用

3. AppDynamics アカウントアクセスキー

この認証情報には、Smart Agentの認証に使用するAppDynamicsアカウントアクセスキーが含まれます。

Type: Secret text

ID: account-access-key（正確に一致させる必要があります）
Description: AppDynamics account access key
Secret: AppDynamicsのアクセスキー

例: abcd1234-ef56-7890-gh12-ijklmnopqrst

ヒント

AppDynamicsのアクセスキーは、Controllerの Settings → License → Account で確認できます。

認証情報のセキュリティベストプラクティス

認証情報管理のベストプラクティスに従ってください:

Jenkinsの認証情報暗号化を使用する（組み込み機能）
Jenkinsのロールベース認可でアクセスを制限する
SSH鍵を定期的にローテーションする
EC2インスタンスに最小権限のIAMロールを使用する
認証情報アクセスの監査ログを有効にする
認証情報をバージョン管理にコミットしない

Smart Agent パッケージのセットアップ

Smart AgentのZIPファイルは、Jenkinsからアクセス可能な場所に配置する必要があります。推奨される方法は、Jenkinsのホームディレクトリに保存することです。

Smart Agent のダウンロード

# AppDynamics からダウンロード
curl -o appdsmartagent_64_linux.zip \
  "https://download.appdynamics.com/download/prox/download-file/smart-agent/latest/appdsmartagent_64_linux.zip"

# ダウンロードを確認
ls -lh appdsmartagent_64_linux.zip

保存場所

パイプラインはSmart Agent ZIPを /var/jenkins_home/smartagent/appdsmartagent.zip で参照します。

以下のいずれかの方法で対応できます:

この場所にZIPファイルを正確に配置する
パイプラインパラメータ SMARTAGENT_ZIP_PATH をZIPファイルの場所に変更する

設定の確認

パイプライン作成に進む前に、セットアップを確認します:

1. エージェントの状態確認

Manage Jenkins → Nodes に移動します
エージェントが「online」と表示されていることを確認します
ラベルが linux に設定されていることを確認します

2. SSH 接続のテスト

SSHが動作することを確認するための簡単なテストパイプラインを作成します:

pipeline {
    agent { label 'linux' }
    stages {
        stage('Test SSH') {
            steps {
                withCredentials([
                    sshUserPrivateKey(credentialsId: 'ssh-private-key',
                                     keyFileVariable: 'SSH_KEY',
                                     usernameVariable: 'SSH_USER'),
                    string(credentialsId: 'deployment-hosts', variable: 'HOSTS')
                ]) {
                    sh '''
                        echo "Testing SSH credentials..."
                        echo "$HOSTS" | head -1 | while read HOST; do
                            ssh -i $SSH_KEY \
                                -o StrictHostKeyChecking=no \
                                -o ConnectTimeout=10 \
                                $SSH_USER@$HOST \
                                "echo 'Connection successful'"
                        done
                    '''
                }
            }
        }
    }
}

3. 認証情報の存在確認

Manage Jenkins → Credentials に移動します
以下の3つの認証情報がリストに表示されていることを確認します:
- ssh-private-key
- deployment-hosts
- account-access-key

よくある問題のトラブルシューティング

エージェントが利用できない

症状: パイプライン実行時に「No agent available」エラーが発生する

解決策:

Manage Jenkins → Nodes を確認します
エージェントがオンラインであることを確認します
エージェントに linux ラベルがあることを確認します
エージェントの接続をテストします

SSH 接続の失敗

症状: SSH経由でターゲットホストに接続できない

解決策:

# Jenkins エージェントマシンからテスト
ssh -i /path/to/key ubuntu@172.31.1.243 -o ConnectTimeout=10

# セキュリティグループがエージェントからの SSH を許可していることを確認
# 秘密鍵がターゲットの公開鍵と一致していることを確認

認証情報が見つからない

症状:「Credential not found」エラーが発生する

解決策:

認証情報のIDが正確に一致していることを確認します:
- ssh-private-key
- deployment-hosts
- account-access-key
認証情報のスコープが Global に設定されていることを確認します

ターゲットホストでの権限拒否

症状: SSHは成功するがコマンドが権限拒否で失敗する

解決策:

# ターゲットホストで、ユーザーが sudoers に含まれていることを確認
sudo visudo
# 以下の行を追加:
ubuntu ALL=(ALL) NOPASSWD: ALL

次のステップ

Jenkinsの認証情報とエージェントの設定が完了したら、デプロイパイプラインの作成に進みます。

パイプライン作成

10 minutes

概要

GitHubリポジトリには、Smart Agentのライフサイクル管理のための4つのメインパイプラインが含まれています:

Deploy Smart Agent - Smart Agentサービスのインストールと起動
Install Machine Agent - smartagentctlによるMachine Agentのインストール
Install Database Agent - smartagentctlによるDatabase Agentのインストール
Cleanup All Agents - /opt/appdynamicsディレクトリの削除

すべてのパイプラインコードは sm-jenkins GitHub リポジトリで公開されています。

パイプラインファイル

リポジトリには以下のJenkinsfileパイプライン定義が含まれています:

sm-jenkins/
└── pipelines/
    ├── Jenkinsfile.deploy                  # Deploy Smart Agent
    ├── Jenkinsfile.install-machine-agent  # Install Machine Agent
    ├── Jenkinsfile.install-db-agent       # Install Database Agent
    └── Jenkinsfile.cleanup                # Cleanup All Agents

Jenkins でのパイプライン作成

使用したい各Jenkinsfileに対して、以下の手順でJenkinsにパイプラインを作成します。

方法1: SCM からのパイプライン（推奨）

この方法では、パイプラインコードをバージョン管理に保持し、変更を自動的に同期します。

ステップ1: リポジトリのフォークまたはクローン

まず、リポジトリを自分のGitHubアカウントまたは組織にフォークするか、元のリポジトリを直接使用します。

リポジトリ URL: https://github.com/chambear2809/sm-jenkins

ステップ2: Jenkins でパイプラインを作成

Jenkins Dashboard に移動します
New Item をクリックします
アイテム名を入力します（例: Deploy-Smart-Agent）
Pipeline を選択します
OK をクリックします

ステップ3: パイプラインの設定

パイプライン設定ページで以下を設定します:

General セクション:

Description: Deploys AppDynamics Smart Agent to multiple hosts
Discard old builds はチェックしないままにします（または必要に応じて設定）

Build Triggers:

手動実行のみの場合はチェックしないままにします
必要に応じてWebhookやポーリングを設定します

Pipeline セクション:

Definition: Pipeline script from SCM を選択します
SCM: Git を選択します
Repository URL: https://github.com/chambear2809/sm-jenkins
Credentials: プライベートリポジトリの場合は追加します
Branch Specifier: */main（または */master）
Script Path: pipelines/Jenkinsfile.deploy

ステップ4: 保存

Save をクリックしてパイプラインを作成します。

ステップ5: 他のパイプラインでも繰り返す

作成したい各パイプラインに対して、適切なスクリプトパスを使用してステップ2-4を繰り返します:

パイプライン名	スクリプトパス
Deploy-Smart-Agent	`pipelines/Jenkinsfile.deploy`
Install-Machine-Agent	`pipelines/Jenkinsfile.install-machine-agent`
Install-Database-Agent	`pipelines/Jenkinsfile.install-db-agent`
Cleanup-All-Agents	`pipelines/Jenkinsfile.cleanup`

方法2: パイプラインスクリプトの直接入力

または、Jenkinsfileの内容をJenkinsに直接コピーすることもできます。

New Item を作成 します（方法1と同様）
Pipeline セクションで:
- Definition: Pipeline script を選択します
- Script: GitHubからJenkinsfileの内容全体をコピー/ペーストします
Save をクリックします

ヒント

方法1（SCM）を推奨します。パイプラインをバージョン管理に保持でき、更新が容易になります。

パイプラインパラメータ

各パイプラインは設定可能なパラメータを受け付けます。メインデプロイパイプラインの主要なパラメータを以下に示します:

Deploy Smart Agent パイプラインのパラメータ

パラメータ	デフォルト値	説明
`SMARTAGENT_ZIP_PATH`	`/var/jenkins_home/smartagent/appdsmartagent.zip`	Jenkins サーバー上の Smart Agent ZIP のパス
`REMOTE_INSTALL_DIR`	`/opt/appdynamics/appdsmartagent`	ターゲットホストのインストールディレクトリ
`APPD_USER`	`ubuntu`	Smart Agent プロセスを実行するユーザー
`APPD_GROUP`	`ubuntu`	Smart Agent プロセスを実行するグループ
`SSH_PORT`	`22`	リモートホストの SSH ポート
`AGENT_NAME`	`smartagent`	Smart Agent 名
`LOG_LEVEL`	`DEBUG`	ログレベル（DEBUG、INFO、WARN、ERROR）

Cleanup パイプラインのパラメータ

パラメータ	デフォルト値	説明
`REMOTE_INSTALL_DIR`	`/opt/appdynamics/appdsmartagent`	削除するディレクトリ
`SSH_PORT`	`22`	リモートホストの SSH ポート
`CONFIRM_CLEANUP`	`false`	クリーンアップを実行するにはチェックが必要

警告

Cleanupパイプラインには、誤って削除することを防ぐための確認パラメータがあります。クリーンアップを実行するには CONFIRM_CLEANUP にチェックを入れる必要があります。

パイプライン構造の理解

デプロイパイプラインの主要なコンポーネントを見ていきます:

1. エージェント宣言

agent { label 'linux' }

これにより、パイプラインが linux ラベルを持つJenkinsエージェントで実行されることが保証されます。

2. パラメータブロック

parameters {
    string(name: 'SMARTAGENT_ZIP_PATH', ...)
    string(name: 'REMOTE_INSTALL_DIR', ...)
    // ... その他のパラメータ
}

ビルドをトリガーする際に設定できるパラメータを定義します。

3. ステージ

デプロイパイプラインには以下のステージがあります:

Preparation - 認証情報からターゲットホストを読み込み
Extract Smart Agent - ZIPファイルをステージングディレクトリに展開
Configure Smart Agent - config.iniテンプレートを作成
Deploy to Remote Hosts - 各ホストにファイルをコピーしSmart Agentを起動
Verify Installation - すべてのホストでSmart Agentの状態を確認

4. 認証情報バインディング

withCredentials([
    sshUserPrivateKey(credentialsId: 'ssh-private-key', ...),
    string(credentialsId: 'account-access-key', ...)
]) {
    // 認証情報にアクセスできるパイプラインコード
}

ログに公開することなく、安全に認証情報を読み込みます。

5. Post アクション

post {
    success { ... }
    failure { ... }
    always { ... }
}

パイプライン完了後に、成功・失敗に関わらず実行するアクションを定義します。

パイプラインの命名規則

明確さと整理のために、一貫した命名規則を使用します:

推奨名称:

01-Deploy-Smart-Agent
02-Install-Machine-Agent
03-Install-Database-Agent
04-Cleanup-All-Agents

数字のプレフィックスにより、Jenkinsダッシュボードで論理的な順序を維持できます。

フォルダーによるパイプラインの整理

より良い整理のために、Jenkinsフォルダーを使用できます:

フォルダーを作成:
- New Item をクリックします
- 名前を入力します: AppDynamics Smart Agent
- Folder を選択します
- OK をクリックします
フォルダー内にパイプラインを作成:
- フォルダーに入ります
- 上記の手順でパイプラインを作成します

構成例:

AppDynamics Smart Agent/
├── Deployment/
│   └── 01-Deploy-Smart-Agent
├── Agent Installation/
│   ├── 02-Install-Machine-Agent
│   └── 03-Install-Database-Agent
└── Cleanup/
    └── 04-Cleanup-All-Agents

パイプラインコードの表示

完全なパイプラインコードはGitHubリポジトリで確認できます:

メインデプロイパイプライン: https://github.com/chambear2809/sm-jenkins/blob/main/pipelines/Jenkinsfile.deploy

その他のパイプライン:

パイプライン設定のテスト

本番デプロイを実行する前に、パイプライン設定をテストします:

1. 単一ホストでのドライラン

IPが1つだけのテスト認証情報 deployment-hosts-test を作成します
パイプラインをこの認証情報を使用するよう一時的に変更します
パイプラインを実行し、単一ホストで動作することを確認します
確認後、完全なホストリストに更新します

2. 構文チェック

Jenkinsには組み込みの構文バリデーターがあります:

パイプラインに移動します
Pipeline Syntax リンクをクリックします
Declarative Directive Generator を使用して構文を検証します

次のステップ

パイプラインが作成できたら、最初のSmart Agentデプロイを実行する準備が整いました。

デプロイワークフロー

15 minutes

初回デプロイ

パイプラインの設定が完了したので、最初のSmart Agentデプロイを実行してみましょう。

ステップ1: パイプラインに移動

Jenkins Dashboard に移動します
Deploy-Smart-Agent パイプラインをクリックします

ステップ2: パラメータを指定してビルド

左サイドバーの Build with Parameters をクリックします
デフォルトパラメータを確認します:
- SMARTAGENT_ZIP_PATH: パスが正しいことを確認します
- REMOTE_INSTALL_DIR: /opt/appdynamics/appdsmartagent
- APPD_USER: ubuntu（または使用するSSHユーザー）
- APPD_GROUP: ubuntu
- SSH_PORT: 22
- AGENT_NAME: smartagent
- LOG_LEVEL: DEBUG
必要に応じてパラメータを調整します
Build をクリックします

ヒント

初回デプロイでは、IPアドレスが1つだけの別の認証情報を作成して、単一ホストでテストすることを検討してください。

ステップ3: パイプラインの実行を監視

Build をクリックすると、以下が表示されます:

Build added to queue - Build Historyにビルド番号が表示されます
ビルド番号をクリック します（例: #1）
Console Output をクリックしてリアルタイムのログを表示します

ステップ4: コンソール出力の理解

コンソール出力にはデプロイの各ステージが表示されます:

Started by user admin
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Running on aws-vpc-agent in /home/ubuntu/jenkins/workspace/Deploy-Smart-Agent
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Preparation)
[Pipeline] script
[Pipeline] {
Preparing Smart Agent deployment to 3 hosts: 172.31.1.243, 172.31.1.48, 172.31.1.5
...

表示される主要なステージ:

Preparation - ホストリストの読み込みと検証
Extract Smart Agent - ZIPファイルの展開
Configure Smart Agent - config.iniの作成
Deploy to Remote Hosts - 各ホストへのデプロイ
Verify Installation - Smart Agentの状態確認

ステップ5: 結果の確認

完了後、以下のいずれかが表示されます:

成功:

Smart Agent successfully deployed to all hosts
Finished: SUCCESS

部分的な成功:

Deployment completed with some failures
Failed hosts: 172.31.1.48
Finished: UNSTABLE

失敗:

Smart Agent deployment failed. Check logs for details.
Finished: FAILURE

インストールの検証

デプロイが成功したら、ターゲットホストでSmart Agentが稼働していることを確認します。

Smart Agent の状態確認

ターゲットホストにSSH接続して状態を確認します:

# ターゲットホストに SSH 接続
ssh ubuntu@172.31.1.243

# インストールディレクトリに移動
cd /opt/appdynamics/appdsmartagent

# Smart Agent の状態を確認
sudo ./smartagentctl status

期待される出力:

Smart Agent is running (PID: 12345)
Service: appdsmartagent.service
Status: active (running)

インストール済みエージェントの一覧表示

cd /opt/appdynamics/appdsmartagent
sudo ./smartagentctl list

期待される出力:

No agents currently installed
(Use install-machine-agent or install-db-agent pipelines to add agents)

ログの確認

cd /opt/appdynamics/appdsmartagent
tail -f log.log

AppDynamics Controllerへの接続成功メッセージを確認します。

AppDynamics Controller での確認

AppDynamics Controllerにログインします
Servers → Servers に移動します
新しくデプロイされたホストを探します
Smart AgentがMetricをレポートしていることを確認します

追加エージェントのインストール

Smart Agentがデプロイされたら、他のパイプラインを使用して特定のエージェントタイプをインストールできます。

Machine Agent のインストール

Install-Machine-Agent パイプラインに移動します
Build with Parameters をクリックします
パラメータを確認します:
- AGENT_NAME: machine-agent
- SSH_PORT: 22
Build をクリックします

パイプラインは各ホストにSSH接続して以下を実行します:

cd /opt/appdynamics/appdsmartagent
sudo ./smartagentctl install --component machine

Database Agent のインストール

Install-Database-Agent パイプラインに移動します
Build with Parameters をクリックします
データベース接続パラメータを設定します
Build をクリックします

パイプラインはすべてのホストにDatabase Agentをインストールして設定します。

エージェントインストールの確認

エージェントのインストール後、表示されることを確認します:

cd /opt/appdynamics/appdsmartagent
sudo ./smartagentctl list

期待される出力:

Installed agents:
- machine-agent (running)
- db-agent (running)

一般的なデプロイシナリオ

シナリオ1: 初回デプロイ

ワークフロー:

Deploy-Smart-Agent パイプラインを実行します
完了を待って検証します
必要に応じて Install-Machine-Agent を実行します
必要に応じて Install-Database-Agent を実行します

シナリオ2: Smart Agent のアップデート

Smart Agentを新しいバージョンにアップデートするには:

新しいSmart Agent ZIPをダウンロードします
設定済みのパスにJenkinsに配置します
Deploy-Smart-Agent パイプラインを再度実行します

パイプラインは自動的に以下を行います:

既存のSmart Agentを停止
古いファイルを削除
新しいバージョンをインストール
Smart Agentを再起動

シナリオ3: 新しいホストの追加

Smart Agentを新しいホストに追加するには:

Jenkinsの deployment-hosts 認証情報を更新します
新しいIPアドレスを追加します（1行に1つ）
Deploy-Smart-Agent パイプラインを実行します

パイプラインは以下を行います:

設定済みのホストをスキップします（冪等性がある場合）
新しいホストにのみデプロイします

シナリオ4: 完全な削除

すべてのホストからSmart Agentを完全に削除するには:

Cleanup-All-Agents パイプラインに移動します
Build with Parameters をクリックします
CONFIRM_CLEANUP チェックボックスに チェックを入れます
Build をクリックします

これにより、すべてのホストから /opt/appdynamics/appdsmartagent ディレクトリが完全に削除されます。この操作は元に戻せません。

デプロイのトラブルシューティング

Preparation ステージでビルドが失敗する

症状: ホストリストの読み込み時にパイプラインが失敗する

原因: deployment-hosts 認証情報が見つからないか、正しくない

解決策:

Manage Jenkins → Credentials に移動します
deployment-hosts 認証情報が存在することを確認します
フォーマットを確認します（1行に1つのIP、カンマなし）
末尾にスペースがないことを確認します

SSH 接続の失敗

症状:「Permission denied」または「Connection refused」エラーが発生する

解決策:

セキュリティグループの確認:

# Jenkins エージェントからターゲットに到達できることを確認
ping 172.31.1.243
telnet 172.31.1.243 22

SSH の手動テスト:

# Jenkins エージェントマシンから
ssh -i /path/to/key ubuntu@172.31.1.243

SSH 鍵の確認:

ssh-private-key 認証情報が正しいことを確認します
ターゲットホストの ~/.ssh/authorized_keys に公開鍵があることを確認します

Smart Agent が起動しない

症状: デプロイは完了するがSmart Agentが稼働していない

解決策:

ターゲットホストのログを確認:

cd /opt/appdynamics/appdsmartagent
cat log.log

よくある問題:

無効なアクセスキー: account-access-key 認証情報を確認します
ネットワーク接続: Controllerへの送信HTTPS接続を確認します
権限の問題: APPD_USERに正しい権限があることを確認します

デプロイの部分的な成功

症状: 一部のホストは成功するが、他のホストは失敗する

解決策:

Console Output を確認 します - どのホストが失敗したかを特定します
失敗したホストを調査 します - SSHで接続して手動でテストします
パイプラインを再実行 します - Jenkinsがリトライが必要なホストを追跡します

パイプラインのベストプラクティス

1. まず単一ホストでテスト

本番環境にデプロイする前に、必ず単一ホストで新しい設定をテストします:

1. deployment-hosts-test 認証情報を作成（IP 1つ）
2. この認証情報を使用するテストパイプラインを作成
3. 成功を確認
4. 完全なホストリストにデプロイ

2. 説明的なビルド説明を使用

ビルドをトリガーした後、説明を追加します:

ビルドページに移動します
Edit Build Information をクリックします
説明を追加します:「本番環境デプロイ - 2024年第4四半期」

3. ビルド履歴の監視

ビルド履歴を定期的にチェックしてパターンを確認します:

失敗したビルド
所要時間の傾向
エラーメッセージ

4. メンテナンスウィンドウ中にデプロイをスケジュール

本番システムの場合:

Jenkinsのスケジュールビルドを使用します
トラフィックの少ない時間帯にデプロイします
ロールバック計画を準備しておきます

5. 認証情報を最新に保つ

SSH鍵を四半期ごとにローテーションします
インフラストラクチャの変更に合わせてホストリストを更新します
AppDynamicsアクセスキーの有効性を確認します

次のステップ

大規模デプロイのスケーリングと運用上の考慮事項について見ていきましょう。

GitHub Actions による自動化

2 minutes

はじめに

このワークショップでは、セルフホストランナーを使用した GitHub Actions で、複数のEC2インスタンスにわたる AppDynamics Smart Agent のデプロイとライフサイクル管理を自動化する方法を紹介します。10台のホストでも10,000台のホストでも、このガイドではスケーラブルで安全かつ再現可能なSmart Agent運用のためにGitHub Actionsワークフローを活用する方法を説明します。

学習内容

このワークショップでは、以下の内容を学びます:

GitHub Actionsワークフローを使用して複数のホストに Smart Agent をデプロイ する
安全な認証情報管理のために GitHub Secrets と Variables を設定 する
AWS VPC内に セルフホストランナーをセットアップ する
数千台のホストにスケールするための 自動バッチ処理を実装 する
インストール、アンインストール、停止、クリーンアップなど エージェントの完全なライフサイクルを管理 する
ワークフローの実行を監視 し、問題をトラブルシューティングする

主な機能

並列デプロイ - 複数のホストに同時にデプロイ
完全なライフサイクル管理 - エージェントのすべての操作をカバーする11のワークフロー
Infrastructure as Code - すべてのワークフローをGitHubでバージョン管理
セキュア - SSH鍵はGitHub Secretsに保存、プライベートVPCネットワーキング
大規模スケーラブル - 自動バッチ処理で数千台のホストにデプロイ
セルフホストランナー - AWS VPC内で実行

アーキテクチャ概要

┌─────────────────────────────────────────────────────────────────┐
│                  GitHub Actions-based Deployment                 │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  Developer ──▶ GitHub.com ──▶ Self-hosted Runner (AWS VPC)     │
│                                          │                       │
│                                          ├──▶ Host 1 (SSH)      │
│                                          ├──▶ Host 2 (SSH)      │
│                                          ├──▶ Host 3 (SSH)      │
│                                          └──▶ Host N (SSH)      │
│                                                                  │
│  All hosts send metrics ──▶ AppDynamics Controller             │
└─────────────────────────────────────────────────────────────────┘

ワークショップの構成

このワークショップは以下の内容で構成されています:

アーキテクチャと設計 - GitHub Actionsワークフローアーキテクチャの理解
GitHub のセットアップ - Secrets、Variables、セルフホストランナーの設定
ワークフローの作成 - 11の利用可能なワークフローの理解と使用
デプロイの実行 - ワークフローの実行とインストールの検証

利用可能なワークフロー

このソリューションには、Smart Agentの完全なライフサイクル管理のための 11のワークフロー が含まれています:

カテゴリ	ワークフロー数	説明
デプロイ	1	Smart Agent のデプロイと起動
エージェントのインストール	4	Node、Machine、DB、Java エージェントのインストール
エージェントのアンインストール	4	特定のエージェントタイプのアンインストール
エージェント管理	2	停止/クリーンおよび完全なクリーンアップ

すべてのワークフローはスケーラビリティのための自動バッチ処理をサポートしています。

前提条件

リポジトリアクセス権を持つGitHubアカウント
Ubuntu EC2インスタンスを持つAWS VPC
同じVPC内のセルフホストGitHub Actionsランナー
認証用のSSHキーペア
AppDynamics Smart Agentパッケージ

GitHub リポジトリ

すべてのワークフローコードと設定ファイルはGitHubリポジトリで利用できます:

https://github.com/chambear2809/github-actions-lab

リポジトリには以下が含まれています:

11の完全なワークフロー YAMLファイル
詳細なセットアップドキュメント
アーキテクチャ図
トラブルシューティングガイド

ヒント

このワークショップを最も簡単にナビゲートするには、以下を使用します:

このページの右上にある左右の矢印（< | >）
キーボードの左（◀️）および右（▶️）カーソルキー

アーキテクチャと設計

5 minutes

システムアーキテクチャ

GitHub ActionsベースのSmart Agentデプロイシステムは、AWS VPC内のセルフホストランナーを使用して、SSH経由で複数のターゲットホストへのデプロイを調整します。

ハイレベルアーキテクチャ

graph TB
    subgraph Internet
        GH[GitHub.com<br/>Repository & Actions]
        User[Developer<br/>Local Machine]
    end

    subgraph AWS["AWS VPC (172.31.0.0/16)"]
        subgraph SG["Security Group: smartagent-lab"]
            Runner[Self-hosted Runner<br/>EC2 Instance<br/>172.31.1.x]

            subgraph Targets["Target Hosts"]
                T1[Target Host 1<br/>Ubuntu EC2<br/>172.31.1.243]
                T2[Target Host 2<br/>Ubuntu EC2<br/>172.31.1.48]
                T3[Target Host 3<br/>Ubuntu EC2<br/>172.31.1.5]
            end
        end
    end

    User -->|git push| GH
    GH <-->|HTTPS:443<br/>Poll for jobs| Runner
    Runner -->|SSH:22<br/>Private IPs| T1
    Runner -->|SSH:22<br/>Private IPs| T2
    Runner -->|SSH:22<br/>Private IPs| T3

    style GH fill:#24292e,color:#fff
    style User fill:#0366d6,color:#fff
    style Runner fill:#28a745,color:#fff
    style T1 fill:#ffd33d,color:#000
    style T2 fill:#ffd33d,color:#000
    style T3 fill:#ffd33d,color:#000

ネットワークアーキテクチャ

すべてのインフラストラクチャは、共有セキュリティグループを持つ単一のAWS VPC内で動作します。セルフホストランナーはプライベートIP経由でターゲットホストと通信します。

VPC レイアウト

┌─────────────────────────────────────────────────────────────────┐
│                        AWS VPC (172.31.0.0/16)                  │
│  ┌───────────────────────────────────────────────────────────┐  │
│  │          Security Group: smartagent-lab                   │  │
│  │  Rules:                                                   │  │
│  │  - Inbound: SSH (22) from same security group            │  │
│  │  - Outbound: HTTPS (443) to GitHub                       │  │
│  └───────────────────────────────────────────────────────────┘  │
│                                                                  │
│  ┌─────────────┐    ┌──────────────┐    ┌──────────────┐       │
│  │ Self-hosted │    │  Target EC2  │    │  Target EC2  │       │
│  │   Runner    │    │              │    │              │       │
│  │             │───▶│ Private IP:  │    │ Private IP:  │       │
│  │ 172.31.1.x  │SSH │ 172.31.1.243 │    │ 172.31.1.48  │       │
│  │             │───▶│              │    │              │       │
│  │ Polls GitHub│    │ Ubuntu 20.04 │    │ Ubuntu 20.04 │       │
│  └─────────────┘    └──────────────┘    └──────────────┘       │
│         │                    │                    │             │
│         │                    │                    │             │
│         └────────────────────┴────────────────────┘             │
│                              │                                  │
└──────────────────────────────┼──────────────────────────────────┘
                               │
                               ▼
                    ┌──────────────────┐
                    │   AppDynamics    │
                    │    Controller    │
                    │  (SaaS/On-Prem)  │
                    └──────────────────┘

ワークフロー実行フロー

完全なデプロイシーケンス

sequenceDiagram
    participant Dev as Developer
    participant GH as GitHub
    participant Runner as Self-hosted Runner
    participant Target as Target Host(s)

    Dev->>GH: 1. Push code or trigger workflow
    GH->>GH: 2. Workflow event triggered
    Runner->>GH: 3. Poll for jobs (HTTPS:443)
    GH->>Runner: 4. Assign job to runner
    Runner->>Runner: 5. Execute prepare job<br/>(load host matrix)

    par Parallel Execution
        Runner->>Target: 6a. SSH to Host 1<br/>(port 22)
        Runner->>Target: 6b. SSH to Host 2<br/>(port 22)
        Runner->>Target: 6c. SSH to Host 3<br/>(port 22)
    end

    Target->>Target: 7. Execute commands<br/>(install/uninstall/stop/clean)
    Target-->>Runner: 8. Return results
    Runner-->>GH: 9. Report job status
    GH-->>Dev: 10. Notify completion

コンポーネントの詳細

GitHub リポジトリ

格納内容:

11のワークフロー YAMLファイル
Smart Agentインストールパッケージ
設定ファイル（config.ini）

Secrets:

SSH秘密鍵

Variables:

ホストリスト（DEPLOYMENT_HOSTS）
ユーザー/グループ設定（オプション）

セルフホストランナー

配置場所:

AWS VPC（ターゲットと同じ）
プライベートネットワークアクセス

責務:

GitHubからワークフロージョブをポーリング
ワークフローステップの実行
ターゲットホストへのSSH接続
ファイル転送（SCP）
並列実行
エラー収集

要件:

Ubuntu/Amazon Linux 2
GitHubへの送信HTTPS（443）
ターゲットホストへの送信SSH（22）
SSHキー認証

アクセス:

GitHubへの送信HTTPS（443）
ターゲットホストへの送信SSH（22）
SSHキー認証を使用

ターゲットホスト

前提条件:

Ubuntu 20.04+
SSHサーバーが稼働中
sudoアクセス権を持つユーザー
認証済みSSHキー

デプロイ後:

/opt/appdynamics/
└── appdsmartagent/
    ├── smartagentctl
    ├── config.ini
    └── agents/
        ├── machine/
        ├── java/
        ├── node/
        └── db/

セキュリティアーキテクチャ

セキュリティレイヤー

AWS VPC の分離
- ホスト用のプライベートサブネット
- 直接のインターネットアクセスは不要
- VPCフローログを有効化
セキュリティグループ
- 同じセキュリティグループ内のみSSH（22）
- GitHubアクセス用の送信HTTPS（443）
- ステートフルファイアウォールルール
SSH キー認証
- パスワード認証なし
- キーはGitHub Secretsに保存
- ランナー上の一時キーファイル
- ワークフロー完了後にキーを削除
GitHub セキュリティ
- リポジトリアクセス制御
- ブランチ保護ルール
- Secretsはログに公開されない
- 環境変数のマスキング
ネットワークセキュリティ
- プライベートIP通信のみ
- パブリックIPは不要
- ランナーはターゲットと同じVPC内

ワークフローカテゴリ

システムには4つのカテゴリに分類された11のワークフローが含まれています:

GitHub Actions Workflows (11 Total)
├── Deployment (1 workflow)
│   └── Deploy Smart Agent (Batched)
├── Agent Installation (4 workflows)
│   ├── Install Node Agent (Batched)
│   ├── Install Machine Agent (Batched)
│   ├── Install DB Agent (Batched)
│   └── Install Java Agent (Batched)
├── Agent Uninstallation (4 workflows)
│   ├── Uninstall Node Agent (Batched)
│   ├── Uninstall Machine Agent (Batched)
│   ├── Uninstall DB Agent (Batched)
│   └── Uninstall Java Agent (Batched)
└── Smart Agent Management (2 workflows)
    ├── Stop and Clean Smart Agent (Batched)
    └── Cleanup All Agents (Batched)

バッチ処理戦略

すべてのワークフローは、あらゆるスケールのデプロイをサポートするために自動バッチ処理を使用します。

バッチ処理の仕組み

HOST LIST (1000 hosts)              BATCH_SIZE = 256

Host 001: 172.31.1.1                ┌──────────────────┐
Host 002: 172.31.1.2      ────────▶ │   BATCH 1        │
    ...                              │   Hosts 1-256    │ ───┐
Host 256: 172.31.1.256               │   Sequential     │    │
                                     └──────────────────┘    │
Host 257: 172.31.1.257               ┌──────────────────┐    │
Host 258: 172.31.1.258   ────────▶  │   BATCH 2        │    │ SEQUENTIAL
    ...                              │   Hosts 257-512  │    │ EXECUTION
Host 512: 172.31.1.512               │   Sequential     │    │
                                     └──────────────────┘    │
Host 513: 172.31.1.513               ┌──────────────────┐    │
    ...                              │   BATCH 3        │    │
Host 768: 172.31.1.768   ────────▶  │   Hosts 513-768  │ ───┘
                                     └──────────────────┘
Host 769: 172.31.1.769               ┌──────────────────┐
    ...                              │   BATCH 4        │
Host 1000: 172.31.2.232  ────────▶  │   Hosts 769-1000 │
                                     │   (232 hosts)    │
                                     └──────────────────┘

WITHIN EACH BATCH:
┌────────────────────────────────────────┐
│  All hosts deploy in PARALLEL          │
│                                        │
│  Host 1 ──┐                           │
│  Host 2 ──┤                           │
│  Host 3 ──┼─▶ Background processes (&)│
│    ...    │                           │
│  Host 256─┘   └─▶ wait command        │
└────────────────────────────────────────┘

シーケンシャルバッチの理由

リソース管理:

セルフホストランナーの過負荷を防止
各バッチは256の並列SSH接続を開く
シーケンシャル処理により安定したパフォーマンスを確保

設定変更可能:

デフォルトバッチサイズ: 256（GitHub Actionsのマトリックス制限）
ワークフロー入力でより小さなバッチに調整可能
速度とリソース使用量のバランスを調整

スケーリング特性

デプロイ速度（デフォルト BATCH_SIZE=256）:

10台のホスト → 1バッチ → 約2分
100台のホスト → 1バッチ → 約3分
500台のホスト → 2バッチ → 約6分
1,000台のホスト → 4バッチ → 約12分
5,000台のホスト → 20バッチ → 約60分

速度に影響する要因:

ネットワーク帯域幅（ホストあたり19MBのパッケージ）
SSH接続のオーバーヘッド（ホストあたり約1秒）
ターゲットホストのCPU/ディスク速度
ランナーのリソース（CPU/メモリ）

次のステップ

アーキテクチャを理解したところで、GitHubのセットアップとセルフホストランナーの設定に進みましょう。

GitHub のセットアップ

10 minutes

前提条件

開始する前に、以下を確認します:

リポジトリアクセス権を持つGitHubアカウント
Ubuntu EC2インスタンスを持つAWS VPC
ターゲットホストへの認証用SSHキーペア（PEMファイル）
AppDynamics Smart Agentパッケージ
SSHアクセス可能なターゲットUbuntu EC2インスタンス

リポジトリのフォークまたはクローン

まず、GitHub Actionsラボリポジトリへのアクセスを取得します。

リポジトリ URL: https://github.com/chambear2809/github-actions-lab

# Option 1: Fork the repository via GitHub UI
# Go to https://github.com/chambear2809/github-actions-lab
# Click "Fork" button

# Option 2: Clone directly (for testing)
git clone https://github.com/chambear2809/github-actions-lab.git
cd github-actions-lab

セルフホストランナーの設定

セルフホストランナーは、ターゲットEC2インスタンスと同じAWS VPCにデプロイする必要があります。

EC2 インスタンスへのランナーのインストール

VPC内で EC2 インスタンスを起動 します（UbuntuまたはAmazon Linux 2）
フォークしたリポジトリの ランナー設定に移動 します:
```
Settings → Actions → Runners → New self-hosted runner
```
ランナーインスタンスに SSH 接続 し、インストールコマンドを実行します:

# Create runner directory
mkdir actions-runner && cd actions-runner

# Download runner (check GitHub for latest version)
curl -o actions-runner-linux-x64-2.311.0.tar.gz -L \
  https://github.com/actions/runner/releases/download/v2.311.0/actions-runner-linux-x64-2.311.0.tar.gz

# Extract
tar xzf ./actions-runner-linux-x64-2.311.0.tar.gz

# Configure (use token from GitHub UI)
./config.sh --url https://github.com/YOUR_USERNAME/github-actions-lab --token YOUR_TOKEN

# Install as service
sudo ./svc.sh install

# Start service
sudo ./svc.sh start

ランナーステータスの確認

ランナーが以下の場所で “Idle”（緑色）と表示されていることを確認します:

Settings → Actions → Runners

ヒント

ランナーはワークフロージョブを受け取るためにオンラインかつアイドル状態を維持する必要があります。オフラインと表示される場合は、サービスステータスを確認します: sudo ./svc.sh status

GitHub Secrets の設定

Settings → Secrets and variables → Actions → Secrets に移動します。

SSH 秘密鍵の Secret

このSecretには、ターゲットホストにアクセスするためのSSH秘密鍵が含まれます。

“New repository secret” をクリックします
Name: SSH_PRIVATE_KEY
Value: PEMファイルの内容を貼り付けます

# View your PEM file
cat /path/to/your-key.pem

フォーマット例:

-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEA...
...
-----END RSA PRIVATE KEY-----

“Add secret” をクリックします

重要

SSHキーをリポジトリにコミットしないでください。機密性の高い認証情報には必ずGitHub Secretsを使用します。

GitHub Variables の設定

Settings → Secrets and variables → Actions → Variables に移動します。

デプロイホスト Variable（必須）

このVariableには、Smart Agentをデプロイするすべてのターゲットホストのリストが含まれます。

“New repository variable” をクリックします
Name: DEPLOYMENT_HOSTS
Value: ターゲットホストのIPを入力します（1行に1つ）

172.31.1.243
172.31.1.48
172.31.1.5
172.31.10.20
172.31.10.21

フォーマット要件:

1行に1つのIP
カンマなし
スペースなし
余分な文字なし
Unix改行コード（LF、CRLFではなく）を使用

“Add variable” をクリックします

オプションの Variables

これらのVariableはオプションで、Smart Agentサービスのユーザー/グループ設定に使用されます:

SMARTAGENT_USER

“New repository variable” をクリックします
Name: SMARTAGENT_USER
Value: 例: appdynamics
“Add variable” をクリックします

SMARTAGENT_GROUP

“New repository variable” をクリックします
Name: SMARTAGENT_GROUP
Value: 例: appdynamics
“Add variable” をクリックします

ネットワーク設定

同じVPCおよびセキュリティグループ内のすべてのEC2インスタンスを使用するラボセットアップの場合:

セキュリティグループルール

インバウンドルール:

同じセキュリティグループからのSSH（ポート22）（ソース: 同じSG）

アウトバウンドルール:

0.0.0.0/0へのHTTPS（ポート443）（GitHub APIアクセス用）
同じセキュリティグループへのSSH（ポート22）（ターゲットアクセス用）

ネットワークのベストプラクティス

DEPLOYMENT_HOSTS にはプライベートIPアドレス（172.31.x.x）を使用
ランナーとターゲットを同じセキュリティグループに配置
ターゲットホストにパブリックIPは不要
ランナーはプライベートネットワーク経由で通信
GitHubポーリング用のアウトバウンドHTTPSが必要

設定の確認

ワークフローを実行する前に、セットアップを確認します:

1. ランナーステータスの確認

Settings → Actions → Runners に移動します
ランナーが「Idle」（緑色）と表示されていることを確認します
「Last seen」のタイムスタンプが最近であることを確認します

2. SSH 接続のテスト

ランナーインスタンスからターゲットホストにSSH接続します:

# On runner instance
ssh -i ~/.ssh/your-key.pem ubuntu@172.31.1.243

成功すると、ターゲットホストのシェルプロンプトが表示されます。

3. Secrets と Variables の確認

Settings → Secrets and variables → Actions に移動します
Secretsタブに SSH_PRIVATE_KEY が表示されていることを確認します
Variablesタブに DEPLOYMENT_HOSTS が表示されていることを確認します

4. リポジトリアクセスの確認

ランナーがリポジトリにアクセスできることを確認します:

# On runner instance, as the runner user
cd ~/actions-runner
./run.sh  # Test run (Ctrl+C to stop)

「Listening for Jobs」と表示されます。

よくある問題のトラブルシューティング

ランナーがジョブを取得しない

症状: ワークフローが「queued」状態のまま

解決策:

ランナーステータスを確認します: sudo systemctl status actions.runner.*
ランナーを再起動します: sudo ./svc.sh restart
GitHubへのアウトバウンドHTTPS（443）接続を確認します

SSH 接続の失敗

症状: ワークフローが「Permission denied」または「Connection refused」で失敗

解決策:

# Test from runner
ssh -i ~/.ssh/test-key.pem ubuntu@172.31.1.243 -o ConnectTimeout=10

# Check security group allows SSH from runner
# Verify private key matches public key on targets

ホスト名に無効な文字

症状: エラー「hostname contains invalid characters」

解決策:

DEPLOYMENT_HOSTS Variableを編集します
末尾にスペースがないことを確認します
Unix改行コード（LF、CRLFではなく）を使用します
1行に1つのIP、余分な文字なし

Secrets が見つからない

症状: エラー「Secret SSH_PRIVATE_KEY not found」

解決策:

Secret名が正確に一致していることを確認します: SSH_PRIVATE_KEY
SecretがリポジトリSecrets（環境Secretsではなく）にあることを確認します
リポジトリの管理者アクセス権があることを確認します

セキュリティのベストプラクティス

安全な運用のために、以下のベストプラクティスに従います:

すべての秘密鍵にGitHub Secretsを使用
SSHキーを定期的にローテーション
ランナーをプライベートVPCサブネットに配置
ランナーのセキュリティグループを最小限のアクセスに制限
ランナーソフトウェアを定期的にアップデート
ブランチ保護ルールを有効化
環境ごとに別のキーを使用
リポジトリアクセスの監査ログを有効化

次のステップ

GitHubの設定とランナーのセットアップが完了したら、利用可能なワークフローを確認し、最初のデプロイを実行しましょう。

ワークフローの理解

10 minutes

利用可能なワークフロー

GitHub Actionsラボには、Smart Agentの完全なライフサイクル管理のための 11のワークフロー が含まれています。すべてのワークフローファイルはリポジトリの .github/workflows/ で利用できます。

リポジトリ: https://github.com/chambear2809/github-actions-lab

ワークフローカテゴリ

1. デプロイ（1ワークフロー）

Deploy Smart Agent（バッチ処理）

ファイル: deploy-agent-batched.yml
目的: Smart Agentのインストールとサービスの起動
機能:
- 自動バッチ処理（デフォルト: バッチあたり256ホスト）
- 設定可能なバッチサイズ
- 各バッチ内での並列デプロイ
- シーケンシャルバッチ処理
入力:
- batch_size: バッチあたりのホスト数（デフォルト: 256）
トリガー: 手動のみ（workflow_dispatch）

2. エージェントのインストール（4ワークフロー）

すべてのインストールワークフローは、特定のエージェントタイプをインストールするために smartagentctl を使用します:

Install Node Agent（バッチ処理）

ファイル: install-node-batched.yml
コマンド: smartagentctl install node
バッチ処理: あり（設定可能）

Install Machine Agent（バッチ処理）

ファイル: install-machine-batched.yml
コマンド: smartagentctl install machine
バッチ処理: あり（設定可能）

Install DB Agent（バッチ処理）

ファイル: install-db-batched.yml
コマンド: smartagentctl install db
バッチ処理: あり（設定可能）

Install Java Agent（バッチ処理）

ファイル: install-java-batched.yml
コマンド: smartagentctl install java
バッチ処理: あり（設定可能）

3. エージェントのアンインストール（4ワークフロー）

すべてのアンインストールワークフローは、特定のエージェントタイプを削除するために smartagentctl を使用します:

Uninstall Node Agent（バッチ処理）

ファイル: uninstall-node-batched.yml
コマンド: smartagentctl uninstall node
バッチ処理: あり（設定可能）

Uninstall Machine Agent（バッチ処理）

ファイル: uninstall-machine-batched.yml
コマンド: smartagentctl uninstall machine
バッチ処理: あり（設定可能）

Uninstall DB Agent（バッチ処理）

ファイル: uninstall-db-batched.yml
コマンド: smartagentctl uninstall db
バッチ処理: あり（設定可能）

Uninstall Java Agent（バッチ処理）

ファイル: uninstall-java-batched.yml
コマンド: smartagentctl uninstall java
バッチ処理: あり（設定可能）

4. Smart Agent 管理（2ワークフロー）

Stop and Clean Smart Agent（バッチ処理）

ファイル: stop-clean-smartagent-batched.yml
コマンド:
- smartagentctl stop
- smartagentctl clean
目的: Smart Agentサービスの停止とすべてのデータのパージ
バッチ処理: あり（設定可能）

Cleanup All Agents（バッチ処理）

ファイル: cleanup-appdynamics.yml
コマンド: sudo rm -rf /opt/appdynamics
目的: /opt/appdynamicsディレクトリの完全な削除
バッチ処理: あり（設定可能）
警告: すべてのAppDynamicsコンポーネントが完全に削除されます

「Cleanup All Agents」ワークフローは /opt/appdynamics を完全に削除します。この操作は元に戻せません。注意して使用してください。

ワークフローの構造

すべてのバッチ処理ワークフローは、一貫した2ジョブ構成に従います:

ジョブ 1: Prepare

prepare:
  runs-on: self-hosted
  outputs:
    batches: ${{ steps.create-batches.outputs.batches }}
  steps:
    - name: Load hosts and create batches
      run: |
        # Load DEPLOYMENT_HOSTS variable
        # Split into batches of N hosts
        # Output as JSON array

目的: GitHub Variablesからターゲットホストを読み込み、バッチマトリックスを作成

ジョブ 2: Deploy/Install/Uninstall

deploy:
  needs: prepare
  runs-on: self-hosted
  strategy:
    matrix:
      batch: ${{ fromJson(needs.prepare.outputs.batches) }}
  steps:
    - name: Setup SSH key
    - name: Execute operation on all hosts in batch (parallel)

目的: 各バッチに対して並列に実行し、バッチ内のすべてのホストで特定の操作を実行

バッチ処理の動作

仕組み

Prepare ジョブ が DEPLOYMENT_HOSTS を読み込み、バッチに分割
Deploy ジョブ がバッチごとに1つのマトリックスエントリを作成
バッチはシーケンシャルに処理 され、ランナーの過負荷を防止
各バッチ内 では、バックグラウンドプロセスを使用してすべてのホストが並列にデプロイ

設定可能なバッチサイズ

すべてのワークフローは batch_size 入力を受け付けます（デフォルト: 256）:

# Via GitHub CLI
gh workflow run "Deploy Smart Agent" -f batch_size=128

# Via GitHub UI
Actions → Select workflow → Run workflow → Set batch_size

例

100台のホスト、batch_size=256: 1バッチ、約3分
500台のホスト、batch_size=256: 2バッチ、約6分
1,000台のホスト、batch_size=128: 8バッチ、約16分
5,000台のホスト、batch_size=256: 20バッチ、約60分

ワークフローの実行順序

典型的なデプロイシーケンス

Deploy Smart Agent - 初期デプロイ
Install Machine Agent - 必要に応じて特定のエージェントをインストール
Install DB Agent - データベースモニタリングのインストール
（必要に応じて他のインストールワークフローを使用）

メンテナンス/アップデートシーケンス

Stop and Clean Smart Agent - サービスの停止とデータのクリーン
Deploy Smart Agent - 更新バージョンの再デプロイ
エージェントの再インストール - 必要なエージェントの再インストール

完全な削除シーケンス

Stop and Clean Smart Agent - サービスの停止
Cleanup All Agents - /opt/appdynamicsディレクトリの削除

ワークフローコードの確認

リポジトリで完全なワークフロー YAMLファイルを確認できます:

メインデプロイワークフロー: https://github.com/chambear2809/github-actions-lab/blob/main/.github/workflows/deploy-agent-batched.yml

すべてのワークフロー: https://github.com/chambear2809/github-actions-lab/tree/main/.github/workflows

ワークフローの機能

組み込みエラーハンドリング

ホストごとのエラー追跡
失敗したホストのレポート
バッチレベルの障害処理
常に実行されるサマリー

並列実行

バッチ内のすべてのホストが同時にデプロイ
SSHバックグラウンドプロセス（&）を使用
waitコマンドですべての完了を保証
リソース制限内での最大並列処理

セキュリティ

SSHキーはログに公開されない
認証情報は環境変数としてバインド
自動化のために厳密なホストキーチェックを無効化
ワークフロー完了後にキーを削除

次のステップ

利用可能なワークフローを理解したところで、最初のデプロイを実行しましょう。

ワークフローの実行

15 minutes

ワークフローのトリガー

すべてのワークフローは workflow_dispatch で設定されており、手動でトリガーする必要があります。ワークフローを実行する主な方法は2つあります:

GitHub UI - ビジュアルインターフェース、ほとんどのユーザーにとって最も簡単
GitHub CLI - コマンドラインインターフェース、自動化に最適

方法 1: GitHub UI

ステップ 1: Actions タブに移動

GitHub上のフォークしたリポジトリに移動します
上部の Actions タブをクリックします

ステップ 2: ワークフローを選択

左側のサイドバーに、利用可能なすべてのワークフローが表示されます:

Deploy Smart Agent
Install Node Agent (Batched)
Install Machine Agent (Batched)
Install DB Agent (Batched)
Install Java Agent (Batched)
Uninstall Node Agent (Batched)
Uninstall Machine Agent (Batched)
Uninstall DB Agent (Batched)
Uninstall Java Agent (Batched)
Stop and Clean Smart Agent (Batched)
Cleanup All Agents

実行するワークフローをクリックします。

ステップ 3: ワークフローを実行

“Run workflow” ボタン（右上）をクリックします
ブランチ main を選択します
（オプション）必要に応じて batch_size を調整します
“Run workflow” ボタンをクリックします

ステップ 4: 実行を監視

ワークフローが下のリストに表示されます
ワークフローの実行をクリックして詳細を確認します
リアルタイムで進捗を監視します
ジョブ名をクリックして詳細なログを確認します

方法 2: GitHub CLI

GitHub CLI のインストール

# macOS
brew install gh

# Linux
curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo dd of=/usr/share/keyrings/githubcli-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null
sudo apt update
sudo apt install gh

認証

gh auth login

ワークフローの実行

# Deploy Smart Agent (default batch size)
gh workflow run "Deploy Smart Agent" --repo YOUR_USERNAME/github-actions-lab

# Deploy with custom batch size
gh workflow run "Deploy Smart Agent" \
  --repo YOUR_USERNAME/github-actions-lab \
  -f batch_size=128

# Install agents
gh workflow run "Install Node Agent (Batched for Large Scale)" \
  --repo YOUR_USERNAME/github-actions-lab

gh workflow run "Install Machine Agent (Batched for Large Scale)" \
  --repo YOUR_USERNAME/github-actions-lab

# Uninstall agents
gh workflow run "Uninstall Node Agent (Batched for Large Scale)" \
  --repo YOUR_USERNAME/github-actions-lab

# Stop and clean
gh workflow run "Stop and Clean Smart Agent (Batched for Large Scale)" \
  --repo YOUR_USERNAME/github-actions-lab

# Complete cleanup
gh workflow run "Cleanup All Agents" \
  --repo YOUR_USERNAME/github-actions-lab

ワークフローの監視

# List recent workflow runs
gh run list --repo YOUR_USERNAME/github-actions-lab

# View specific run
gh run view RUN_ID --repo YOUR_USERNAME/github-actions-lab

# Watch run in progress
gh run watch RUN_ID --repo YOUR_USERNAME/github-actions-lab

# View failed logs
gh run view RUN_ID --log-failed --repo YOUR_USERNAME/github-actions-lab

初回デプロイのウォークスルー

完全な初回デプロイの手順を説明します:

ステップ 1: セットアップの確認

ワークフローを実行する前に、以下を確認します:

セルフホストランナーが「Idle」（緑色）と表示されている
SSH_PRIVATE_KEY Secretが設定されている
DEPLOYMENT_HOSTS VariableにターゲットIPが含まれている
ネットワーク接続が確認済み

ステップ 2: Smart Agent のデプロイ

GitHub UI 経由:

Actions タブに移動します
“Deploy Smart Agent” を選択します
“Run workflow” をクリックします
デフォルトのbatch_size（256）を受け入れます
“Run workflow” をクリックします

GitHub CLI 経由:

gh workflow run "Deploy Smart Agent" --repo YOUR_USERNAME/github-actions-lab

ステップ 3: 実行の監視

ワークフローは以下を表示します:

Prepare ジョブ - バッチマトリックスの作成
Deploy ジョブ（バッチごとに1つ）- ホストへのデプロイ

各ジョブをクリックして詳細なログを確認します。

ステップ 4: インストールの確認

ターゲットホストにSSH接続して確認します:

# SSH to target
ssh ubuntu@172.31.1.243

# Check Smart Agent status
cd /opt/appdynamics/appdsmartagent
sudo ./smartagentctl status

期待される出力:

Smart Agent is running (PID: 12345)
Service: appdsmartagent.service
Status: active (running)

ステップ 5: 追加エージェントのインストール（オプション）

必要に応じて、特定のエージェントタイプをインストールします:

# Install Machine Agent
gh workflow run "Install Machine Agent (Batched for Large Scale)" \
  --repo YOUR_USERNAME/github-actions-lab

# Install DB Agent
gh workflow run "Install DB Agent (Batched for Large Scale)" \
  --repo YOUR_USERNAME/github-actions-lab

ワークフロー出力の理解

Prepare ジョブの出力

Loading deployment hosts...
Total hosts: 1000
Batch size: 256
Creating 4 batches...
Batch 1: Hosts 1-256
Batch 2: Hosts 257-512
Batch 3: Hosts 513-768
Batch 4: Hosts 769-1000

Deploy ジョブの出力（バッチごと）

Processing batch 1 of 4
Deploying to 256 hosts in parallel...
Host 172.31.1.1: SUCCESS
Host 172.31.1.2: SUCCESS
Host 172.31.1.3: SUCCESS
...
Batch 1 complete: 256/256 succeeded

完了サマリー

Deployment Summary:
Total hosts: 1000
Successful: 998
Failed: 2
Failed hosts:
  - 172.31.1.48
  - 172.31.1.125

よくあるデプロイシナリオ

シナリオ 1: 初期デプロイ

# 1. Deploy Smart Agent
gh workflow run "Deploy Smart Agent"

# 2. Verify deployment
# SSH to a host and check status

# 3. Install agents as needed
gh workflow run "Install Machine Agent (Batched for Large Scale)"
gh workflow run "Install DB Agent (Batched for Large Scale)"

シナリオ 2: Smart Agent のアップデート

# 1. Stop and clean current installation
gh workflow run "Stop and Clean Smart Agent (Batched for Large Scale)"

# 2. Update Smart Agent ZIP in repository
# (Push new version to repository)

# 3. Deploy new version
gh workflow run "Deploy Smart Agent"

# 4. Reinstall agents
gh workflow run "Install Machine Agent (Batched for Large Scale)"

シナリオ 3: 新しいホストの追加

# 1. Update DEPLOYMENT_HOSTS variable in GitHub
# Add new IPs

# 2. Deploy to all hosts (will skip existing ones with idempotent logic)
gh workflow run "Deploy Smart Agent"

シナリオ 4: 完全な削除

# 1. Stop and clean
gh workflow run "Stop and Clean Smart Agent (Batched for Large Scale)"

# 2. Complete removal
gh workflow run "Cleanup All Agents"

「Cleanup All Agents」は /opt/appdynamics を完全に削除します。この操作は元に戻せません。

ワークフロー失敗のトラブルシューティング

ワークフローが「Queued」のまま

症状: ワークフローが開始されない

原因: ランナーが利用できないかオフライン

解決策:

ランナーステータスを確認します: Settings → Actions → Runners
ランナーが「Idle」（緑色）と表示されていることを確認します
必要に応じてランナーを再起動します: sudo ./svc.sh restart

SSH 接続の失敗

症状:「Permission denied」または「Connection refused」エラー

解決策:

SSH を手動でテスト:

# From runner instance
ssh -i ~/.ssh/test-key.pem ubuntu@172.31.1.243

セキュリティグループを確認:

ランナーからのSSH（22）が許可されていることを確認
ランナーとターゲットが同じセキュリティグループにあることを確認

SSH キーを確認:

SSH_PRIVATE_KEY Secretが実際のキーと一致していることを確認
ターゲットホストに公開鍵があることを確認

部分的なバッチの失敗

症状: 一部のホストが成功し、他が失敗

解決策:

ワークフローログで失敗したホストを特定
失敗したホストにSSH接続して調査
ワークフローを再実行（冪等性 - 成功したホストはスキップ）

バッチジョブエラー

症状:「Error splitting hosts into batches」

解決策:

DEPLOYMENT_HOSTS Variableのフォーマットを確認
1行に1つのIPであることを確認
末尾のスペースや特殊文字がないことを確認
Unix改行コード（LF、CRLFではなく）を使用

パフォーマンスチューニング

バッチサイズの調整

小さなバッチ（リソース使用量が少ない、速度は低下）:

gh workflow run "Deploy Smart Agent" -f batch_size=128

大きなバッチ（リソース使用量が多い、速度は向上）:

gh workflow run "Deploy Smart Agent" -f batch_size=256

ランナーリソースの推奨事項

ホスト数	CPU	メモリ	バッチサイズ
1-100	2コア	4 GB	256
100-500	4コア	8 GB	256
500-2000	8コア	16 GB	256
2000+	16コア	32 GB	256

ベストプラクティス

まず単一ホストでテスト
- 1つのIPでテスト変数を作成
- ワークフローを実行して確認
- その後フルリストにデプロイ
ワークフロー実行の監視
- リアルタイムでログを監視
- エラーを即座に確認
- サンプルホストで検証
適切なバッチサイズの使用
- デフォルト（256）はほとんどの場合に適用
- ランナーに負荷がかかる場合は削減
- ランナーのリソース使用量を監視
ワークフローを最新の状態に維持
- リポジトリから最新の変更をプル
- 本番環境以外で先にアップデートをテスト
- カスタマイズ内容をドキュメント化
ランナーの正常性を維持
- ランナーをオンラインかつアイドル状態に維持
- ランナーソフトウェアを定期的にアップデート
- ディスク容量とリソースを監視

次のステップ

おめでとうございます。GitHub Actionsを使用したAppDynamics Smart Agentデプロイの自動化方法を学びました。詳細については、完全なリポジトリを参照してください。

Smart Agent と Ansible によるモニタリングのコード化

10 minutes

はじめに

このガイドでは、Ansibleを使用してCisco AppDynamics Smart Agentを複数のホストにデプロイする方法を説明します。自動化を活用することで、モニタリングインフラストラクチャの一貫性、堅牢性、スケーラビリティを確保できます。

アーキテクチャの概要

デプロイアーキテクチャは、Ansibleコントロールノードを活用して、ターゲットホストへのSmart Agentのインストールと設定をオーケストレーションします。

graph TD
    CN[Ansible Control Node<br/>(macOS/Linux)] -->|SSH| H1[Target Host 1<br/>(Debian/RedHat)]
    CN -->|SSH| H2[Target Host 2<br/>(Debian/RedHat)]
    CN -->|SSH| H3[Target Host N<br/>(Debian/RedHat)]

    subgraph "Target Host Configuration"
        SA[Smart Agent Service]
        Config[config.ini]
        Package[Installer .deb/.rpm]
    end

    H1 --> SA
    H2 --> SA
    H3 --> SA

主要コンポーネント

Ansible Control Node: プレイブックを実行するマシン（例: ラップトップやジャンプホスト）です。
Target Hosts: Smart Agentがインストールされるサーバーです。
Inventory: ターゲットホストとその接続情報の一覧です。
Playbook: デプロイタスクを定義するYAMLファイルです。

前提条件

開始する前に、以下を確認してください

SSH経由でターゲットホストにアクセスできること。
ターゲットホストでsudo権限を持っていること。
Smart Agentインストールパッケージ（.deb または .rpm）をダウンロード済みであること。
AppDynamics Controllerのアカウント情報（Access Key、Account Name、URL）を用意していること。

ステップ1: macOS に Ansible をインストールする

まず、コントロールノードにAnsibleをインストールします。

Homebrew をインストール します（未インストールの場合）

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Ansible をインストール します
```
brew install ansible
```
インストールを確認 します
```
ansible --version
```
Ansibleのインストール済みバージョンを示す出力が表示されます。

セットアップと設定

10 minutes

ステップ2: ファイルとディレクトリ構成を準備する

Ansibleデプロイ用のプロジェクトディレクトリを作成します。以下のファイルを含める必要があります

.
├── appdsmartagent_64_linux_24.6.0.2143.deb  # Debian package
├── appdsmartagent_64_linux_24.6.0.2143.rpm  # RedHat package
├── inventory-cloud.yaml                     # Inventory file
├── smartagent.yaml                          # Playbook
└── variables.yaml                           # Variables file

ターゲット環境に適したSmart Agentパッケージをダウンロード済みであることを確認してください。

ステップ3: ファイルの内容を理解する

1. インベントリファイル（`inventory-cloud.yaml`）

インベントリファイルには、Smart Agentをデプロイするホストの一覧を記載します。ホストと認証情報をここで定義します。

all:
  hosts:
    smartagent-host-1:
      ansible_host: 54.173.1.106
      ansible_username: ec2-user
      ansible_password: ins3965!
      ansible_become: yes
      ansible_become_method: sudo
      ansible_become_password: ins3965!
      ansible_ssh_common_args: '-o StrictHostKeyChecking=no'

    smartagent-host-2:
      ansible_host: 192.168.86.107
      ansible_username: aleccham
      ansible_password: ins3965!
      ansible_become: yes
      ansible_become_method: sudo
      ansible_become_password: ins3965!

    smartagent-host-3:
      ansible_host: 54.82.95.69
      ansible_username: ubuntu
      ansible_password: ins3965!
      ansible_become: yes
      ansible_become_method: sudo
      ansible_become_password: ins3965!

Action: ansible_host のIPアドレスと認証情報を、実際のラボ環境の情報に更新します。

2. 変数ファイル（`variables.yaml`）

このファイルには、Smart Agentの設定情報が含まれています。

smart_agent:
  controller_url: 'CONTROLLER URL HERE, JUST THE BASE URL' # o11y.saas.appdynamics.com
  account_name: 'Account Name Here'
  account_access_key: 'YOUR ACCESS KEY HERE'
  fm_service_port: '443' # Use 443 or 8080 depending on your environment.
  ssl: true

smart_agent_package_debian: 'appdsmartagent_64_linux_24.6.0.2143.deb'  # or the appropriate package name
smart_agent_package_redhat: 'appdsmartagent_64_linux_24.6.0.2143.rpm'  # or the appropriate package name

Action: smart_agent セクションを、使用するController URL、アカウント名、アクセスキーに更新します。

3. プレイブック（`smartagent.yaml`）

このプレイブックは、Cisco AppDynamics Distribution of OpenTelemetry Collectorのデプロイをオーケストレーションします。タスクの概要は以下のとおりです

前提パッケージ: 必要なパッケージをインストールします（RedHatの場合は yum-utils、Debianの場合は curl/apt-transport-https）。
ディレクトリのセットアップ: /opt/appdynamics/appdsmartagent ディレクトリが存在することを確認します。
設定:
- config.ini が存在するかチェックします。
- 存在しない場合、variables.yaml の値を使用してデフォルトの config.ini を作成します。
- lineinfile を使用して設定キー（AccountAccessKey、ControllerURLなど）を更新し、設定が正しいことを確認します。
パッケージ管理:
- OSファミリー（Debian/RedHat）に基づいて適切なパッケージパスを決定します。
- パッケージがローカルに存在しない場合は失敗します。
- パッケージをターゲットホストの /tmp ディレクトリにコピーします。
- dpkg または yum を使用してパッケージをインストールします。
サービス管理: smartagent サービスを再起動します。
クリーンアップ: 一時パッケージファイルを削除します。

このプレイブックは、when: ansible_os_family == ... の条件分岐を使用して、同じワークフロー内でRedHatとDebianの両方のシステムに対応しています。

デプロイ

5 minutes

ステップ4: プレイブックを実行する

Smart Agentをデプロイするには、プロジェクトディレクトリから以下のコマンドを実行します

ansible-playbook -i inventory-cloud.yaml smartagent.yaml

インベントリファイルに別の名前を付けた場合は、inventory-cloud.yaml を適切なファイル名に置き換えます。

確認

プレイブックが正常に完了したら、ターゲットホストの1つにログインしてサービスの状態を確認することで、デプロイを検証できます

systemctl status smartagent

サービスがactive (running) と表示されます。

Splunk4Ninjas AppDynamics

はじめに

ワークショップ概要

今後追加予定の内容

Splunk4Ninjas AppDynamicsのサブセクション

Application Performance Monitoring (APM)

目標

ワークショップ環境

Controller

Application VM

Application Performance Monitoring (APM)のサブセクション

1. Java Agent のダウンロード

Controller へのログイン

アプリケーションの設定

Java Agent のダウンロード

2. Java Agent のインストール

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

Java Agent の解凍

Tomcat Server への Java Agent の追加

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

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

負荷生成の開始

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

4. AppDynamics の基本概念

Flow Maps

Business Transactions

Business Transactions の確認

Snapshots

Drill Downs と Call Graphs

5. Controller 設定の構成

Business Transaction 設定の調整

Call Graph 設定の調整

Business Transaction の変更の確認

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

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

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

まとめ

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

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

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

まとめ

Server Visibility Monitoring

目標

ワークショップ環境

Controller

Application VM

Server Visibility Monitoringのサブセクション

Machine Agent のデプロイ

インストールスクリプトの実行

Server Agent の設定

Server Visibility Agent の起動

サーバーの健全性を監視する

Server Main Dashboard の確認

Server Processes Dashboard の確認

Server Volumes Dashboard の確認

Server Network Dashboard の確認

サーバーと APM の相関

サーバーとアプリケーションのコンテキスト間の移動

Business iQ

目標

ワークショップ環境

Controller VM

Application VM

Business iQのサブセクション

ラボの前提条件

Controllerへのログイン

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

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

アプリケーションでAnalyticsを有効化

Controllerへのログイン

Analytics設定への移動

Transaction Summaryの検証

HTTPデータコレクターの設定

すべてのHTTPデータコレクターの有効化

関連するHTTPデータコレクターの観察と選択

HTTPパラメータを使用したAnalyticsでのビジネスデータのキャプチャ

HTTPパラメータのAnalyticsの検証

メソッドデータコレクターの設定

ディスカバリーセッションを開く

オブジェクトへのドリルダウン