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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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 日間を超えているので、パージされます。
• Tonga Fashions! のバージョンは、バージョンの数が 5 を超えているので、パージされます。

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.log が作成されます。
  
• 以前のログファイルは削除されないので、自己責任で古いログファイルを定期的にクリーンアップして、ディスクの使用量を制限してください。
  

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

• <cq-installation-dir>/crx-quickstart/logs
  • access.log
    AEM WCM およびリポジトリに対するアクセス要求はすべてここに登録されます。
  • audit.log
    モデレートアクションはここに登録されます。
  • error.log
    エラーメッセージ（様々な深刻度レベル）はここに登録されます。
  • ImageServer-<PortId>-yyyy>-<mm>-<dd>.log
    このログは、ダイナミックメディアが有効な場合にのみ使用されます。内部 Image Server プロセスの動作の分析に使用する、統計および分析情報を提供します。
  • request.log
    各アクセス要求が、応答と共にここに登録されます。
  • s7access-<yyyy>-<mm>-<dd>.log
    このログは、ダイナミックメディアが有効な場合にのみ使用されます。s7access ログは、/is/image および /is/content 経由でダイナミックメディアに対しておこなわれた要求を記録します。
  • stderr.log
    起動時に生成されたエラーメッセージ（様々な深刻度レベル）を保持します。デフォルトでは、ログレベルは Warning（WARN）に設定されています。
    
  • stdout.log
    起動時のイベントを示すログメッセージを保持します。
  • upgrade.log
    com.day.compat.codeupgrade パッケージおよび com.adobe.cq.upgradesexecutor パッケージから実行されるすべてのアップグレード操作のログを提供します。
• <cq-installation-dir>/crx-quickstart/repository
  • revision.log
    リビジョンジャーナル処理の情報。

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

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

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

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

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

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

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

/var/audit フォルダー内では、監査記録はリソースに従って保持されます。ドリルダウンすると、個々の記録およびそれぞれに含まれる情報を確認できます。

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

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

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

• 必要なキューがすべて有効になっていますか。
• 無効なキューの中に、まだ必要なものがありますか。
• enabled（有効な状態）のキューはすべて、ステータスが idle または active であり、これは正常な動作を示します。キューを blocked（ブロック状態）にしてはいけません。ブロックされている場合、多くは受信者側に問題があります。
• 時間の経過と共にキューのサイズが大きくなる場合は、キューがブロックされている可能性があります。

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

ここでも、すべてのレプリケーションエージェント（/etc/replication/author または /etc/replication/publish の下）を検出して、エージェントのステータス（enabled、disabled）および基になるキューのステータス（active、idle、blocked）を確認するソリューションを開発できます。

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

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

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

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

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

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

• パフォーマンス問題が発生する前の対応：
  • できる限り多くの情報を収集し、正常な状態のシステムに関する十分な実用的知識を構築します。
• パフォーマンス問題が発生した場合の対応：
  • 1 つ（または 2 つ以上を推奨）の標準的な Web ブラウザー、通常のパフォーマンスが良好であることがわかっている別のクライアント、またはサーバー自体（可能であれば）で、問題を再現します。
  • 適切な時間内に（システムに関連する）何かが変更されたかどうかと、いずれかの変更がパフォーマンスに影響した可能性があるかどうかを確認します。
  • 次の点を確認します。
    • 問題が発生するのは特定の時間のみかどうか。
    • 問題が発生するのは特定のページのみかどうか。
    • その他の要求に影響があるかどうか。
  • できる限り多くの情報を収集し、正常な状態のシステムに関する知識と比較します。

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

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

このファイルは、CQ に対するすべての要求に関する基本的な情報を登録します。ここから、貴重な結論を導き出すことができます。

request.log は、要求の所要時間を確認する方法として組み込まれています。開発目的では、request.log の末尾に -f を付けて、応答時間が遅くなる現象を監視すると便利です。サイズの大きい request.log を分析するには、rlog.jar を使用して、応答時間を分類してフィルター処理することをお勧めします。

「低速の」ページを request.log から分離し、個々に調整してパフォーマンスを向上させることをお勧めします。そのためには、通常はコンポーネントごとにパフォーマンス指標を含めるか、yourkit などのパフォーマンスプロファイリングツールを使用します。

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

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

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

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

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

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

• 要求または応答がおこなわれた日付。
• 要求の番号（角括弧内）。この番号は、要求と応答で一致しています。
• 矢印は、要求（右向き矢印）か応答（左向き矢印）かを示しています。
• 要求の行には、以下が含まれます。
  
  • メソッド（通常は GET、HEAD または POST）
  • 要求されたページ
  • プロトコル
• 応答の行には、以下が含まれます。
  
  • ステータスコード（200 は「成功」、404 は「ページが見つかりません」）
  • MIME タイプ
  • 応答時間

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

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

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

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

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

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

• 特定の期間（1 分間など）内におこなわれる要求の数を監視します。
• 特定の数のユーザー全員がほぼ同時に同じ要求をおこなった場合の影響をテストします（例えば、30 人のユーザーが同時に「保存」をクリックするなど）。

CQ には、様々なヘルパーツールが以下の場所に含まれています。
    <cq-installation-dir>/crx-quickstart/opt/helpers

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

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

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

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

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

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

上記の数値は、標準的な MAcBook Pro ラップトップ（2010 年半ば）から、CQ 5.6.1 のデフォルトインストールに含まれている Geometrixx 社のページにアクセスして得られたものです。このページは非常にシンプルですが、パフォーマンス向けに最適化はされていません。

apachebench では、同時に実行されているすべての要求の、要求ごとの所要時間の平均も表示されます。Time per request: 54.595 [ms] (mean, across all concurrent requests) を参照してください。並列性のパラメーター -c（同時に実行する複数の要求の数）の値を変更すると、それによる影響の有無を確認できます。

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

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

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

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

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

サーバーのパフォーマンスを向上するために、プロジェクトごとに html comments を含めることをお勧めします。良い例が多数公開されています。ページを選択し、ページソースを開いて下までスクロールすると、次のようなコードを確認できます。

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

JDK 1.6 以降、ツールコマンド jvisualvm が使用可能になりました。JDK 1.6 のインストールが完了したら、次の手順を実行できます。

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

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

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

• システムで作業をしている作成者の数
• 1 日あたりのページアクティベーションの平均数
• このシステムで現在保守しているページ数
• MSM を使用する場合は、1 ヶ月あたりのロールアウトの平均数
• 1 ヶ月あたりのライブコピーの平均数
• CQ DAM を使用する場合は、CQ DAM で現在保守しているアセットの数
• アセットの平均サイズ
• 現在使用されているテンプレートの数
• 現在使用されているコンポーネントの数
• ピーク時のオーサーシステムの 1 時間あたりの要求数
• ピーク時のパブリッシュシステムの 1 時間あたりの要求数

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

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

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

• タイプ XPath
• Path /
  
• クエリー //element(*, cq:AuditEvent)[@cq:type='Activate']
  

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

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

• タイプ XPath
• Path /
  
• クエリー //element(*, cq:Page)
  

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

• タイプ XPath
• Path /
  
• Query //element(*, cq:AuditEvent)[@cq:type='PageRolledOut']
  

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

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

• タイプ XPath
• Path /
  
• クエリー //element(*, cq:LiveSyncConfig)
  

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

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

• タイプ XPath
• Path /
  
• クエリー /jcr:root/content/dam//element(*, dam:Asset)
  

/var/dam フォルダーの合計サイズを特定するには：

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

• タイプ XPath
• Path /
  
• クエリー //element(*, cq:Template)
  

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

• タイプ XPath
• Path /
  
• クエリー //element(*, cq:Component)
  

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

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

CQ のパフォーマンスに関する問題が発生し始めたときにチェックする箇所に関する推奨事項を以下に示します。ただし、このリストはすべてを網羅しているわけではありません。

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

• ナレッジベース
  • 遅延しているプロセスおよびブロックされたプロセスの分析
    

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

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

    java.lang.OutOfMemoryError

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

• CQ の起動の際に使用している JVM 設定
• ナレッジベース
  • メモリの問題の分析

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

• Tar ファイルの最適化およびクラスターでの Tar ファイルの最適化
• デバッグ情報のコレクションを無効にしているかどうか。これは、以下を含む様々な場所で設定できます。
  • Apache Sling JSP Script Handler
  • Apache Sling Java Script Handler
  • Apache Sling Logging Configuration
  • CQ HTML Library Manager
  • CQ WCM Debug Filter
  • Logger
• バージョンのパージを設定しているかどうかと、その設定方法
• ナレッジベース
  
  • 開いているファイルが多すぎる
  • ジャーナルの消費ディスクスペースが大きすぎる

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

• メモリ不足
• ナレッジベース
  • 閉じられていないセッション

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

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

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

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

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

http://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 に接続します。以下を参照してください。
  http://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html

これは、使用中のメモリ量、使用されている GC アルゴリズム、アルゴリズムの実行にかかる時間、アプリケーションのパフォーマンスへの影響を確認する上で役立ちます。これがないと、チューニングは「ノブをランダムに回している」だけになります。