このページでは、コントローラのインストールおよびオペレーション中に発生する可能性がある問題のトラブルシューティング情報を提供しています。 

コントローラサーバーログ

コントローラのプライマリログファイルは次の場所にあります。

<controller_home>/logs/server.log

コントローラの問題をトラブルシュートするには、まずログファイルを確認します。発生した問題に対応する可能性のあるエラーをログで探します。エラーが見つかった場合は、エラーログで問題を特定し解決できることがあります。

「カスタム インストール」にあるインストールのトラブルシューティングに関する情報も参照してください。 

コントローラのパフォーマンス問題の特定

次の場合、コントローラのパフォーマンスに問題が発生しています。

  1. コントローラUIの動作が遅い。15 分や 30 分などの短い時間にわたり応答に 10 秒から 20 秒以上かかる場合、コントローラに負荷がかかっている兆候の可能性があります。 
  2. コントローラのメトリックレポートと現在の時間に7分から10分の開きが見られる場合、コントローラに負荷がかかっている兆候かもしれません。3分から5分程度の遅れは正常です。
  3. コントローラ環境をモニタリングする時に、CPU、メモリ、ディスクメトリックが約75%のキャパシティにある。

コントローラのパフォーマンス低下が見られたら、次のいずれかの原因が考えられます。

  • コントローラのハードウェアリソースが正しいコントローラプロファイルと一致していません。
  • コントローラのパフォーマンスプロファイルが正しく構成されていません。
コントローラのパフォーマンス問題を解決するには：
  1. ハードウェアが使用中のコントローラのプロファイルと一致するか確認します。詳細については、「コントローラシステム要件」を参照してください。
  2. ディスクパフォーマンスが最小ディスクパフォーマンスの推奨しきい値と一致することを確認します。詳細については、「コントローラシステム要件」を参照してください。
  3. Java SDK バージョンがコントローラの Java バージョンと同一であることを確認します。以下の手順で、コントローラで使用されているJavaのバージョンを表示します。
    • コマンドライン ユーティリティを開きます。
    • 次の URL にアクセスしてください。 <Controller_Installation_Directory>/jre/bin
    • java -versionの実行

ヒープ使用量のモニタリング

  • Windowsでは、タスクマネージャを使用してコントローラのメモリ使用状況を測定します。

  • Linux では、top コマンドを使用してメモリデータの統計を取得します。

    ps -elf (expect to see a "java" process and a "mysql" process)

top (expect to see java and mysql with cpu greater then 0)
    BASH

コントローラのインストール中のタイムアウトエラー

コントローラのインストール中に、Enterprise Console がコントローラのアプリケーションサーバとデータベースの起動を試みます。初回のデータベース起動時に、アプリケーションはデータベーススキーマ、テーブル、コントローラが必要とするその他のアーティファクトの作成を試みます。  

デフォルトでは、Enterprise Console は、コントローラ アプリケーション サーバまたはデータベースが起動するのを 45 分間待機します。中規模または大規模のプロファイルのコントローラをインストールする場合や、仮想マシンなどの特定の環境へインストールする場合は、システムの起動にかかる時間が、デフォルトの起動タイムアウト期間を超える可能性があります。

Windowsでコントローラが正常に起動しない

Glassfishにより作成されたトランザクションログのファイル拡張子が原因で、コントローラが起動しないことがあります。「コントローラのためのWindowsの準備」に記載されている手順でウイルススキャナーのスキャン対象からコントローラのデータディレクトリを除外しても、<AppDynamicsInstall>\Controller\appserver\glassfish\domains\domain1\logs\server\tx ディレクトリにあるこうした拡張子のファイルは考慮されません。ウィルス対策ソフトでこれらの拡張子（WRYなど）が検出された場合、該当するファイルを使用するプロセスが停止され、コントローラが起動しないことがあります。

これらのトランザクションログは、失敗したGlassfishトランザクションを復元するためのものですので、起動時に削除しないようにしてください。代わりに、コントローラディレクトリ全体を無視するようにウィルススキャナーを構成してください。 

Metrics Browserにデータがない

これは、エージェントが正しく構成されていない可能性を示します。server.log ファイルを確認して、トラブルシューティングを開始してください。

コントローラのログファイルはすべて <Controller_Installation_Directory>/logs フォルダにあります。

エラーメッセージ

解決策

Error receiving metrics (node not properly modeled yet: Could not find component for node.

このエラーは、アプリケーションエージェントが特定のノードのメトリックデータをアップロードしようとしたものの、ノードがどのティアにも属していなかったことを意味しています。ノードのメトリックデータを受信するには、ノードがティアに属しており、かつこのティアがビジネスアプリケーションに属している必要があります。「アプリケーションモニタリングの概要」を参照してください。

Received Metric Registration request for a machine that is NOT registered to any nodes. Sending back null!

このエラーは、コントローラが、ノードと関連付けられていないマシンIDを一覧にしたマシンエージェントのメトリックの登録リクエストを受信したことを示しています。マシンエージェントを構成し、適切なアプリケーション、ティア、ノードに関連付けてください。「マシンエージェントのインストール」を参照してください。

Agent upload blocked, as its reporting a time well into the future. 

アプリケーションエージェントは、コントローラの時間を使用してメトリックデータを報告しようとします。エージェントは5分毎にコントローラから時間を取得しますが、この時間とローカルマシンの時間が異なる場合は、ローカルマシンの時間のスキューを使用して時間を報告します。

何らかの理由により、アプリケーションエージェントがコントローラの時間より早いタイムスタンプを持つメトリックを報告した場合、コントローラはそのメトリックを拒否します。これを防ぐために、コントローラが実行されているマシンとアプリケーションエージェント用のマシンのシステムの時間が同期されるようにしてください。

マルチバイト文字が文字化けする

Windows環境では日本語などのマルチバイト文字が含まれるコンポーネント名がコントローラUIやエクスポートされたファイルで文字化けしていることがあります。
その場合、コントローラのJVM オプションに以下のプロパティを追加することで修正できます。

-Dfile.encoding=UTF-8
JAVA

コントローラをシャットダウンしてもLinuxの空きメモリが増えない

通常「空きメモリ」の値は常にゼロに近い傾向にあるので、気にする必要はありません。Linuxカーネルはキャッシュをできるだけ大きく保とうとします。結果として、Linuxカーネルはプロセス終了後もメモリを解放しません。別のプロセスで必要とされる場合にのみ、メモリが解放されます。 

コントローラのプロセスが予期せずシャットダウンする

Linux では、メモリの割り当てに失敗するとコントローラのプロセスが Linux Out-of-Memory（OOM）Killer によって予期せずシャットダウンすることがあります。コントローラログの server.log は、シャットダウンに関する情報を提供しません。このイベントを診断するには、OOM Killer により書き込まれる「out of memory」エントリのシステムログ（通常 /var/log/messages）を確認します。たとえば、以下のようなログがあります。

grep -i "Out of memory" /var/log/messages

このログエントリを見つけたら、コントローラマシンに十分なスワップスペースを割り当てていることを確認してください。AppDynamics では 10 GB 以上のスワップスペースの割り当てを推奨しています。  

コントローラサーバーのスワップが頻繁に起こる

コントローラマシンで予期せぬスワップが起こる場合、swappiness パラメータを構成することでオペレーティングシステムがどの程度の頻度でスワップを行うかを設定できます。swappiness パラメータは、Linux カーネルがプロセスを物理メモリからスワップディスクへ移動させる頻度をコントロールします。パラメータのデフォルト値は通常 60 になっています。この値を減らすと、オペレーティングシステムがスワップする頻度を抑えられます。これにより、デフォルトのファイルキャッシュが少なくなります。

swappiness パラメータの推奨値についてはお使いの Linux ディストリビューションのドキュメントを参照してください。たとえば、RedHat では、CentOS と RedHat カーネルバージョン 2.6.32-303 以降については、スワップスペースが利用可能であっても OOM 問題が起こる場合、swappiness を 10 に設定するよう推奨されています。 

swappiness パラメータを構成する前に、マシンに十分な RAM があり、MySQL のバッファプールサイズが適切に構成されていることを確認してください。

swappinessを構成するには

  1. swappiness の現在の値を確認します。

    /sbin/sysctl -a | grep swappiness
    BASH

  2. swappiness パラメータを設定します。

    たとえば、swappiness パラメータを 10 に設定するには次の行を追加します。


    echo 10 &gt; /proc/sys/vm/swappiness
    BASH

  3. /etc/sysctl.conf ファイルの swappiness パラメータをステップ 2 で使用した値に設定します。

    たとえば、次の行を /etc/sysct1.conf ファイルに追加します。


    vm.swappiness = 10
    BASH

インストール中にこのホストのIPアドレスを確認できないエラー

インストール中にユーザが入力したホスト名または IP アドレスを使用して、Enterprise Console はコントローラに対して ping を試行します。ユーザの入力照合中に ping が失敗すると、「Could not determine the IP address of this host. Please ensure that the IP address of the Controller host resolves to its hostname or to localhost. You may need to add an entry in the hosts file on the Controller host and retry the operation.」というエラーメッセージが表示されます。 

ホスト名を解決するには、コントローラをインストールしているマシンのホストファイルにエントリを追加します。Linux では、ホストファイルは通常 /etc/hosts にあります。Windows の場合は、C:\Windows\System32\Drivers\etc\hosts またはご使用の Windows バージョンの該当する場所でファイルを探してください。

次の例の形式でエントリを追加します。

127.0.0.1 localhost myhostname

システムに適したIPアドレスとホスト名を使用してください。

以下に、デフォルトのRedHatホストファイルの3行目として追加するエントリの例を示します。

127.0.0.1    localhost.localdomain localhost
::1          localhost6.localdomain6 localhost6
198.51.100.2 myhost myhost.example.org

コントローラがMySQLデータベースに接続できない

次のserver.logファイルの例外メッセージは、コントローラが埋め込み型のデータベースに接続できないことを示しています。

*Server log exception:* "Caused by: java.net.ConnectException: Connection refused"

このエラーが起こった場合は、コントローラのデータベースが適切に実行されていることを確認してください。Linuxでは、次のコマンドのいずれかを使用して確認できます。

Linux

Windows

説明

lsof -i:3388

SysInternals Process Explorer は、PID が 3388 のプロセスによって開かれたファイルの一覧を提供します。

PID が 3388 のプロセスによって開かれたオープンファイルを一覧にします。

netstat -anp | grep 3388

netstat -ano | find "3388"

PID が 3388 のプロセスによって開かれたすべてのネットワークポートを一覧にします。

ps -aef | grep mysql

tasklist /v | find "mysql"

すべてのプロセスを一覧にし、「mysql」という名前のプロセスがアクティブかつ有効であることを確認します。

プロセスが見つからない場合、コントローラデータベースが正しく終了されなかったことを示しています。コントローラデータベースを再起動し、コントローラの server.log ファイルでエラーメッセージを確認します。 

Windowsでのコントローラのインストール時にスタックオーバーフローの例外が発生する

この例外は、通常 [-Xss] オプションを低い値に設定している時に起こります。この値を96000に変更することを推奨します。

コントローラログの自動収集のトリガー

コントローラログファイルの自動キャプチャをトリガーするには、次のコンソールコマンドを使用します。

  • Linuxでは次のコマンドを実行します。

    bin/platform-admin.sh submit-job --platform-name test --service controller --job retrieve-log

  • Windows では、管理者特権でのコマンドプロンプトを開き（Windows のスタートメニューでCommand Promptアイコンを右クリックし、[Run as Administrator] を選択）、次のコマンドを実行します。

    bin/platform-admin.exe cli submit-job --platform-name test --service controller --job retrieve-log

    ログは、platform-admin/logs-controller-<platform-name>-<date-time-stamp>.zip にある Enterprise Console のホストにコピーされます。

コントローラログの管理方法の詳細については、「プラットフォームログファイル」を参照してください。

コントローラのトラブルシューティング情報の収集

コントローラのトラブルシューティングのサポートケースを作成する場合、以下の情報を提供していただくと、問題の診断が容易になります。

  • すべての platform-admin/logs/* および platform-admin/logs-controller-*.zip、特に server.log ファイルを送信します。また、「コントローラログの自動収集のトリガー」で説明されているログファイルユーティリティを使用してログを収集することもお勧めします。 
  • コントローラは、メモリが不足するとヒープダンプを生成します。<controller_home>/appserver/glassfish/domains/domain1/config/hprof のすべてのファイルを送信します。
  • すべての <controller_home>/appserver/glassfish/domains/domain1/config/gc.log ファイルを送信します。
  • オペレーティングシステム、ビットバージョン、CPUコア、クロックスピード、ディスク構成、RAMなど、現在コントローラをホストしているマシンのハードウェアとオペレーティングシステム構成に関する情報を送信します。

  • コントローラのパフォーマンスプロファイルを示してください。コントローラの診断コマンドを実行して、platform-admin-server.log に情報を記録します。

    bin/platform-admin.sh submit-job --platform-name <platform_name> --job diagnosis --service controller
    BASH 
    bin/platform-admin.exe cli submit-job --platform-name <platform_name> --job diagnosis --service controller
    BASH

    platform-admin-server.log でコントローラの診断データを確認してください。「高可用性デプロイの管理」ページのサンプルコントローラの診断データを参照してください。

コントローラ4.5へのアップグレード直後に監査レポートを生成できない

コントローラのアップグレードが完了しても、監査レポートはすぐには機能しません。監査データベーステーブルが移行されるのはアップグレードプロセスの後のみで、移行の完了に1時間以上かかります。移行プロセスの完了前に監査レポートを実行すると、server.log ファイルに監査テーブル移行メッセージが記録されます。

特別な対処は不要です。1時間後にもう一度監査レポートを実行してください。