プラットフォーム ログ ファイルには、以下が含まれます。

  • platform-admin-server.log：抽出、準備、その他の後処理タスクなど、インストールプロセスのイベントに関する情報。<platform_admin_home>/logs にあります。
  • server.log：コントローラが使用する埋め込み Jetty アプリケーションサーバーの情報。<controller_home>/logs にあります。
  • audit.log：アカウント/ユーザー/グループ/ロールの CRUD およびユーザーのログイン/ログアウト/SSH 接続などの操作に関する情報。監査可能なイベントをコントローラから中央ログ管理システムまたは SIEM に転送するために使用できます。<controller_home>/logs にあり、Controller Audit Report が複製されます。 
  • database.log：コントローラが使用する MySQL データベースの情報。<controller_home>/db/logs にあります。
  • startAS.log：コントローラの基礎となる Jetty ドメインにより生成される出力。
  • orcha-modules.log：インストール中に実行されるすべてのタスクとコマンドに関する情報。platform-admin-server.log には、実行されたタスクに関する高レベルの情報が含まれています。ただし、orcha-modules.log には、特定のコマンドおよび出力に関する追加情報が含まれています。<platform-dir>/orcha/<version>/orcha-modules/logs/orcha-modules.log にあります。

ログファイルの取得

Enterprise Consoleを使用して、コントローラおよびイベントサービスのログファイルを取得することができます。[Controller] または [Events Service] ページで、[More] オプションを展開し、[Retrieve Log] をクリックして Retrieve Log ジョブを開始します。ジョブが正常に完了すると、AppServer、レポートサービス、および DB ログを含むコントローラまたはイベントサービスのログファイルが取得され、zip ファイルとして Enterprise Console ホストの /home/appdynamics/appdynamics/platform/platform-admin に保存されます。

また、Enterprise Consoleホストで次のコマンドを実行することもできます。

bin/platform-admin.sh submit-job --service <controller or events-service> --job retrieve-log --platform-name <name_of_the_platform>

ログファイルの管理

ログローテーションを設定し、保持期間を調整することで、ログファイルを管理することができます。

ログローテーション

アプリケーションサーバーは、ドメイン設定ファイルの設定に基づいて、server.log ファイルを定期的にローテーションするように事前設定されています。

database.log や audit.log などのその他のログファイルについては、過剰にディスク領域を消費しないようログローテーションの設定が必要になることがあります。特に audit.log ファイルは、1 分ごとに発生するコントローラおよびイベントサービスホストへの SSH 接続が含まれるため、短時間でサイズが大きくなる可能性があります。また、追加のログファイル <controller_home>/db/data/slow.log のログローテーションも設定する必要があります。このログには、遅いMySQLクエリに関する情報が含まれます。

ローテーションの実行に使用するツールは、オペレーティングシステムにより異なります。Linux では、mysql-log-rotate スクリプトを使用します。このスクリプトは、コントローラデータベースのインストール時に <controller_home>/db/support-files に含まれます。デフォルトで database.log ファイルをローテーションするようには設定されていないため、ご使用の環境に応じてスクリプトを変更する必要があります。他のシステムではログのローテーションを実行し、cronや同等のタスクスケジューラなど、定期的に実行するスクリプトを作成またはインストールする必要があります。

保持期間

platfom-admin/logs の Enterprise Console ログは、サイズが大きくなりすぎると、日時スタンプ付きの .gz 形式で自動的にアーカイブされます。アーカイブされる各ログのサイズは、およそ 300 KB です。logs ディレクトリには、最近の 7 つのファイルのみがアーカイブされます。

アーカイブされたログをより長期間保持する場合、Dropwizard 構成ファイル PlatformAdminApplication.yml で設定を構成できます。logging/appenders/type: file セクションで、より大きな archivedFileCount および maxFileSize を指定する必要があります。詳細については、「ドロップウィザード設定リファレンス」を参照してください。

コントローラログのデフォルトの場所または名前の変更

  1. 次のプロパティを編集して、start.ini の新しい場所を設定します。

    -Dcom.appdynamics.controller.logs.dir=<New log location>

    存在しないディレクトリを指定する場合、アプリケーションサーバーを再起動した時点で作成されます。

  2. <controller_home>/db/db.cnf ファイルを開き、database.log の場所を変更します。また、Enterprise Console GUI の [Database Configurations] ページから db.cnf ファイルを変更することもできます。それにより、データベースサーバーが再起動されます。

    これらの構成を変更すると、Enterprise Consoleでバックアップが取得されます。

  3. log-error プロパティの値を database.log ファイルの新しい場所に設定します。コントローラを再起動する前に、このディレクトリの場所が存在することが必要です。存在しないと起動エラーが発生します。

  4. 必要に応じて、デフォルトのディレクトリ（<controller_home>/logs）から新しい場所に既存のログをコピーします。

  5. コントローラを再起動します。コントローラの起動または停止を参照してください。

  6. server.log ファイルが新しい場所に書き込まれていることを確認し、古いログファイルを削除します。database.log の場所は、controller_home>/db/logs/database.log です。

ログレベルの細分性

コントローラログには、コントローラの操作で発生する可能性のあるエラーについての情報が表示されます。デフォルトでは、コントローラは INFO レベルでログに書き込みます。コントローラのデプロイをデバッグする際は、追加情報を生成するためにログレベルを上げる必要があります。

コントローラコンポーネントごとに、以下のログレベルを設定できます。

  • エージェント
  • ビジネストランザクション（BTS）
  • イベント
  • インシデント
  • インフォメーションポイント（IPS）
  • メトリック
  • オーケストレーション
  • ルール
  • スナップショット

コンポーネント別デフォルトのログレベルの変更

デフォルトでは、コントローラはINFOレベルでログを生成します。1つまたはすべてのコンポーネントのレベルを変更できます。これはたとえばシステムをデバッグする際に、コントローラがログという形式でより多くの情報を生成したい場合などに必要になることがあります。一方で、ログファイルの増加を最小限にするため、ログの冗長性を減らすことをお勧めします。次の手順では、デフォルトのログレベルを変更する方法について説明します。

  1. コントローラを展開したサーバーにログインします。

  2. <controller_home>/appserver/jetty/resources/logback.xml ファイルに移動します。
    デフォルトでは、ログレベルの変更は再起動なしで数分以内に適用されます。

  3. 必要なロガーを変更し、ファイルを保存します。「Logback Configuration」を参照してください。
    たとえば、com.hibernate logger を変更する場合は、次のように更新します。

    <logger name="com.hibernate" level="DEBUG"/>
    CODE