Download PDF
Download page イベントサービスの管理.
イベントサービスの管理
このコンポーネントは、オンプレミス展開でのみ使用できます。SaaS 展開は AppDynamics によって管理されます。
このページでは、Enterprise Console を使用してイベントサービスを管理する方法について説明します。 次のタスクはすべてGUIまたはCLIで実行できます。
イベントサービスの起動および停止
イベントサービスは、データベースの可視性 モジュールによって使用される内部データストレージエンジンです。データベースモニタリングを使用するには、イベントサービスを起動する必要があります。
イベントサービスは、インストール後自動的に起動します。
Linuxの場合
Linux で、次のコマンドを実行してイベントサービスを起動します。
bin/platform-admin.sh submit-job --platform-name <platform_name> --service events-service --job start
次のコマンドを実行してイベントサービスを停止します。
bin/platform-admin.sh submit-job --platform-name <platform_name> --service events-service --job stop
Windowsの場合
Windows で、次のコマンドを実行してイベントサービスを起動します。
bin/platform-admin.exe cli submit-job --platform-name <platform_name> --service events-service --job start
次のコマンドを実行してイベントサービスを停止します。
bin/platform-admin.exe cli submit-job --platform-name <platform_name> --service events-service --job stop
クラスタノードの正常性のモニタリング
新しいデプロイメントについては、イベントサービスクラスタの正常性を注意深くモニタリングすること、特にディスク消費をモニタリングすることが大切です。
次のコマンドを使用して、Enterprise Console GUI またはコントローラマシンのコントローラページから、クラスタのステータスを確認できます。
bin/platform-admin.sh show-events-service-health
結果には、考えられる問題とその問題を解決するために必要な手順が示されます。たとえば、利用可能なディスクが少ない場合、解決するためにクラスタにノードを追加します。
以下は、考えられるエラーと修復手順です。
エラー | 説明 | 修復 |
---|---|---|
クラスタの容量が不足 | イベントサービスのJavaプロセスのヒープサイズが80%を上回っている | イベントサービスノードを追加する |
ディスクサイズが残り30%以下 | 識別されたノードのディスクサイズが30%以下に落ちた | イベントサービスノードを追加する |
イベントサービスに到達不可能だがホストには到達可能 | 識別されたノード上でイベントサービスのプロセスが適切に機能していない | ノードを再起動する |
マシンに到達不可能 | マシンが停止、切断状態またはエラーが起こっている可能性がある | マシンを再起動する。それでも改善しない場合は、クラスタからノードを削除しなければならない場合がある。 |
クラスタの再起動が必要 | クラスタの再起動が必要な状態として識別される | クラスタを再起動する |
クラスタサイズが2 | イベントサービスクラスタが2つ以上のノードを要求する | ノードを追加する |
クラスタの拡張
Enterprise Console の GUI または CLI を使用して、Linux 上のイベントサービスクラスタを水平方向にスケーリングできます。増加する作業負荷に対応できるよう既存のデプロイメントを拡張するには、ノードを追加するだけです。
始める前に、新しいクラスタマシンを準備します。「イベントサービス要件」の説明に従って、システム要件を確認し、環境を整えます。
クラスタの新しいマシンが、既存クラスタメンバーと同じ SSH 対応ユーザアカウントを持つようにしてください。
システムの準備ができたら、ノードを追加するためのコマンドを実行します。
bin/platform-admin.sh add-events-service-nodes --hosts host1 host2 host3
あるいは、新しいノードのホスト名をファイルとして渡します。
bin/platform-admin.sh add-events-service-nodes --host-file=/home/appduser/hosts.txt
コマンド(たとえば hosts.txt
)に渡すファイルには、追加するノードの内部 DNS ホスト名または IP アドレスが含まれている必要があります。クラスタの既存のノードをリストする必要はありません。 これらのホストはプラットフォームに所属する必要があります。ホストをプラットフォームに追加する方法の詳細は、「Enterprise Consoleの管理」を参照してください。
ロードバランサルールを変更し、ルーティングルールに新しいクラスタメンバーを含むようにしてください。詳細については、「ロードバランスイベントサービストラフィック」を参照してください。
ノードを再起動する
Enterprise Console GUIまたはCLIを使用して、ノードを再起動できます。
システムの準備ができたら、ノードを再起動するためのコマンドを実行します。
bin/platform-admin.sh submit-job --platform-name <platform_name> --service events-service --job restart-node --args nodeActionHost=<node_name>
ここで <node_name>
は次のコマンドによるノードのホスト名です。
bin/platform-admin.sh list-nodes --platform-name <platform_name> --service events-service
クラスタを再起動する
Enterprise Console GUIまたはCLIを使用して、クラスタを再起動できます。
システムの準備ができたら、クラスタノードを再起動するためのコマンドを実行します。
bin/platform-admin.sh submit-job --platform-name <platform_name> --service events-service -job restart-cluster
ノードの削除または置換
uninstall-events-service
コマンドはすべてのクラスタノードからイベントサービスのソフトウェアとデータを削除します。コントローラおよびイベントサービスはデータベースを共有しているため、イベントサービスをインストールするために Enterprise Console を実行したコントローラインスタンスをアンインストールする場合は、コントローラをアンインストールする前にこのコマンドを使用してイベントサービスをアンインストールする必要があります。
remove-events-service-node
コマンドは、ホスト名で指定した 1 つのノードから、イベントサービスのソフトウェアとデータを削除します。クラスタ内に少なくとも 4 つのノードがある場合にのみこのコマンドを使用します。3 つのノードを持つクラスタからのイベントサービス削除には対応していません。--node
コマンドラインパラメータを使用して、削除するノードを指定します。
ノードを削除したら、ロードバランサのルールを調整して古いクラスタメンバーを削除してください。詳細については、「ロードバランスイベントサービストラフィック」を参照してください。
クラスタ展開でロードバランサを使用していない場合は、インストール時にコントローラにレポートする最初のプライマリノードの接続設定は、コントローラに対してイベントサービスを特定するコントローラ設定に書き込まれることに注意してください。その状況でプライマリノードを削除する場合は、削除したプライマリノードがコントローラ接続設定(例:appdynamics.on.premise.event.service.url
)でイベントサービスの宛先 URL として指定されているノードであるかどうかを確認し、該当する場合はその設定を調整します。詳細については、「イベントサービスへの接続」を参照してください。
次のガイドラインに注意してください。
- 結果として生じるクラスタサイズが2となるノードは削除できない。
- 3 つ以上のノードで構成されるクラスタは、単一ノードのイベントサービスにサイズを減少することはできません。
remove-events-service-node
コマンドは、ホスト名で指定した 1 つのノードから、イベントサービスのソフトウェアとデータを削除します。クラスタ内に少なくとも 4 つのノードがある場合にのみこのコマンドを使用します。3 つのノードを持つクラスタからのイベントサービス削除には対応していません。--node
コマンドラインパラメータを使用して、削除するノードを指定します。
このコマンドで、引数で指定されたノードを削除します。
bin/platform-admin.sh remove-events-service-node --node 10.0.100.51
上記のコマンドを使用してプライマリノードを削除しようとすると、Enterprise Console が、プライマリノードを削除しようとしていることを通知し、操作をキャンセルします。出力で示されるとおり、-f
force フラグを使用してコマンドを再度実行することで、プライマリノードの削除を進めることができます。プライマリノードを削除すると、クラスタは既存のデータノードから新しいプライマリノードを選択します。選択プロセスには数秒かかることがあり、その間新しいイベントを処理することはできません。サービスが短時間中断しても影響が少ない時に、このオペレーションを実行してください。
到達不能なノードがあって削除したいが、上記の制限により削除できない場合、代わりに置換することができます。
このコマンドで、引数で指定された古いノードを新しいノードに置換します。
bin/platform-admin.sh submit-job --service events-service --job replace-node --args originalNode=<old_host_address> newNode=<new_host_address>
- クラスタからイベントサービスノードを削除した後、EUM プロパティファイル
analytics.accountAccessKey
ではなく、コントローラadmin.jsp
とイベントサービスのプロパティファイルで値appdynamics.es.eum.key
が変更されていることを確認できます。 - コントローラとイベントサービスでキー値が変更されたかどうかを確認し、キー値を EUM プロパティファイル
analytics.accountAccessKey
に置き換えます。
イベントサービスで SSL を使用できるようにする
Enterprise Console CLI を使用して、イベントサービスで SSL を使用できるようにすることができます。JKS 形式のキーストアファイル、パスワード、およびキーストアのエイリアスが必要です。キーストアを作成するための詳細な手順については、「証明書の作成と CSR の生成」を参照してください。
Enterprise Console にログインします。
bin/platform-admin.sh login --user-name <admin_username> --password <admin_password>
TEXT正常にログインしたら、イベントサービスの
enable-ssl
ジョブを送信し、キーストアファイルへのパス、キーストアのパスワード、およびキーストアのエイリアスを提供します。bin/platform-admin.sh submit-job --platform-name <platform_name> --service events-service --job enable-ssl --args keystorePath=<path-to-keystore-jks-file> keystorePassword=<keystore_password> keystoreAlias=<keystore_alias>
TEXTSSL が有効になっていることを確認します。
curl -k -v -X GET https://<events-service-domain>:9080/_ping
TEXTcURL コマンドの出力には、TLS ハンドシェイクと HTTP ステータス 200 が表示されます。
... * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): ... < HTTP/1.1 200 OK < Date: Fri, 10 May 2019 00:13:49 GMT < X-Content-Security-Policy: default-src 'self' ...
TEXT
イベントサービスログの収集
Enterprise Consoleは、クラスタのノードからログを収集できます。次のコマンドはノードログを取得して、Enterprise Consoleのログとともにバンドルします。
bin/platform-admin.sh retrieve-events-service-logs
コマンドが完了すると、スクリプトを実行した場所に events-service.log.zip
という名前の ZIP ファイルが作成されます。その後、アーカイブを抽出してトラブルシューティングを行うか、トラブルシューティングに役立つアーカイブを AppDynamics 担当者に送信することができます。何らかの理由で Enterprise Console がログを取得するのにクラスタノードの 1 つと接続できなかった場合、アーカイブに含まれるログファイルに接続エラーが書き込まれます。
SSHキーファイルの変更
初期インストール後、Enterprise Console がノードマシンにアクセスできるよう PEM ファイルをアップデートしなければならない場合があります。
そのためには、「イベントサービスホストの準備」におけるパスワード不要の SSH ログインの構成に関する議論にあるように、PEM ファイルを作成し、次のコマンドを使用して新しい PEM ファイルをインストールします。
bin/platform-admin.sh set-user-credentials --ssh-key-file newkeyfile.pem
変更はすぐに有効になります。
イベントサービスのアップグレード
Enterprise Consoleを使用して、イベントサービスソフトウェアを導入されているノード上でローリングアップグレードできます。詳細については、「Enterprise Consoleを使用したイベントサービスのアップグレード」を参照してください。
イベントサービスデプロイメントをアップグレードするための一般的な手順は、以下の通りです。
- コントローラをアップグレードします。(Enterprise Consoleを使用するコントローラのアップグレード を参照してください)。
次のコマンドを使用して、イベントサービスノードにアップグレードを適用する。
bin/platform-admin.sh upgrade-events-service
Enterprise Console は、イベントサービスが現行のコントローラバージョンに対して最新の状態であるかを確認し、そうでなければアップデートを実行します。
AppDynamicsによるイベントサービスノードのモニタリング
AppDynamicsエージェントを使用してイベントサービスノードまたはクラスタをモニタリングし、トラブルシューティング用の診断情報を生成できます。次のステップはワークフローの概要です。
- AppDynamics ダウンロードセンターから次のエージェントをダウンロードします。
- Javaエージェント
- マシンエージェント
- クラスタ内の各ノードに、両方のエージェントをインストールします。まず Java エージェント、次にマシンエージェントをインストールします。
- クラスタの各ノードで、 JavaエージェントのVMオプションを更新します。
- 次のファイルをテキストエディタで開きます。
<controller_home>/platform_admin/events-service/conf/events-service.vmoptions
以下の行をファイルの末尾に追加します。
-javaagent:/opt/appdynamics/events-service/java_agent/ver4.5.0.0/javaagent.jar -Dappdynamics.agent.accountName=<account_name> -Dappdynamics.agent.applicationName=<events_service_app_name> -Dappdynamics.controller.hostName=<controller_host> -Dappdynamics.controller.port=443 -Dappdynamics.controller.ssl.enabled=true -Dappdynamics.agent.nodeName=<events_service_node_name> -Dappdynamics.agent.tierName=<events_service_tier_name>
Java エージェント JAR、アカウント名、その他の値を適宜調整します。
イベントサービスクラスタ内のすべてのノードについて、ビジネスアプリケーション名(
events_service_app_name
)とティア名(events_service_tier_name
)は通常同じですが、各ノードは一意の名前でなければなりません(events_service_node_name
)。
AppDynamics におけるアプリケーションのモデル化に関する情報は、「アプリケーションモデリング」を参照してください。
- 次のファイルをテキストエディタで開きます。
「独立したマシンエージェントのインストール」で説明しているように、クラスタ内の各ノードで、マシンエージェントが使用するノード名とティア名を定義します。
各マシンエージェントのノード名とティア名は、各ノードで指定した
events_service_node_name
およびevents_service_tier_name
と同じでなければなりません。- クラスタ内のすべてのノードでイベントサービスを再起動します。コントローラホストで
<controller_home
>/platform_admin/events-service/
に移動し、/bin/platform-admin.sh restart-events-service
コマンドを入力します。 - コントローラの UI で、[Applications] テーブルに移動して events_service_app_name アプリケーションのダッシュボードを開きます(ノードのイベントサービスが再起動してコントローラへのデータ送信を開始するまで、このアプリケーションが表示されるのに数分かかる場合があります)。
- アプリケーション ダッシュボードで、[Configure] > [Instrumentation] を選択します。
events_service_tier_name
ティアを選択し、[Use Custom Configuration for this Tier] を選択します。- カスタムマッチルールの下に、次の属性で新しいルールを作成します:
- エントリポイント = Servlet
- リクエストデータを使用してトランザクションを分割 = トランザクション名の最初の 4 セグメントを使用
イベントサービスノードの Java 一時ディレクトリの更新
CLI のプラットフォーム管理を使用して、イベントサービスで一時 Java ディレクトリのオプションのオーバーライドを設定できます。イベントサービスの Java 一時ディレクトリを更新するには、次の手順を実行します。
イベントサービス設定を更新した後、イベントサービスを再起動するには、プラットフォーム管理 CLI または Enterprise Console GUI が必要です。
- インストール後に次のコマンドを実行します。
/root/install/pa/platform-admin/bin/platform-admin.sh submit-job --service events-service --job update_jvm_temp_dir --args jvmTempDir=/var/tmp
2. 次のコマンドを実行して、設定が有効であることを確認します。
/root/install/pa/platform-admin/bin/platform-admin.sh list-service-configurations --service events-service
3. ジョブ update_jvm_temp_dir
の設定を追加します。
jvmTempDir (STRING): [/var/tmp]
4. 元に戻すには、次のコマンドを使用します。
/root/install/pa/platform-admin/bin/platform-admin.sh submit-job --service events-service --job update_jvm_temp_dir
5. ジョブ update_jvm_temp_dir
の設定を追加するには、次のコマンドを使用します。
jvmTempDir (STRING): [null]