AEM 6 の操作ダッシュボードは、システムオペレーターが AEM のシステムヘルスを一目で監視するために役立ちます。また、AEM の関連する側面に関して自動生成された診断情報も提供され、自己完結型のメンテナンス自動化を設定および実行して、プロジェクト操作およびサポートケースを大幅に削減できます。操作ダッシュボードは、カスタムのヘルスチェックおよびメンテナンスタスクによって拡張できます。さらに、外部監視ツールから JMX を使用して操作ダッシュボードのデータにアクセスできます。
操作ダッシュボードの特徴は次のとおりです。
- ワンクリックのシステムステータスで、運営部門の効率向上に役立ちます。
- システムヘルスの概要を、1 つの場所で一元的に提供します。
- 問題の発見、分析および修正にかかる時間を短縮します。
- 自己完結型のメンテナンス自動化により、プロジェクトの運営コストを大幅に削減します。
操作ダッシュボードには、AEM のようこそ画面からツール／運営を選択してアクセスできます。
注意：
操作ダッシュボードにアクセスするには、「オペレーター」ユーザーグループの一員としてログインする必要があります。詳しくは、ユーザー、グループおよびアクセス権限の管理に関するドキュメントを参照してください。
ヘルスレポートシステムは、Sling ヘルスチェックを使用して AEM インスタンスのヘルスに関する情報を提供します。これには、OSGI、JMX、HTTP のいずれかの要求（JSON 経由）またはタッチ UI を使用します。設定可能なカウンターの測定値やしきい値を提供し、場合によっては、問題の解決方法に関する情報も提供します。
以下で説明するような、様々な機能があります。
ヘルスレポートは、特定の製品領域に関するヘルスの良好または不良を示すカードのシステムです。これらのカードは、Sling ヘルスチェックのビジュアライゼーションで、JMX および他のソースからデータを集計し、処理した情報を MBean として再公開します。これらの MBean は、org.apache.sling.healthcheck ドメイン以下にある JMX Web コンソールで検査できます。
ヘルスレポートインターフェイスには、AEM のようこそ画面のツール／運用／ヘルスレポートメニューからアクセスするか、または次の URL から直接アクセスできます。
http://<serveraddress>:port/libs/granite/operations/content/healthreports/healthreportlist.html
カードシステムが表示する状態は、OK、警告および重要の 3 つです。この状態は、ルールおよびしきい値の結果です。ルールおよびしきい値は、カードの上にマウスポインターを置いてアクションバーのギアアイコンをクリックすることで設定できます。
AEM 6 には次の 2 種類のヘルスチェックがあります。
- 個別ヘルスチェック
- 複合ヘルスチェック
個別ヘルスチェックは、状態カードに対応する単一のヘルスチェックです。個別ヘルスチェックは、ルールまたはしきい値で設定でき、特定されたヘルスの問題を解決するための 1 つ以上のヒントおよびリンクを提供できます。「ログエラー」チェックを例に説明します。インスタンスログにエラーエントリがある場合、ヘルスチェックの詳細ページに表示されます。ページ上部の「診断ツール」セクションに、「ログメッセージ」アナライザーがあります。これにより、これらのエラーをより詳細に分析してロガーを再設定できます。
複合ヘルスチェックは、複数の個別チェックから情報を集約するチェックです。
複合ヘルスチェックは、フィルタータグを使用して設定します。基本的に、同じフィルタータグを持つ単一チェックはすべて、複合ヘルスチェックとしてグループ化されます。複合ヘルスチェックは、集約した単一チェックのステータスがすべて OK である場合にのみ OK ステータスとなります。
-
Sling ヘルスチェックを作成するには、Sling ヘルスチェックインターフェイスを実装する OSGI コンポーネントを作成する必要があります。このコンポーネントをバンドル内に追加します。コンポーネントのプロパティにより、ヘルスチェックが完全に特定されます。コンポーネントがインストールされると、ヘルスチェック用の JMX MBean が自動的に作成されます。詳しくは、Sling ヘルスチェックドキュメントを参照してください。
OSGI サービスコンポーネントの注釈を含む、Sling ヘルスチェックコンポーネントの例：@Component(service = HealthCheck.class, property = { HealthCheck.NAME + "=Example Check", HealthCheck.TAGS + "=example", HealthCheck.TAGS + "=test", HealthCheck.MBEAN_NAME + "=exampleHealthCheckMBean" }) public class ExampleHealthCheck implements HealthCheck { @Override public Result execute() { // health check code } }注意：
MBEAN_NAME プロパティは、このヘルスチェック用に生成される Mbean の名前を定義します。
-
ヘルスチェックの作成後、操作ダッシュボードインターフェイスでアクセスできるようにするために、新しい設定ノードを作成する必要があります。この手順では、ヘルスチェックの JMX MBean 名を知っておく必要があります（MBEAN_NAME プロパティ）。ヘルスチェックの設定を作成するには、CRXDE を開いて新しいノード（タイプ nt:unstructured）を /apps/settings/granite/operations/hc の下に追加します。
新しいノードに次のプロパティを設定する必要があります。
- 名前：sling:resourceType
- タイプ：String
- 値：granite/operations/components/mbean
- 名前：resource
- タイプ：String
- 値： /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/exampleHealthCheck
注意：
前述のリソースパスは、次のように作成されます。ヘルスチェックの MBean 名が「test」の場合、「test」をパス /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck の末尾に追加します。
最終的なパスは次のようになります。
/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/test
注意：
/apps/settings/granite/operations/hc パスに、true に設定された次のプロパティがあることを確認します。
sling:configCollectionInherit
sling:configPropertyInherit
これにより、設定マネージャーで新しい設定が /libs の既存の設定と結合されます。
- 名前：sling:resourceType
複合ヘルスチェックの役割は、一般的な機能のセットを共有する個別ヘルスチェックの数を集計することです。例えば、セキュリティ複合ヘルスチェックは、セキュリティ関連の検証を実行するすべての個別ヘルスチェックをグループ化します。複合チェックを作成するには、まず、新しい OSGI 設定を追加します。操作ダッシュボードに表示するために、シンプルなチェックでおこなったのと同じように、新しい設定ノードを追加する必要があります。
-
設定を作成し、保存します。新しい設定で MBean が作成されます。
各設定プロパティの目的は次のとおりです。
- Name（hc.name）：複合ヘルスチェックの名前。意味のある名前を推奨します。
- Tags（hc.tags）：このヘルスチェックのタグ。この複合ヘルスチェックを別の複合ヘルスチェックの一部とする場合（ヘルスチェックの階層内など）は、この複合が関連付けられているタグを追加します。
- MBean Name（hc.mbean.name）：この複合ヘルスチェックの JMX MBean に付けられる Mbean の名前。
- Filter Tags（filter.tags）：これは複合ヘルスチェック専用のプロパティです。複合が集約するタグを指定します。複合ヘルスチェックは、そのグループの下に、この複合のいずれかのフィルタータグに一致するタグを持つすべてのヘルスチェックを集約します。例えば、test および check というフィルタータグを持つ複合ヘルスチェックは、タグプロパティ（hc.tags）に test タグと check タグのいずれかが含まれているすべての個別および複合ヘルスチェックを集約します。
注意：
Apache Sling 複合ヘルスチェックの新しい設定ごとに、新しい JMX Mbean が 1 つずつ作成されます。
-
最後に、作成した複合ヘルスチェックのエントリを操作ダッシュボードの設定ノードに追加する必要があります。この手順は、個別ヘルスチェックの手順と同じです。タイプ nt:unstructured のノードを /apps/settings/granite/operations/hc の下に作成する必要があります。ノードのリソースプロパティは、OSGI 設定の hc.mean.name の値によって定義されます。
例えば、設定を作成して hc.mbean.name 値を diskusage に設定した場合、設定ノードは次のようになります。
- 名前：Composite Health Check
- タイプ：nt:unstructured
次のようにプロパティを定義します。
- 名前：sling:resourceType
- タイプ：String
- 値：granite/operations/components/mbean
- 名前：resource
- タイプ：String
- 値：/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/diskusage
注意：
既にデフォルトでダッシュボードに存在する複合チェックに論理的に属する個別ヘルスチェックを作成する場合、ヘルスチェックは自動的にキャプチャされ、各複合チェックの下にグループ化されます。このため、これらのチェック用に新しい設定ノードを作成する必要はありません。
例えば、個別セキュリティヘルスチェックを作成する場合は、「security」タグを割り当ててインストールするだけで、操作ダッシュボードのセキュリティチェック複合チェックの下にヘルスチェックが自動的に表示されます。
- 名前：Composite Health Check
| ヘルスチェック名 | 説明 |
| クエリパフォーマンス | このヘルスチェックは AEM 6.4 で簡素化され、最近リファクタリングされた Oak QueryStats MBean（具体的には SlowQueries 属性）をチェックするようになりました。処理に時間のかかるクエリが統計に含まれる場合、ヘルスチェックは警告を返します。それ以外の場合は、OK ステータスを返します。 このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=queriesStatus,type=HealthCheck です。 |
| 監視キューの長さ | 監視キューの長さは、すべてのイベントリスナーとバックグラウンドオブザーバーを繰り返し処理し、それらの queueSize を maxQueueSize と比較します。
各キューの最大長は個別の設定（Oak と AEM）から取得され、このヘルスチェックからは設定できません。このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=ObservationQueueLengthHealthCheck,type=HealthCheck です。 |
| クエリトラバーサルの制限 | クエリトラバーサルの制限は、QueryEngineSettings MBean（具体的には LimitInMemory 属性と LimitReads 属性）をチェックし、次のステータスを返します。
このヘルスチェックの Mbean は、org.apache.sling.healthcheck:name=queryTraversalLimitsBundle,type=HealthCheck です。 |
| 同期済みのクロック | このチェックは、ドキュメントノードストアクラスターにのみ関連しています。次のステータスを返します。
このヘルスチェックの Mbean は、org.apache.sling.healthcheck:name=slingDiscoveryOakSynchronizedClocks,type=HealthCheck です。 |
| 非同期インデックス | 非同期インデックスチェック：
重要および警告ステータスのしきい値は、どちらも設定可能です。このヘルスチェックの Mbean は、org.apache.sling.healthcheck:name=asyncIndexHealthCheck,type=HealthCheck です。 注意：このヘルスチェックは、AEM 6.4 で使用でき、AEM 6.3.0.1 に移植されています。 |
| 大きい Lucene インデックス | このチェックは、Lucene Index Statistics MBean によって公開されたデータを使用して大きいインデックスを識別し、次のステータスを返します。
しきい値は設定可能で、このヘルスチェックの MBean は org.apache.sling.healthcheck:name=largeIndexHealthCheck,type=HealthCheck です。 注意：このチェックは、AEM 6.4 で使用でき、AEM 6.3.2.0 に移植されています。 |
| システムメンテナンス | システムメンテナンスは複合チェックです。すべてのメンテナンスタスクが設定どおりに実行されている場合に、OK を返します。次の点に注意してください。
このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=systemchecks,type=HealthCheck です。 |
| レプリケーションキュー | このチェックは、レプリケーションエージェントに対して繰り返され、そのキューを確認します。キューの上位にある項目について、チェックはエージェントがレプリケーションを試行した回数を確認します。エージェントが numberOfRetriesAllowed パラメーターの値より多くレプリケーションを試行した場合、警告を返します。numberOfRetriesAllowed パラメーターは設定可能です。 このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=replicationQueue,type=HealthCheck です。 |
| Sling ジョブ | Sling ジョブは、JobManager でのキューに登録されたジョブ数をチェックし、maxNumQueueJobs しきい値と比較します。
キューに登録されたジョブの最大数のパラメーターのみが設定可能で、デフォルト値は 1000 です。 このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=slingJobs,type=HealthCheck です。 |
| 要求パフォーマンス | このチェックは、granite.request.metrics.timer Sling 指標を確認します。
このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=requestsStatus,type=HealthCheck です。 |
| ログエラー | このチェックは、ログにエラーがある場合、警告ステータスを返します。 このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=logErrorHealthCheck,type=HealthCheck です。 |
| ディスク容量 | ディスク容量チェックは、FileStoreStats MBean を確認し、ノードストアのサイズおよびノードストアパーティション上の使用可能なディスク容量を取得します。
どちらのしきい値も設定可能です。このチェックは、セグメントストアを含むインスタンスに対してのみ機能します。 このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=DiskSpaceHealthCheck,type=HealthCheck です。 |
| スケジューラーヘルスチェック | このチェックは、インスタンスが 60 秒を超えて実行している Quartz ジョブを持つ場合、警告を返します。許容される期間のしきい値は、設定可能です。 このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=slingCommonsSchedulerHealthCheck,type=HealthCheck です。 |
| セキュリティチェック | セキュリティチェックは、複数のセキュリティ関連チェックを集計する複合チェックです。これらの個別ヘルスチェックは、セキュリティチェックリストドキュメントページで利用できるセキュリティチェックリストの様々な問題に対処します。このチェックは、インスタンス開始時のセキュリティスモークテストとして役立ちます。 このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=securitychecks,type=HealthCheck です。 |
| アクティブなバンドル | アクティブなバンドルは、すべてのバンドルの状態をチェックします。
無視リストパラメーターは設定可能です。 このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=inactiveBundles,type=HealthCheck です。 |
| コードキャッシュのチェック | これは、Java 7 に存在する CodeCache バグをトリガーできるいくつかの JVM 条件を検証するヘルスチェックです。
minimum.code.cache.size しきい値は設定可能です。バグについて詳しくは、このページを参照してください。 このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=codeCacheHealthCheck,type=HealthCheck です。 |
| リソース検索パスエラー | パス /apps/foundation/components/primary にリソースがあるかどうかをチェックします。
このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=resourceSearchPathErrorHealthCheck,type=HealthCheck です。 |
ヘルスチェックダッシュボードは、Granite JMX Mbean 経由で Nagios と統合できます。以下の例では、AEM を実行しているサーバー上で使用されているメモリを表示するチェックの追加方法を説明します。
-
注意：
Nagios および NRPE をシステムにインストールする方法について詳しくは、Nagios のドキュメントを参照してください。
-
AEM サーバーのホスト定義を追加します。これは、設定マネージャーを使用して、Nagios XI Web インターフェイス経由で実行できます。
- ブラウザーを開いて Nagios サーバーにアクセスします。
- トップメニューの「Configure」ボタンをクリックします。
- 左側のウィンドウで、「Advanced Configuration」の下の「Core Config Manager」をクリックします。
- 「Monitoring」セクションの下の「Hosts」リンクをクリックします。
- ホスト定義を追加します。
define host { address 192.168.0.5 max_check_attempts 3 check_period 24x7 check-command check-host-alive contacts admin notification_interval 60 notification_period 24x7 } -
check_http_json プラグインを両方のサーバーにインストールします。
-
define service { use generic-service host_name my.remote.host service_description AEM Author Used Memory check_command check_http_json-int!<cq-user>!<cq-password>!<cq-port>!system/sling/monitoring/mbeans/java/lang/Memory.infinity.json!{noname}.mbean:attributes.HeapMemoryUsage.mbean:attributes.used.mbean:value!<warn-threshold-in-bytes>!<critical-threshold-in-bytes> }
操作ダッシュボードからは、診断ツールにもアクセスできます。診断ツールは、ヘルスチェックダッシュボードからの警告の根本原因の発見やトラブルシューティングに役立つほか、システムオペレーターに重要なデバッグ情報を提供することもできます。
最も重要な機能は以下のとおりです。
- ログメッセージ分析
- ヒープおよびスレッドダンプにアクセスする機能
- 要求およびクエリパフォーマンスの分析
「診断ツール」画面を開くには、AEM のようこそ画面からツール／運営／診断を選択します。URL http://serveraddress:port/libs/granite/operations/content/diagnosis.html に直接アクセスして、この画面にアクセスすることもできます。
ログメッセージユーザーインターフェイスには、デフォルトですべてのエラーメッセージが表示されます。表示されるログメッセージを増やす場合は、該当するログレベルでロガーを設定する必要があります。
ログメッセージではメモリ内のログ追加機能を使用するので、ログファイルとは関係ありません。また、この UI でログレベルを変更しても、従来のログファイルに記録される情報は変更されません。この UI でのロガーの追加および削除は、メモリ内のロガーのみに影響します。また、ロガーの設定を変更すると、それ以降のメモリ内ロガーに反映されます。既にログに記録されていて該当しなくなったエントリは削除されませんが、同様のエントリは今後は記録されません。
ログに記録する内容を設定するには、UI の左上にあるギアボタンから、ロガーを設定します。そこで、ロガーの設定を追加、削除または更新できます。ロガーの設定は、ログレベル（警告／情報／デバッグ）とフィルター名で構成されます。フィルター名には、記録されるログメッセージのソースをフィルター処理する役割があります。また、指定したレベルのすべてのログメッセージをロガーで取り込む必要がある場合は、フィルター名を「root」とします。ロガーのレベルを設定すると、指定したレベル以上のすべてのメッセージの取り込みがトリガーされます。
例：
- すべてのエラーメッセージを取り込む計画をしている場合は、設定は不要です。エラーメッセージはすべてデフォルトで取り込まれます。
- エラー、警告、情報のすべてのメッセージを取り込む計画をしている場合は、ロガー名を「root」に、ロガーレベルを情報に設定します。
- 特定のパッケージ（com.adobe.granite など）からのすべてのメッセージを取り込む計画をしている場合は、ロガー名を「com.adobe.granite」に、ロガーレベルをデバッグに設定します（エラー、警告、情報、デバッグのすべてのメッセージが取り込まれます）。以下の図を参照してください。
注意：
指定したフィルター経由でエラーメッセージのみを取り込むロガー名は設定できません。デフォルトで、すべてのエラーメッセージが取り込まれます。
注意：
ログメッセージユーザーインターフェイスには、実際のエラーログは反映されません。UI で他のタイプのログメッセージを設定しない限り、エラーメッセージのみが表示されます。特定のログメッセージを表示する方法については、上記の説明を参照してください。
注意：
診断ページの設定はログファイルへの記録内容には影響せず、その逆も同様です。したがって、エラーログで情報メッセージが見つかったとしても、ログメッセージの UI には表示されない場合があります。また、エラーログに影響を与えずに、特定のパッケージからのデバッグメッセージを UI を通して見つけることもできます。ログファイルの設定方法について詳しくは、ログを参照してください。
注意：
AEM 6.4 では、メンテナンスタスクは、より情報の多い形式の標準のログに情報レベルで記録されるようになりました。これにより、メンテナンスタスクの状態がよりわかりやすくなっています。
メンテナンスタスクのアクティビティを監視し、対処するためにサードパーティツール（Splunk など）を使用している場合、次のログステートメントを使用できます。
Log level: INFO DATE+TIME [MaintanceLogger] Name=<MT_NAME>, Status=<MT_STATUS>, Time=<MT_TIME>, Error=<MT_ERROR>, Details=<MT_DETAILS>
要求パフォーマンスページでは、処理時間が最も長いページ要求を分析できます。このページではコンテンツ要求のみが登録されます。具体的には、以下の要求が取り込まれます。
- /content の下のリソースにアクセスする要求
- /etc/design の下のリソースにアクセスする要求
- 「.html」の拡張子が付いた要求
このページには以下の項目が表示されます。
- 要求がおこなわれた時刻
- URL と要求のメソッド
- 所要時間（ミリ秒単位）
デフォルトでは、所要時間が長いほうから 20 個のページ要求が取り込まれますが、この制限は設定マネージャーで変更できます。
取り込む要求の数を変更するには、以下の手順を実行する必要があります。
クエリパフォーマンスページでは、システムによって実行される、所要時間が最も長いクエリを分析できます。この情報は、JMX Mbean 内のリポジトリによって提供されます。Jackrabbit では、この情報は com.adobe.granite.QueryStat JMX Mbean によって提供され、Oak リポジトリでは org.apache.jackrabbit.oak.QueryStats によって提供されます。
このページには以下の項目が表示されます。
- クエリがおこなわれた時刻
- クエリの言語
- クエリの発行回数
- クエリのステートメント
- 所要時間（ミリ秒単位）
どのようなクエリでも、Oak は、リポジトリ内の oak:index ノードの下で定義されている Oak インデックスに基づいて最適な実行方法の計算を試みます。クエリごとに異なるインデックスが Oak によって選択されます。Oak によるクエリの実行方法を把握することが、クエリを最適化するための第一歩です。
クエリの説明を実行は、Oak によるクエリの実行方法を説明するツールです。これには、AEM のようこそ画面からツール／運営／診断を選択し、「クエリパフォーマンス」をクリックして「クエリの説明を実行」タブに切り替えることでアクセスできます。
機能
- Xpath、JCR-SQL および JCR-SQL2 クエリ言語をサポート
- 指定したクエリの実際の実行時間をレポート
- 時間のかかるクエリを検出し、潜在的に時間のかかる可能性のあるクエリに関する警告を表示
- クエリ実行に使用された Oak インデックスをレポート
- 実際の Oak クエリエンジンの説明を表示
- 時間のかかるクエリおよびよく使用されるクエリのリストをクリックで表示
クエリの説明を実行の UI では、クエリを入力して「説明」ボタンを押すだけで使用できます。
「クエリの説明」セクションの最初のエントリが実際の説明です。この説明には、クエリの実行に使用されたインデックスのタイプが示されます。
2 つ目のエントリは実行計画です。
クエリを実行する前に「実行時間を含める」ボックスをチェックすると、このクエリが実行された時間も示され、アプリケーションやデプロイメントでインデックスを最適化するために使用できる詳細情報が得られます。
インデックスマネージャの目的は、インデックスのメンテナンス、インデックスのステータスの表示、再インデックスのトリガーなどのインデックス管理を容易にすることです。
これには、AEM のようこそ画面からツール／運営／診断を選択し、「インデックスマネージャ」ボタンをクリックしてアクセスできます。
また、この URL（http://サーバーアドレス:ポート /libs/granite/operations/content/diagnosis/tool.html/_granite_oakindexmanager）から直接アクセスできます。
この UI で、画面左上隅の検索ボックスにフィルター条件を入力して、テーブル内のインデックスにフィルターを適用することができます。
各インデックスの「再インデックス」列のアイコンをクリックすることで、単独の再インデックスをトリガーできます。また、複数のインデックスを選択して「一括再インデックス」ボタンをクリックすることで、一括再インデックスをトリガーできます。
これは、システムステータスおよび設定に関する有益な情報を含む zip のダウンロードをトリガーします。アーカイブには、インスタンス設定、バンドルのリスト、OSGI、Sling の指標と統計が含まれているので、ファイルのサイズが大きくなります。サイズの大きいステータスファイルの影響を減らすには、ステータス ZIP をダウンロードウィンドウを使用します。このウィンドウには、AEM／ツール／運営／診断／ステータス ZIP をダウンロードからアクセスできます。
このウィンドウでは、エクスポートするもの（ログファイルやスレッドダンプ）および現在の日付を基準にしてダウンロードに含めるログの日数を選択できます。
自動メンテナンスタスクページでは、定期的な実行がスケジュールされている、推奨されるメンテナンスタスクを表示および追跡できます。タスクはヘルスチェックシステムに統合されています。タスクはインターフェイスから手動で実行することもできます。
運営ダッシュボードのメンテナンスページを開くには、AEM のようこそ画面からツール／運営／ダッシュボード／メンテナンスを選択するか、次のリンクに直接アクセスします。
http://serveraddress:port/libs/granite/operations/content/maintenance.html
操作ダッシュボードでは、次のタスクを使用できます。
- 日別メンテナンスウィンドウメニューの下のリビジョンのクリーンアップタスク。
- 日別メンテナンスウィンドウメニューの下の Lucene バイナリクリーンアップタスク。
- 週別メンテナンスウィンドウメニューの下のワークフローのパージタスク。
- 週別メンテナンスウィンドウメニューの下のデータストアのガベージコレクションタスク。
- 週別メンテナンスウィンドウメニューの下の監査ログのメンテナンスタスク。
- 週別メンテナンスウィンドウメニューの下のバージョンのパージのメンテナンスタスク。
日別メンテナンスウィンドウのデフォルトのタイミングは、午前 2 時から 5 時までです。週別メンテナンスウィンドウで実行するように設定されているタスクは、土曜日の午前 1 時から 2 時までに実行されます。
2 つのメンテナンスカードの歯車アイコンをクリックすることによって、タイミングを設定することもできます。
注意：
AEM 6.1 以降では、既存のメンテナンスウィンドウを月別で実行するように設定することもできます。
AEM 6.4 のリビジョンのクリーンアップの実行について詳しくは、この記事を参照してください。
Lucene バイナリクリーンアップタスクを使用することで、Lucene バイナリをパージして、実行中のデータストアのサイズ要件を減らすことができます。これは、以前はデータストアのガベージコレクションの正常な実行に依存していましたが、Lucene のバイナリチャーンが毎日再要求されるようになったからです。
メンテナンスタスクは Lucene に関連したリビジョンガベージを減らすために開発されましたが、このタスクを実行すると、次のように全般的に効率が向上します。
- データストアのガベージコレクションタスクの毎週の実行は、より迅速に完了します。
- AEM の全体的なパフォーマンスがわずかに向上することもあります。
Lucene バイナリクリーンアップタスクには、AEM／ツール／運営／メンテナンス／日別メンテナンスウィンドウ／Lucene バイナリクリーンアップからアクセスできます。
データストアのガベージコレクションについて詳しくは、専用のドキュメントページを参照してください。
監査ログのメンテナンスについて詳しくは、別個のドキュメントページを参照してください。
バージョンのパージメンテナンスタスクをスケジュールして、古いバージョンを自動的に削除できます。これにより、バージョンのパージツールを手動で実行する必要性を最小限に抑えることができます。バージョンのパージタスクをスケジュールして設定するには、ツール／運営／メンテナンス／週別メンテナンスウィンドウにアクセスし、次の手順に従います。
AEM 6.4 では、次のようにバージョンのパージメンテナンスタスクを停止できるようになりました。
- 自動 - タスクが完了する前に、スケジュールされたメンテナンスウィンドウを閉じると、タスクは自動的に停止します。次回のメンテナンスウィンドウを開くと、タスクは再開されます。
- 手動 - タスクを手動で停止するには、バージョンのパージメンテナンスカードの「停止」アイコンをクリックします。次回の実行時に、タスクは安全に再開されます。
注意：
メンテナンスタスクを停止すると、タスクの実行は休止されますが、既に進行しているジョブの監視が途切れることはありません。
カスタムメンテナンスタスクは OSGi サービスとして実装できます。メンテナンスタスクのインフラストラクチャは Apache Sling のジョブ処理に基づいているので、メンテナンスタスクでは Java インターフェイス org.apache.sling.event.jobs.consumer.JobExecutor を実装する必要があります。さらに、以下に示すいくつかのサービス登録プロパティがメンテナンスタスクとして検出されることを宣言する必要があります。
| サービスプロパティ名 | 説明 | 例 | タイプ |
| granite.maintenance.isStoppable | ユーザーがタスクを停止できるかどうかを定義するブール属性。タスクを停止可能と宣言した場合は、実行中に停止されたかどうかをチェックし、それに応じて対処する必要があります。デフォルト値は false です。 | true | オプション |
| granite.maintenance.mandatory | 定期的に実行する必要がある必須のタスクであるかどうかを定義するブール属性。必須のタスクがアクティブなスケジュールウィンドウ内で現在実行されていない場合、このヘルスチェックはこれをエラーとして報告します。デフォルト値は false です。 | true | オプション |
| granite.maintenance.name | タスクの一意の名前 - これはタスクを参照するために使用します。通常、これは単純な名前です。 | MyMaintenanceTask | 必須 |
| granite.maintenance.title | このタスクに表示されるタイトル | 特別なメンテナンスタスク | 必須 |
| job.topics | これは、メンテナンスタスクの一意のトピックです。 Apache Sling ジョブ処理は、このトピックに従ってジョブを開始してメンテナンスタスクを実行し、タスクがこのトピックに登録されると実行されます。 トピックは com/adobe/granite/maintenance/job/ で始まる必要があります | com/adobe/granite/maintenance/job/MyMaintenanceTask | 必須 |
上記のサービスプロパティの他に、メンテナンスタスク用に実行するコードを追加することにより、JobConsumer インターフェイスの process() メソッドを実装する必要があります。提供されている JobExecutionContext を使用すると、ステータス情報を出力し、ジョブがユーザーによって停止されるかどうかをチェックして、結果（成功または失敗）を作成できます。
すべてのインストールでメンテナンスタスクを実行することが適切ではない状況の場合（パブリッシュインスタンスでのみ実行する場合など）は、@Component(policy=ConfigurationPolicy.REQUIRE) を追加することにより、サービスをアクティブにするには設定を必要とするように指定できます。その後、該当する設定を、リポジトリ内で実行モードに依存するとマークすることができます。詳しくは、OSGi の設定を参照してください。
以下のカスタムメンテナンスタスクの例では、設定可能な一時ディレクトリから、過去 24 時間以内に変更されたファイルを削除します。
src/main/java/com/adobe/granite/samples/maintenance/impl/DeleteTempFilesTask.java
/* * #%L * sample-maintenance-task * %% * Copyright (C) 2014 Adobe * %% * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. * #L% */
package com.adobe.granite.samples.maintenance.impl;
import java.io.File; import java.util.Calendar; import java.util.Collection; import java.util.Map;
import org.apache.commons.io.FileUtils; import org.apache.commons.io.filefilter.IOFileFilter; import org.apache.commons.io.filefilter.TrueFileFilter; import org.apache.felix.scr.annotations.Activate; import org.apache.felix.scr.annotations.Component; import org.apache.felix.scr.annotations.Properties; import org.apache.felix.scr.annotations.Property; import org.apache.felix.scr.annotations.Service; import org.apache.sling.commons.osgi.PropertiesUtil; import org.apache.sling.event.jobs.Job; import org.apache.sling.event.jobs.consumer.JobConsumer; import org.apache.sling.event.jobs.consumer.JobExecutionContext; import org.apache.sling.event.jobs.consumer.JobExecutionResult; import org.apache.sling.event.jobs.consumer.JobExecutor; import org.slf4j.Logger; import org.slf4j.LoggerFactory;
import com.adobe.granite.maintenance.MaintenanceConstants;
@Component(metatype = true, label = "Delete Temp Files Maintenance Task", description = "Maintatence Task which deletes files from a configurable temporary directory which have been modified in the last 24 hours.") @Service @Properties({ @Property(name = MaintenanceConstants.PROPERTY_TASK_NAME, value = "DeleteTempFilesTask", propertyPrivate = true), @Property(name = MaintenanceConstants.PROPERTY_TASK_TITLE, value = "Delete Temp Files", propertyPrivate = true), @Property(name = JobConsumer.PROPERTY_TOPICS, value = MaintenanceConstants.TASK_TOPIC_PREFIX + "DeleteTempFilesTask", propertyPrivate = true) }) public class DeleteTempFilesTask implements JobExecutor {
private static final Logger log = LoggerFactory.getLogger(DeleteTempFilesTask.class);
@Property(label = "Temporary Directory", description="Temporary Directory. Defaults to the java.io.tmpdir system property.") private static final String PROP_TEMP_DIR = "temp.dir";
private File tempDir;
@Activate private void activate(Map<string, object=""> properties) { this.tempDir = new File(PropertiesUtil.toString(properties.get(PROP_TEMP_DIR), System.getProperty("java.io.tmpdir"))); }
@Override public JobExecutionResult process(Job job, JobExecutionContext context) { log.info("Deleting old temp files from {}.", tempDir.getAbsolutePath()); Collection<file> files = FileUtils.listFiles(tempDir, new LastModifiedBeforeYesterdayFilter(), TrueFileFilter.INSTANCE); int counter = 0; for (File file : files) { log.debug("Deleting file {}.", file.getAbsolutePath()); counter++; file.delete(); // TODO - capture the output of delete() and do something useful with it } return context.result().message(String.format("Deleted %s files.", counter)).succeeded(); }
/** * IOFileFilter which filters out files which have been modified in the last 24 hours. * */ private static class LastModifiedBeforeYesterdayFilter implements IOFileFilter {
private final long minTime;
private LastModifiedBeforeYesterdayFilter() { Calendar cal = Calendar.getInstance(); cal.add(Calendar.DATE, -1); this.minTime = cal.getTimeInMillis(); }
@Override public boolean accept(File dir, String name) { // this method is never actually called. return false; }
@Override public boolean accept(File file) { return file.lastModified() <= this.minTime; } }
} </file></string,>
|
experiencemanager-java-maintenancetask-sample - src/main/java/com/adobe/granite/samples/maintenance/impl/DeleteTempFilesTask.java
これにより、対応するリソースが /apps/granite/operations/config/maintenance/[スケジュール]/[タスク名] に追加されます。タスクが実行モードに依存する場合は、granite.operations.conditions.runmode プロパティを該当するノードで設定し、このメンテナンスタスク用にアクティブにする必要のある実行モードの値を指定する必要があります。
システム概要ダッシュボードが導入され、AEM インスタンスの設定、ハードウェアおよびヘルスの概要が表示されます。つまり、システムヘルスのステータスが明白になり、すべての情報が 1 つのダッシュボードに集約されます。
注意：
システム概要ダッシュボードの概要については、このビデオを参照してください。
次の表では、システム概要ダッシュボードに表示されるすべての情報について説明します。表示する関連情報がない場合（バックアップが進行中ではない、重要なヘルスチェックはないなど）は、それぞれのセクションに「エントリがありません」というメッセージが表示されます。
また、ダッシュボードの右上隅の「ダウンロード」ボタンをクリックして、ダッシュボード情報を要約した JSON ファイルをダウンロードすることもできます。JSON のエンドポイントは /libs/granite/operations/content/systemoverview/export.json です。これを curl スクリプトで使用して、外部監視をおこなうことができます。
| セクション | 表示される情報 | これが重要になる状況 | リンク先 |
| ヘルスチェック |
|
色の意味：
|
|
| メンテナンスタスク |
|
色の意味：
|
|
| システム |
|
該当なし | 該当なし |
| インスタンス |
|
該当なし | 該当なし |
| リポジトリ |
|
該当なし | 該当なし |
| 配布エージェント |
|
色の意味：
|
配布版ページ |
| レプリケーションエージェント |
|
色の意味：
|
レプリケーションページ |
| ワークフロー |
前述のステータスごとにクエリが実行されます（400 ミリ秒以内）。400 ミリ秒の時点で、その時点までに取得されたエントリ数が表示されます。 |
判断なし：
|
ワークフローエラーページ |
| Sling ジョブ | Sling ジョブ数 - 特定のステータスのジョブの数（ある場合）：
|
判断なし：
|
該当なし |
| 予測ノード数 | 予測数：
ノードの合計数は nodeCounterMBean から取得しますが、残りの統計は IndexInfoService から取得します。 |
該当なし | 該当なし |
| バックアップ | この場合は、「オンラインバックアップを処理中」と表示されます。 | 該当なし | 該当なし |
| インデックス作成 | 表示：
インデックスまたはクエリスレッドがスレッドダンプに存在する場合。 |
該当なし | 該当なし |
Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。