AEM インスタンスの監視および保守

AEM インスタンスがデプロイされた後は、操作、パフォーマンス、統合性を監視および保守するために、一定の作業が必要になります。

ここで重要なのは、潜在的な問題を認識するために、通常の状態におけるシステムの外観や動作を知っておく必要があるということです。最善の方法は、システムを一定期間にわたって監視し、情報を収集することです。

チェック項目 検討事項 注釈/アクション
バックアップ計画 インスタンスのバックアップ方法を参照してください。
障害回復計画 各社の障害回復ガイドライン。
問題を報告するためのエラー追跡システムが利用可能であること 例えば、bugzillajira、その他多数のうちいずれか。
ファイルシステムが監視されていること ディスクの空き容量が不十分な場合、CRX リポジトリは「フリーズ」します。容量が利用可能になると再開します。 " *ERROR* LowDiskSpaceBlocker" messages can be seen in the log file when free space becomes low.
ログファイルが監視されていること
システム監視がバックグラウンドで(一貫して)実行されていること CPU、メモリ、ディスクおよびネットワークの使用状況を含みます。例えば、iostat、vmstat、perfmon を使用します。 ログに記録されたデータを可視化して、パフォーマンス問題の追跡に使用できます。生のデータにもアクセスできます。
AEM パフォーマンスが監視されていること トラフィックレベルを監視する要求カウンターを含みます。 重大な、または長期にわたるパフォーマンスの損失が見られる場合は、詳細な調査をする必要があります。
レプリケーションエージェントを監視していること。
ワークフローインスタンスを定期的にパージすること リポジトリのサイズとワークフローのパフォーマンス。 ワークフローインスタンスの定期的なパージを参照してください。

バックアップ

以下のバックアップを取っておくことをお勧めします。

  • ソフトウェアインストール - 設定を大幅に変更した前後
  • リポジトリ内に保持されているコンテンツ - 定期的に

企業で決められているバックアップポリシーがある場合は、それに従う必要があります。何をいつバックアップするかについては、次の点も考慮してください。

  • システムおよびデータの重要度。
  • ソフトウェアまたはデータの変更の頻度。
  • データのボリューム。バックアップの実施に必要な時間と同様に、容量も問題になる場合があります。
  • ユーザーがオンライン中にバックアップを実施できるかどうか。可能な場合は、パフォーマンスへの影響。
  • ユーザーの地理的分布。つまり、バックアップに最適な(影響が最小限に抑えられる)時間帯。
  • 障害回復ポリシー。バックアップデータの格納場所(オフサイト、特定のメディア、など)に関するガイドラインがあるかどうか。

一般的には、完全バックアップを一定の間隔(例:1 日ごと、週ごと、月ごと)でおこない、その合間に増分バックアップをおこないます(例:1 時間ごと、1 日ごと、週ごと)。

注意

実稼動インスタンスのバックアップを実装するときは、バックアップを正常に復元できることを確認するために、テストをおこなう必要があります。

そうしないと、最悪の場合、バックアップが無駄になる可能性があります。

メモ

バックアップのパフォーマンスについて詳しくは、バックアップのパフォーマンスを参照してください。

ソフトウェアインストールのバックアップ

インストール後または設定を大幅に変更した後に、ソフトウェアインストールのバックアップを取ります。

これをおこなうには、リポジトリ全体をバックアップする必要があります。その後、以下の手順を実行します。

  1. AEM を停止します。
  2. Back up the entire <cq-installation-dir> from your file system.
注意

サードパーティ製のアプリケーションサーバーを使用している場合は、追加のフォルダーが別の場所に存在し、そのフォルダーのバックアップも必要になることがあります。アプリケーションサーバーのインストールについて詳しくは、アプリケーションサーバーと共に AEM をインストールする方法を参照してください。

注意

ファイルデータストアの増分バックアップがサポートされています。その他のコンポーネント(Lucene インデックスなど)の増分バックアップを使用する場合は、削除済みのファイルがバックアップでも削除済みとマークされることを確認してください。

メモ

ディスクミラーリングも、バックアップメカニズムとして使用できます。

リポジトリのバックアップ

CRX ドキュメントのバックアップと復元に、CRX リポジトリのバックアップに関連するすべての問題が掲載されています。

オンラインの「ホット」バックアップの作成について詳しくは、オンラインバックアップの作成を参照してください。

バージョンのパージ

バージョンのパージ​ツールは、リポジトリ内のノードまたはノードの階層のバージョンをパージします。このツールの主な目的は、古いバージョンのノードを削除して、リポジトリのサイズを削減することです。

ここでは、AEM のバージョン管理機能に関連するメンテナンス操作について説明します。バージョンのパージ​ツールは、リポジトリ内のノードまたはノードの階層のバージョンをパージします。このツールの主な目的は、古いバージョンのノードを削除して、リポジトリのサイズを削減することです。

概要

バージョンのパージ​ツールは、ツールコンソール​の「バージョン管理」の下か、次の場所にあります。

https://<server>:<port>/etc/versioning/purge.html

screen_shot_2012-03-15at14418pm

開始パス :削除を実行する必要がある絶対パスです。 リポジトリツリーナビゲーターをクリックして、開始パスを選択できます。

再帰 :データを削除する場合は、「再帰」を選択して、1つのノードで操作を実行するか、階層全体で操作を実行するかを選択できます。 最後のケースでは、指定されたパスが階層のルートノードを定義します。

保持する最大バージョン :ノードで保持する最大バージョン数です。 この値を超えると、最も古いバージョンは削除されます。

Maximum version age :ノードのバージョンの最大経過時間。 バージョンの有効期間がこの値を超えると、そのバージョンは削除されます。

ドライ作動 :バックアップを復元しないと、コンテンツの削除バージョンは確定されており、元に戻すことができないため、Purge Versionsツールではドライ作動モードを使用して、削除されたバージョンをプレビューできます。 パージ処理のドライ実行を開始するには、「ドライ実行」(Dry Run)をクリックします。

Purge :開始パスで定義されたノード上のバージョンの削除を開始します。

Web サイトのバージョンのパージ

Web サイトのバージョンをパージするには、次の手順を実行します。

  1. ツールコンソール​に移動して、「バージョン管理」を選択し、「バージョンのパージ」をダブルクリックします。

  2. Set the start path of the content to be purged (e.g. /content/geometrixx-outdoors).

    • パスで定義したノードのみをパージする場合は、「繰り返し」の選択を解除します。
    • パスで定義したノードおよびその下位のノードをパージする場合は、「繰り返し」を選択します。
  3. 保持するバージョンの最大数(ノードごと)を設定します。この設定を使用しない場合は、空のままにします。

  4. 保持するバージョンの最長有効期間(ノードごと)を日数で設定します。この設定を使用しない場合は、空のままにします。

  5. ドライラン」をクリックして、パージプロセスによる処理をプレビューします。

  6. パージ」をクリックして処理を開始します。

注意

パージされたノードを元に戻すには、リポジトリを復元するしかありません。設定は自己管理する必要があるので、パージの前に必ずドライランを実行することをお勧めします。

コンソールの分析

ドライラン」と「パージ」の処理では、処理されたすべてのノードがリストされます。処理の間、ノードのステータスは次のうちいずれかになります。

  • ignore (not versionnable):このノードはバージョン管理をサポートしていないので、プロセス中は無視されます。

  • ignore (no version):ノードにはバージョンがなく、プロセス中は無視されます。

  • retained:ノードはパージされません。

  • purged:ノードが削除されます。

さらに、コンソールでは、バージョンに関して次のような有益な情報が提供されます。

  • V 1.0:バージョン番号。

  • V 1.0.1*:星マークは、バージョンが最新であることを示します。

  • Thu Mar 15 2012 08:37:32 GMT+0100:バージョンの日付。

例を以下に示します。

  • Shirts のバージョンは、バージョンの期間が 2 日間を超えているので、パージされます。
  • The Tonga Fashions! versions are purged because their number of versions is greater than 5.

global_version_screenshot

監査記録とログファイルの使用

Adobe Experience Manager(AEM)に関連する監査記録とログファイルは、様々な場所にあります。以下では、どこに何があるかについて、概要を説明します。

ログの使用

AEM WCM では詳細なログを記録します。クイックスタートを展開して起動すると、次の場所にログが見つかります。

  • <cq-installation-dir>/crx-quickstart/logs/

  • <cq-installation-dir>/crx-quickstart/repository/

ログファイルのローテーション

ログファイルのローテーションとは、新しいファイルを定期的に作成することでファイルの量を制限するプロセスを指します。 AEMでは、というログファイル error.log が、指定されたルールに従って1日1回回転されます。

  • error.log ァイルの名前は、{original_filename}というパターンに従って変更され .yyyy-MM-ddます。 例えば、2010年7月11日に、現在のログファイルの名前が変更され error.log-2010-07-10、新しいログファイルが作成 error.og されます。

  • 以前のログファイルは削除されないので、古いログファイルを定期的にクリーンアップしてディスクの使用を制限する必要があります。

メモ

AEM をアップグレードする場合は、AEM でこれ以上使用されない既存のログファイルがディスク上に残ることに注意してください。これらは削除しても問題ありません。新しいログエントリはすべて、新しいログファイルに書き込まれます。

ログファイルの検索

様々なログファイルが、AEM をインストールしたファイルサーバー上に保持されます。

  • <cq-installation-dir>/crx-quickstart/logs

    • access.log
      AEM WCM およびリポジトリに対するアクセス要求はすべてここに登録されます。

    • audit.log
      モデレート操作はここに登録されます。

    • error.log
      エラーメッセージ(様々な深刻度レベル)はここに登録されます。

    • ImageServer-<PortId>-yyyy>-<mm>-<dd>.log
      このログは、が有効な場合にのみ使用 Dynamic Media されます。 内部ImageServerプロセスの動作の分析に使用される統計と分析情報を提供します。

    • request.log
      各アクセス要求が、応答と共にここに登録されます。

    • s7access-<yyyy>-<mm>-<dd>.log
      このログは、が有効な場合にのみ使用 Dynamic Media されます。 s7accessログには、およびを介して行われた各リクエストが記録 Dynamic Media され /is/image/is/contentす。

    • stderr.log
      起動時に生成される様々なレベルの重大度のエラー・メッセージを保持します。 デフォルトでは、ログレベルは
      WarningWARN

    • stdout.log
      起動時のイベントを示すログメッセージを保持します。

    • upgrade.log
      Folio Builderから実行されるすべてのアップグレード操作のログが
      com.day.compat.codeupgrade および com.adobe.cq.upgradesexecutor パッケージ

  • <cq-installation-dir>/crx-quickstart/repository

    • revision.log
      改訂ジャーナリング情報。
メモ

system/console/status-Bundlelist ページから生成された​Download Full packageには、ImageServerとs7accessのログは含まれません。 サポートの目的で、問題が発生した場合は、カスタマーサポートに問い合わせる際に、ImageServerログとs7accessログも追加して Dynamic Media ください。

デバッグログレベルのアクティベート

デフォルトのログレベル(Apache Sling Logging Configuration)は情報(INFO)なので、デバッグメッセージはログに記録されません。

ロガーのデバッグログレベルをアクティブにするには、リポジトリでデバッグす org.apache.sling.commons.log.level るプロパティを設定します。 例えば、 /libs/sling/config/org.apache.sling.commons.log.LogManager グローバルApache Slingログを設定す る場合などです

注意

デバッグログレベルのログを、不必要に長く残さないでください。多くのログエントリが生成され、リソースが消費されます。

デバッグファイルの行は、通常は DEBUG で始まり、その後にログレベル、インストーラーのアクション、ログメッセージが示されます。次に例を示します。

DEBUG 3 WebApp Panel: WebApp successfully deployed

ログレベルは次のとおりです。

0 重大なエラー アクションが失敗し、インストーラーの処理を続行できません。
1 エラー アクションが失敗しました。インストールは続行しますが、AEM WCM の一部が正常にインストールされなかったので、機能しません。
2 警告 アクションは成功しましたが、問題が発生しました。AEM WCM は正常に機能する場合と機能しない場合があります。
3 情報 アクションが成功しました。

カスタムログファイルの作成

メモ

Adobe Experience Manager を操作しているときは、このようなサービスの設定を管理する方法がいくつかあります。詳細および推奨事項については、OSGi の設定を参照してください。

状況によっては、別のログレベルでカスタムログファイルを作成する必要があります。これをおこなうには、リポジトリで次の手順を実行します。

  1. 既存のものがない場合は、新しい設定フォルダー(sling:Folder)を、プロジェクト(/apps/<project-name>/config)用に作成します。

  2. Under /apps/<project-name>/config, create a node for the new Apache Sling Logging Logger Configuration:

    • 名前:org.apache.sling.commons.log.LogManager.factory.config-<identifier>(ロガーの場合)

      <identifier> の部分は、インスタンスを識別するフリーテキストに置き換えます(この情報は省略できません)。

      例:org.apache.sling.commons.log.LogManager.factory.config-MINE

    • 型:sling:OsgiConfig

    メモ

    技術的に必須ではありませんが、<identifier> は一意にすることをお勧めします。

  3. このノードで次のプロパティを設定します。

    • 名前:org.apache.sling.commons.log.file

      タイプ:String

      値:ログファイルを指定します。例えば、 logs/myLogFile.log

    • 名前:org.apache.sling.commons.log.names

      タイプ:文字列[] (文字列+複数)

      値:ロガーがメッセージをログに記録するOSGiサービスを指定する。例えば、次のすべての例を示します。

      • org.apache.sling
      • org.apache.felix
      • com.day
    • 名前:org.apache.sling.commons.log.level

      タイプ:String

      値:必要なログレベルを指定します( debuginfowarn または error)。例えば debug

    • 必要に応じてその他のパラメーターを設定します。

      • 名前:org.apache.sling.commons.log.pattern

        型:String

        値:必要に応じて、ログメッセージのパターンを指定します。例えば、

        {0,date,dd.MM.yyyy HH:mm:ss.SSS} *{4}* [{2}] {3} {5}

    メモ

    org.apache.sling.commons.log.pattern では、最大 6 個の引数がサポートされています。

    {0}タイプのタイムスタンプ java.util.Date

    {1}ログマーカー

    {2}現在のスレッドの名前

    {3}ロガーの名前

    {4}ログレベル

    {5}ログメッセージ

    ログ呼び出しに Throwable が含まれている場合は、スタックトレースがメッセージに付加されます。

    注意

    org.apache.sling.commons.log.names には値が必要です。

    メモ

    ログライターのパスは、crx-quickstart の場所と相対的です。

    したがって、ログファイルが

    logs/thelog.log

    と指定されている場合、書き込み先は以下となります。

    <cq-installation-dir>/crx-quickstart/logs/thelog.log.

    また、ログファイルが

    ../logs/thelog.log

    と指定されている場合、書き込み先は以下のディレクトリとなります。

    <cq-installation-dir>/logs/
    (隣 <cq-installation-dir>/crx-quickstart/)

  4. この手順は、新しいライターが必要な場合(つまり、デフォルトのライターとは異なる設定の場合)にのみ必要です。

    注意

    新しい Logging Writer Configuration は、既存のデフォルトが適切でない場合にのみ必要です。

    明示的なライターが設定されていない場合は、デフォルトに基づいて暗黙のライターが自動的に生成されます。

    Under /apps/<project-name>/config, create a node for the new Apache Sling Logging Writer Configuration:

    • Name: org.apache.sling.commons.log.LogManager.factory.writer-<identifier> (as this is a Writer)

      As with the Logger, <identifier> is replaced by free text that you (must) enter to identify the instance (you cannot omit this information). 例:org.apache.sling.commons.log.LogManager.factory.writer-MINE

    • 型:sling:OsgiConfig

    メモ

    技術的に必須ではありませんが、<identifier> は一意にすることをお勧めします。

    このノードで次のプロパティを設定します。

    • 名前:org.apache.sling.commons.log.file

      型:String

      値:ロガーで指定したファイルと一致するようにログファイルを指定します。

      この例では、 ../logs/myLogFile.log

    • 必要に応じてその他のパラメーターを設定します。

      • 名前:org.apache.sling.commons.log.file.number

        型:Long

        Value: specify the number of log files you want kept; for example, 5

      • 名前:org.apache.sling.commons.log.file.size

        型:String

        Value: specify as required to control file rotation by size/date; for example, '.'yyyy-MM-dd

    メモ

    org.apache.sling.commons.log.file.size は、次のいずれかを設定することによって、ログファイルのローテーションを制御します。

    • 最大ファイルサイズ
    • 時刻/日付のスケジュール

    これにより、新しいファイルを作成する(また、名前のパターンに従って既存のファイルを名前変更する)条件を示します。

    • サイズ制限は、数値で指定できます。 サイズインジケーターを指定しない場合は、バイト数と見なされるか、サイズインジケーターの1つ( KBMBまたは GB (大文字と小文字は区別されません)を追加できます。
    • 日時スケジュールは、 java.util.SimpleDateFormat パターンとして指定できます。 これは、ファイルを回転した後の期間を定義します。また、回転したファイルの末尾に付く接尾辞(識別用)。

    デフォルトは「。」です。yyyy-MM-dd(日別ログローテーションの場合)

    例えば、2010年1月20日の真夜中(またはこれ以降の最初のログメッセージが正確である場合)、…/logs/error.logは…/logs/error.log.2010-01-20に名前が変更されます。 1月21日のログは、次の変更時にロールオーバーするまで、(新しい空の)…/logs/error.logに出力されます。

    '.'yyyy-MM 毎月の初めにローテーション。
    '.'yyyy-ww 各週の最初の日のローテーション(ロケールに応じて異なります)。
    '.'yyyy-MM-dd 毎日午前0時にローテーション。
    '.'yyyy-MM-dd-a 毎日午前0時と正午のローテーション。
    '.'yyyy-MM-dd-HH 毎時の上部での回転。
    '.'yyyy-MM-dd-HH-mm 毎分の開始時の回転。

    注意:日時を指定する場合:

    1. 一重引用符(' ')のペア内のリテラルテキストは、「エスケープ」する必要があります。

    これは、特定の文字がパターン文字として解釈されるのを防ぐためです。

    1. 有効なファイル名に使用できる文字は、オプション内の任意の場所に限られます。
  5. 任意のツールで新しいログファイルを読み取ります。

    The log file created by this example will be ../crx-quickstart/logs/myLogFile.log.

Felix コンソールでは、../system/console/slinglog の Sling Log Support に関する情報も提供されます。例えば、https://localhost:4502/system/console/slinglog. です。

監査記録の検索

監査記録は、いつ、誰が、何をしたかの記録を提供するために保持されます。AEM WCM と OSGi の両方のイベントに関して、様々な監査記録が生成されます。

ページオーサリング時に表示される AEM WCM の監査記録

  1. ページを開きます。

  2. サイドキックから、ロックアイコンを含むタブを選択できます。次に、「監査ログ」をダブルクリックします。

  3. 新しいウィンドウが開き、現在のページの監査記録のリストが表示されます。

    screen_shot_2012-02-02at43601pm

  4. ウィンドウを閉じるには、「OK」をクリックします。

リポジトリ内の AEM WCM 監査記録

フォルダ内には、 /var/audit リソースに応じて監査レコードが保持される。 個々のレコードとそのレコードに含まれる情報が表示されるまで、ドリルダウンできます。

これらのエントリに保持されている情報は、ページ編集時に表示される情報と同じです。

Web コンソールの OSGi 監査記録

OSGi イベントで生成される監査記録は、AEM Web コンソールの「設定ステータス」タブ/「ログファイル」タブから確認できます。

screen_shot_2012-02-13at50346pm

レプリケーションエージェントの監視

レプリケーションキューを監視すると、キューのダウンまたはブロックを検出できます。このような場合、パブリッシュインスタンスまたは外部システムに問題がある可能性があります。

  • 必要なキューがすべて有効になっていますか。

  • 無効なキューの中に、まだ必要なものがありますか。

  • enabled(有効な状態)のキューはすべて、ステータスが idle または active であり、これは正常な動作を示します。キューを blocked(ブロック状態)にしてはいけません。ブロックされている場合、多くは受信者側に問題があります。

  • 時間の経過と共にキューのサイズが大きくなる場合は、キューがブロックされている可能性があります。

レプリケーションエージェントを監視するには:

  1. AEM の「ツール」タブにアクセスします。

  2. レプリケーション」をクリックします。

  3. 適切な環境のエージェントへのリンクをダブルクリックします(左右いずれかのウィンドウ)。例えば、「オーサーのエージェント」などです。

    ウィンドウが開き、オーサー環境のすべてのレプリケーションエージェントの概要が、それぞれのターゲットとステータスを含めて表示されます。

  4. 適切なエージェント名(リンク)をクリックして、そのエージェントの詳細情報を表示します。

    chlimage_1

    ここでは、以下のことができます。

    • エージェントが有効かどうかを確認。

    • レプリケーションのターゲットを確認。

    • レプリケーションキューが現在アクティブ(有効)かどうかを確認。

    • キュー内に項目が含まれているかどうかを確認。

    • 更新​または​消去​して、キューエントリの表示を更新。これは、キューに出入りする項目の確認に役立ちます。

    • ログを表示​して、レプリケーションエージェントによるアクションのログにアクセス。

    • ターゲットインスタンスへの​接続をテスト

    • 必要に応じて、任意のキュー項目で​強制的に再試行

    注意

    パブリッシュインスタンスのリバースレプリケーションアウトボックスには、「接続をテスト」リンクは使用しないでください。

    アウトボックスクエリ用にレプリケーションテストが実行されると、リバースレプリケーションのたびに、テストレプリケーションより古い項目がすべて再処理されます。

    そのような項目がキュー内に既に存在する場合は、次の XPath JCR クエリを使用して検索し、削除する必要があります。

    /jcr:root/var/replication/outbox/*[@cq:repActionType='TEST']

Again you can develop a solution to detect all replication agents (located under /etc/replication/author or /etc/replication/publish), then check the status of the agent ( enabled, disabled) and the underlying queue ( active, idle, blocked).

パフォーマンスの監視

パフォーマンスの最適化は、開発時に注目を集めるインタラクティブなプロセスです。デプロイメント後、通常は特定の間隔またはイベントの後でレビューされます。

最適化のための情報収集に使用する方法は、継続中の監視にも使用できます。

メモ

具体的なパフォーマンス向上のための設定も確認できます。

以下のリストは、よく発生するパフォーマンス上の問題と、それぞれの見分け方および対策を示しています。

領域 現象 容量を増やす方法 ボリュームを減らす方法
クライアント クライアントの CPU 使用率が高い。 より高性能のクライアント CPU をインストール。 (HTML)レイアウトを簡素化。
サーバーの CPU 使用率が低い。 より高速なブラウザーにアップグレード。 クライアント側のキャッシュを改善。
高速のクライアントと低速のクライアントがある。
サーバー
ネットワーク サーバーとクライアントの両方で CPU 使用率が低い。 ネットワークのボトルネックを除去。 クライアントキャッシュの設定を改善/最適化。
サーバーのローカルでの参照が(比較的)高速。 ネットワーク帯域幅を増加。 Web ページの「重さ」を軽減(例:画像を減らす、HTML を最適化する)。
Web サーバー Web サーバー上の CPU 使用率が高い。 Web サーバーをクラスター化。 ページごとのヒット数(訪問数)を減らす。
ハードウェアのロードバランサーを使用。
アプリケーション サーバーの CPU 使用率が高い。 AEM インスタンスをクラスター化します。 CPU およびメモリが集中的に使用されている箇所を検索して除去(コードレビュー、タイミング出力などを使用)。
メモリ消費率が高い。 すべてのレベルでキャッシュを改善。
応答時間が遅い。 テンプレートおよびコンポーネント(構造、ロジックなど)を最適化。
リポジトリ
キャッシュ

パフォーマンス問題は、接続速度の一時的低下、CPU の負荷、その他の、Web サイトとは何ら関係のない多くの問題から生じる場合があります。

また、訪問者全員に影響する問題もあれば、一部のみに影響する問題もあります。

この情報をすべて入手し、分類および分析して初めて、一般的なパフォーマンスを最適化したり、特定の問題を解決したりできます。

  • パフォーマンス問題が発生する前の対応:

    • できる限り多くの情報を収集し、正常な状態のシステムに関する十分な実用的知識を構築します。
  • パフォーマンス問題が発生した場合の対応:

    • 1 つ(または 2 つ以上を推奨)の標準的な Web ブラウザー、通常のパフォーマンスが良好であることがわかっている別のクライアント、またはサーバー自体(可能であれば)で、問題を再現します。

    • 適切な時間内に(システムに関連する)何かが変更されたかどうかと、いずれかの変更がパフォーマンスに影響した可能性があるかどうかを確認します。

    • 次の点を確認します。

      • 問題が発生するのは特定の時間のみかどうか。
      • 問題が発生するのは特定のページのみかどうか。
      • その他の要求に影響があるかどうか。
    • できる限り多くの情報を収集し、正常な状態のシステムに関する知識と比較します。

パフォーマンスの監視および分析のツール

パフォーマンスの監視および分析に使用できるツールの一部について、以下で簡単に概要を説明します。

この中には、オペレーティングシステムに依存するものもあります。

ツール 分析対象 使用法/詳細
request.log 応答時間および並行性 request.log の解釈
truss/strace ページの読み込み

システムの呼び出しおよびシグナルをトレースする Unix/Linux コマンド。ログレベルを INFO に上げます。

要求ごとのページの読み込み数、どのページか、などを分析します。

スレッドダンプ JVM スレッドを監視。競合、ロック、長時間の実行を識別。

Dependent on the operating system:
- Unix/Linux: kill -QUIT <pid>
- Windows (console mode): Ctrl-Break

TDA などの分析ツールも使用できます。

ヒープダンプ パフォーマンス低下の原因となるメモリ不足の問題。

Add the:
-XX:+HeapDumpOnOutOfMemoryError
option to the java call to AEM.

Troubleshooting Guide for Java SE 6 with HotSpot VM を参照してください。

システム呼び出し タイミングの問題を識別。

Calls to System.currentTimeMillis() or com.day.util.Timing are used to generate timestamps from your code, or via HTML-comments.

注意: これらを実装するのは、必要に応じてアクティベート/アクティベート解除できるようにするためです。システムが問題なく動作しているときは、統計を収集するオーバーヘッドは不要です。

Apache Bench メモリリークを識別し、応答時間を選択分析。

基本的な使用法は次のとおりです。

ab -k -n <requests> -c <concurrency> <url>

See Apache Bench and the ab man page for full details.

Search Analysis 検索クエリーをオフラインで実行し、クエリーの応答時間を特定して、結果セットをテストおよび確認します。
JMeter 読み込みおよび機能テスト。 https://jakarta.apache.org/jmeter/
JProfiler CPU およびメモリの詳細なプロファイリング。 https://www.ej-technologies.com/
JConsole JVM の指標およびスレッドを監視。

使用法:jconsole

jconsole および JConsole を使用したパフォーマンスの監視 を参照してください。

注意: JDK 1.6 では、Top や TDA(Thread Dump Analyzer)などのプラグインを使用して JConsole を拡張できます。

Java VisualVM JVM の指標、スレッド、メモリおよびプロファイリングを監視。

使用法:jvisualvm または visualvm

jvisualvmvisualvm および(J)VisualVM を使用したパフォーマンスの監視を参照してください。

注意: JDK 1.6 では、プラグインを使用して VisualVM を拡張できます。

truss/strace、lsof 詳細なカーネル呼び出しおよびプロセス分析(Unix)。 Unix/Linux コマンド。
タイミングの統計 ページレンダリングのタイミングの統計を確認。

To see timing statistics for page rendering you can use Ctrl-Shift-U together with ?debugClientLibs=true set in the URL.

CPU およびメモリプロファイリングツール
開発中に低速の要求を分析する際に使用 例えば、YourKit などです。
情報収集 インストールの進行中のステータス。 インストールについてできる限り知っておくことは、パフォーマンスの変化の原因や、変化が正当かどうかを追跡する上でも役立ちます。これらの指標を一定の間隔で収集し、重大な変化を簡単に確認できるようにする必要があります。

request.log の解釈

このファイルには、AEM に対するあらゆるリクエストに関する基本情報が登録されています。このことから、貴重な結論を引き出すことができます。

リクエストの所要時間を調べるための request.log オファーーの組み込み。 開発のために、応答時間が遅い場合は、を使用 tail -frequest.log て監視すると便利です。 より大きな値を分析する request.log には、応答時間の並べ替えとフィルターを可能にする、 を使用する rlog.jar ことをお勧めします

「遅い」ページをと分離し、パフォーマンスを向上させるた request.logめにそれらを個別に調整することをお勧めします。 これは、通常、コンポーネントごとのパフォーマンス指標を含めるか、などのパフォーマンスプロファイルツールを使用して行い [yourkit](https://www.yourkit.com/)ます。

Web サイトでのトラフィックの監視

request.log は、実行される各要求を、応答と共に登録します。

09:43:41 [66] -> GET /author/y.html HTTP/1.1
09:43:41 [66] <- 200 text/html 797ms

特定の期間内の(例えば 24 時間の監視を何度かおこなって)すべての GET エントリを合計することにより、Web サイトの平均トラフィックを把握できます。

request.log での応答時間の監視

パフォーマンス分析は、request.log から始めることをお勧めします。

<cq-installation-dir>/crx-quickstart/logs/request.log

ログは次のようになっています(簡潔にするために、各行を短縮しています)。

31/Mar/2009:11:32:57 +0200 [379] -> GET /path/x HTTP/1.1
31/Mar/2009:11:32:57 +0200 [379] <- 200 text/html 33ms
31/Mar/2009:11:33:17 +0200 [380] -> GET /path/y HTTP/1.1
31/Mar/2009:11:33:17 +0200 [380] <- 200 application/json 39ms

このログには、要求または応答ごとに 1 行ずつの構成になっています。

  • 要求または応答がおこなわれた日付。

  • 要求の番号(角括弧内)。この番号は、要求と応答で一致しています。

  • 矢印は、要求(右向き矢印)か応答(左向き矢印)かを示しています。

  • 要求の行には、以下が含まれます。

    • メソッド(通常は GET、HEAD または POST)
    • 要求されたページ
    • プロトコル
  • 応答の行には、以下が含まれます。

    • ステータスコード(200 は「成功」、404 は「ページが見つかりません」)
    • MIME タイプ
    • 応答時間

サイズの小さいスクリプトを使用して、ログファイルから必要な情報を抽出し、必要な統計を取ることができます。これらの統計から、どのページ、またはどんなタイプのページが低速か、全体的なパフォーマンスが十分かどうかを確認できます。

request.log での検索応答時間の監視

検索要求は常にログファイルに登録されます。

31/Mar/2009:11:35:34 +0200 [338] -> GET /author/playground/en/tools/search.html?query=dilbert&size=5&dispenc=utf-8 HTTP/1.1
31/Mar/2009:11:35:34 +0200 [338] <- 200 text/html 1562ms

したがって、上記のように、スクリプトを使用して関連する情報を抽出し、統計を取ることができます。

ただし、応答時間を確認したら、その要求になぜそれだけの時間がかかっているのか、応答を改善するために何ができるかに関する分析が必要になる場合があります。

現在のユーザーの数と影響の監視

ここでも、request.log を使用して、並行性およびそれに対するシステムの反応を監視できます。

テストを実施して、悪影響なくシステムが処理できる同時ユーザーの数を特定する必要があります。ここでも、スクリプトを使用してログファイルから結果を抽出できます。

  • 特定の期間(1 分間など)内におこなわれる要求の数を監視します。
  • 特定の数のユーザー全員がほぼ同時に同じ要求をおこなった場合の影響をテストします(例えば、30 人のユーザーが同時に「保存」をクリックするなど)。
31/Mar/2009:11:45:29 +0200 [333] -> GET /author/libs/Personalize/content/statics.close.gif HTTP/1.1
31/Mar/2009:11:45:29 +0200 [334] -> GET /author/libs/Personalize/content/statics.detach.gif HTTP/1.1
31/Mar/2009:11:45:30 +0200 [335] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTpCxyuBNiTCoiBMmw000.default.gif HTTP/1.1
31/Mar/2009:11:45:32 +0200 [335] <- 304 text/html 0ms
31/Mar/2009:11:45:33 +0200 [334] <- 200 image/gif 31ms
31/Mar/2009:11:45:38 +0200 [333] <- 200 image/gif 31ms
31/Mar/2009:11:45:42 +0200 [336] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTZRXunQbbQtvuuCMbRRBuWXz0000.default.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [337] -> GET /author/titlebar_bg.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [336] <- 304 text/html 0ms
31/Mar/2009:11:45:44 +0200 [337] <- 304 text/html 0ms

rlog.jar を使用した所要時間の長い要求の検索

AEM includes various helper tools located in:
<cq-installation-dir>/crx-quickstart/opt/helpers

その 1 つ、rlog.jar を使用すると、request.log を短時間で分類し、所要時間を基準として、最長から最短の順序で要求を表示できます。

次のコマンドは、考えられる引数を示しています。

$java -jar rlog.jar
Request Log Analyzer Version 21584 Copyright 2005 Day Management AG
Usage:
  java -jar rlog.jar [options] <filename>
Options:
  -h               Prints this usage.
  -n <maxResults>  Limits output to <maxResults> lines.
  -m <maxRequests> Limits input to <maxRequest> requests.
  -xdev            Exclude POST request to CRXDE.

例えば、request.log ファイルをパラメーターとして指定してコマンドを実行し、所要時間が長いほうから 10 個の要求を表示することができます。

$ java -jar ../opt/helpers/rlog.jar -n 10 request.log
*Info * Parsed 464 requests.
*Info * Time for parsing: 22ms
*Info * Time for sorting: 2ms
*Info * Total Memory: 1mb
*Info * Free Memory: 1mb
*Info * Used Memory: 0mb
------------------------------------------------------
     18051ms 31/Mar/2009:11:15:34 +0200 200 GET /content/geometrixx/en/company.html text/ html
      2198ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/cq/widgets.js application/x-javascript
      1981ms 31/Mar/2009:11:15:11 +0200 200 GET /libs/wcm/content/welcome.html text/html
      1973ms 31/Mar/2009:11:15:52 +0200 200 GET /content/campaigns/geometrixx.teasers..html text/html
      1883ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/security/cq-security.js application/x-javascript
      1876ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets.js application/x-javascript
      1869ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets/themes/default.js application/x-javascript
      1729ms 30/Mar/2009:16:45:56 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8
      1510ms 31/Mar/2009:11:15:34 +0200 200 GET /bin/wcm/contentfinder/asset/view.json/ content/dam?_dc=1238490934657&query=&mimeType=image&_charset_=utf-8 application/json
      1462ms 30/Mar/2009:17:23:08 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8

大容量のデータサンプルに関してこの処理をおこなう必要がある場合は、個々の request.log ファイルを連結する必要があります。

Apache Bench

特殊なケース(ガベージコレクションなど)の影響を最小限にするために、apachebench(詳細なドキュメントについては ab などを参照)などのツールを使用してメモリリークを特定し、応答時間を選択分析することをお勧めします。

Apache Bench は次の方法で使用できます。

$ ab -c 5 -k -n 1000 "https://localhost:4503/content/geometrixx/en/company.html"
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, https://www.zeustech.net/
Licensed to The Apache Software Foundation, https://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software: Day-Servlet-Engine/4.1.52
Server Hostname: localhost
Server Port: 4503

Document Path: /content/geometrixx/en/company.html
Document Length: 24127 bytes

Concurrency Level: 5
Time taken for tests: 69.766 seconds
Complete requests: 1000
Failed requests: 998
(Connect: 0, Receive: 0, Length: 998, Exceptions: 0)
Write errors: 0
Keep-Alive requests: 0
Total transferred: 24160923 bytes
HTML transferred: 24010923 bytes
Requests per second: 14.33 /sec (mean)
Time per request: 348.828 [ms] (mean)
Time per request: 69.766 [ms] (mean, across all concurrent requests)
Transfer rate: 338.20 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 3.9 0 58
Processing: 138 347 568.5 282 8106
Waiting: 137 344 568.1 281 8106
Total: 139 348 568.4 283 8106

Percentage of the requests served within a certain time (ms)
50% 283
66% 323
75% 356
80% 374
90% 439
95% 512
98% 1047
99% 1132
100% 8106 (longest request)

上記の数字は、デフォルトの AEM インストールに含まれている、geometrixx の会社ページにアクセスする標準の MAcBook Pro ラップトップ(2010 年半ば)から取得されたものです。このページは非常に単純ですが、パフォーマンスが最適化されていません。

apachebench また、すべての同時要求に対するリクエストあたりの時間を平均として表示します。「 Time per request: 54.595 [ms] (つまり、すべての同時要求に対して)」を参照してください。 concurrencyパラメーターの値 -c (一度に実行する複数の要求の数)を変更して、任意の効果を確認できます。

要求カウンター

要求トラフィックに関する情報(特定の期間の要求数)により、インスタンスの負荷の目安がわかります。この情報は request.log から抽出できますが、カウンターを使用すると、データ収集を自動化し、以下の情報を確認できます。

  • アクティビティの大きな相違点(「多数の要求」と「少ないアクティビティ」を区別)
  • インスタンスが使用されていない時間帯
  • 再起動(カウンターが 0 にリセット)があるかどうか

情報収集を自動化するには、RequestFilter をインストールして、要求がおこなわれるたびにカウンターの数値を増やすこともできます。複数のカウンターを様々な期間に使用できます。

収集された情報を使用して、以下の内容を示すことができます。

  • アクティビティの大きな変化
  • 冗長なインスタンス
  • 再起動(カウンターが 0 にリセット)があるかどうか

HTML Comments

すべてのプロジェクトに、サーバーのパフォーマンスを考慮し html comments た内容を含めることをお勧めします。 良い例がたくさん見つかる。ページを選択し、表示するページソースを開き、下までスクロールします。次のようなコードが表示されます。

</body>
 </html>
        <!--
        Page took 58 milliseconds to be rendered by server
         -->

Monitoring Performance using JConsole

ツールコマンド jconsole を、JDK で使用できます。

  1. AEM インスタンスを起動します。

  2. 実行 jconsole.

  3. AEM インスタンスを選択して「接続」をクリックします。

  4. Local アプリケーション内から、com.day.crx.quickstart.Main をダブルクリックします。「概要」がデフォルトで表示されます。

    chlimage_1-1

    この後、他のオプションを選択できます。

Monitoring Performance using (J)VisualVM

JDK 1.6以降では、toolコマンドを使用 jvisualvm できます。 JDK 1.6をインストールすると、次の操作を実行できます。

  1. AEM インスタンスを起動します。

    メモ

    Java 5を使用している場合は、JVMを開始するJavaコマンドラインに -Dcom.sun.management.jmxremote 引数を追加できます。 JMXは、Java 6によりデフォルトで有効になります。

  2. 次のいずれかを実行します。

    • jvisualvm:JDK 1.6 bin フォルダー内(テスト済みバージョン)
    • visualvmVisualVM からダウンロードできます(最先端バージョン)
  3. Local アプリケーション内から、com.day.crx.quickstart.Main をダブルクリックします。「概要」がデフォルトで表示されます。

    chlimage_1-2

    この後、「監視」など、他のオプションを選択できます。

    chlimage_1-3

このツールを使用すると、スレッドダンプおよびメモリヘッドダンプを生成できます。これは、テクニカルサポートチームから要求されることの多い情報です。

情報収集

インストールについてできる限り知っておくことは、パフォーマンスの変化の原因や、変化が正当かどうかを追跡する上で役立ちます。これらの指標を一定の間隔で収集し、重大な変化を簡単に確認できるようにする必要があります。

有益な情報を以下に示します。

システムで作業をしている作成者の数

インストール以降にシステムを使用した作成者の数を確認するには、次のコマンドラインを使用します。

cd <cq-installation-dir>/crx-quickstart/logs
cut -d " " -f 3 access.log | sort -u | wc -l

特定の日付に作業をしている作成者の数を確認するには、以下を使用します。

grep "<date>" access.log | cut -d " " -f 3 | sort -u | wc -l

1 日あたりのページアクティベーションの平均数

サーバーのインストール以降のページアクティベーションの合計数を確認するには、リポジトリクエリを使用します。CRXDE のツール/クエリで、次のように指定します。

  • XPath

  • パス /

  • クエリ /element(*, cq:AuditEvent)[@cq:type='Activate']

その後、インストール以降の経過日数を計算し、平均を計算します。

このシステムで現在保守しているページ数

現在サーバー上にあるページの数を確認するには、リポジトリクエリを使用します。CRXDE のツール/クエリで、次のように指定します。

  • XPath

  • パス /

  • クエリ /element(*, cq:Page)

MSM を使用する場合は、1 ヶ月あたりのロールアウトの平均数

インストール以降のロールアウトの合計数を特定するには、リポジトリクエリを使用します。CRXDE のツール/クエリで、次のように指定します。

  • XPath

  • パス /

  • クエリ /element(*, cq:AuditEvent)[@cq:type='PageRolledOut']

インストール以降の経過月数を計算し、平均を計算します。

1 ヶ月あたりのライブコピーの平均数

インストール以降におこなわれたライブコピーの合計数を特定するには、リポジトリクエリを使用します。CRXDE のツール/クエリで、次のように指定します。

  • XPath

  • パス /

  • クエリ /element(*, cq:LiveSyncConfig)

ここでも、インストール以降の経過月数を使用して、平均を計算します。

AEM Assets を使用する場合は、Assets で現在保守しているアセットの数

現在保守している DAM アセットの数を確認するには、リポジトリクエリを使用します。CRXDE のツール/クエリで、次のように指定します。

  • XPath
  • パス /
  • クエリ /jcr:root/content/dam/element(*, dam:Asset)

アセットの平均サイズ

To determine the total size of the /var/dam folder:

  1. WebDAV を使用して、 リポジトリをローカルファイルシステムにマップします。

  2. 次のコマンドラインを使用します。

    cd /Volumes/localhost/var
    du -sh dam/
    

    To get the average size, divide the global size by the total number of assets in /var/dam (obtained above).

現在使用されているテンプレートの数

現在サーバー上にあるテンプレートの数を確認するには、リポジトリクエリを使用します。CRXDE のツール/クエリで、次のように指定します。

  • XPath
  • パス /
  • クエリ /element(*, cq:Template)

現在使用されているコンポーネントの数

現在サーバー上にあるコンポーネントの数を確認するには、リポジトリクエリを使用します。CRXDE のツール/クエリで、次のように指定します。

  • XPath
  • パス /
  • クエリ /element(*, cq:Component)

ピーク時のオーサーシステムの 1 時間あたりの要求数

ピーク時のオーサーシステムの 1 時間あたりの要求数を特定するには:

  1. インストール以降の要求の合計数を特定するには、次のコマンドラインを使用します。

    cd <cq-installation-dir>/crx-quickstart/logs
    grep -R "\->" request.log | wc -l
    
  2. 開始日と終了日を特定するには、以下を使用します。

    vim request.log
    G / 1G: for the last/first lines
    

    これらの値を使用して、インストール以降の経過時間数、さらに 1 時間あたりの要求の平均数を計算します。

ピーク時のパブリッシュシステムの 1 時間あたりの要求数

パブリッシュインスタンスで上記の手順を繰り返します。

具体的なシナリオの分析

以下は、特定のパフォーマンス問題が発生しはじめた場合にチェックするべきことの提案リストです。リストは(残念ながら)完全に網羅的ではありません。

CPU 使用率が 100 %

システムの CPU が常に 100 %で動作している場合は、以下を参照してください。

Out of Memory

このようなエラーは開発およびテストの段階で検出されるべきですが、特定のシナリオが見落とされる可能性もあります。

システムがメモリ不足になっている場合、パフォーマンスの低下や、次のサブテキストを含むエラーメッセージなど、様々な方法で確認できます。

java.lang.OutOfMemoryError

このような場合は、以下をチェックします。

ディスク I/O

システムがディスク容量不足になっている場合や、ディスクスラッシングが始まっていることに気付いた場合は、以下を参照してください。

通常のパフォーマンス低下

リブートのたびにインスタンスのパフォーマンスの低下が確認される場合(場合によって 1 週間後またはそれ以降)は、以下を確認できます。

JVM のチューニング

Java 仮想マシン(JVM)のチューニング機能は大幅に改善されています(特に Java 7 以降)。したがって、ある程度の固定の JVM サイズを指定し、デフォルトを使用すれば、たいていの場合に対応できます。

デフォルト設定が適切でない場合は、GC パフォーマンスを監視および査定する方法を確立してから JVM のチューニングを試みることが重要です。これには、ヒープサイズ、アルゴリズム、その他の局面を含む要因の監視が必要になる場合があります。

一般的な選択肢は以下のとおりです。

  • VerboseGC:

    -verbose:gc \
     -Xloggc:$LOGS/verbosegc.log \
     -XX:+PrintGCDetails \
     -XX:+PrintGCDateStamps
    

結果のログは、次のような GC 可視化機能によって取り込み可能です。

[https://www.ibm.com/developerworks/library/j-ibmtools2/](https://www.ibm.com/developerworks/library/j-ibmtools2/)

JConsole の場合は以下のとおりです。

  • 以下の設定は、「ワイドオープン」JMX接続用です。

    -Dcom.sun.management.jmxremote \
     -Dcom.sun.management.jmxremote.port=8889 \
     -Dcom.sun.management.jmxremote.authenticate=false \
     -Dcom.sun.management.jmxremote.ssl=false
    
  • 次に、JConsoleを使用してJVMに接続します。参照:
    [https://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html](https://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html)

これは、使用されているメモリ量、使用されているGCアルゴリズム、実行に要する時間、およびアプリケーションのパフォーマンスに与える影響を確認するのに役立ちます。これを使わないと、調整は単に「ランダムにタワタ動くノブ」になる。

メモ

Oracle の VM に関しては、以下にも情報があります。

https://docs.oracle.com/javase/7/docs/technotes/guides/vm/server-class.html

このページ