AEM 6 の操作ダッシュボードは、システムオペレーターが AEM のシステムヘルスを一目で監視するために役立ちます。また、AEM が関連する側面に関して自動生成された診断情報も提供され、自己完結型のメンテナンス自動化を設定および実行して、プロジェクト操作とサポートケースを大幅に削減できます。操作ダッシュボードは、カスタムのヘルスチェックおよびメンテナンスタスクによって拡張できます。さらに、外部監視ツールから JMX を使用して操作ダッシュボードのデータにアクセスできます。
操作ダッシュボードの特徴は次のとおりです。
AEM のようこそ画面からツール/操作に移動してアクセスできます。
操作ダッシュボードにアクセスするには、「オペレーター」ユーザーグループの一員としてログインする必要があります。詳しくは、ユーザー、グループおよびアクセス権限の管理に関するドキュメントを参照してください。
ヘルスレポートシステムは、Sling ヘルスチェックを使用して AEM インスタンスのヘルスに関する情報を提供します。これには、OSGI、JMX、HTTP のいずれかの要求(JSON 経由)またはタッチ UI を使用します。設定可能なカウンターの測定値やしきい値を提供し、場合によっては、問題の解決方法に関する情報も提供します。
以下で説明するような、様々な機能があります。
ヘルスレポートは、特定の製品領域に関するヘルスの良好または不良を示すカードのシステムです。これらのカードは、Sling ヘルスチェックのビジュアライゼーションで、JMX および他のソースからデータを集計し、処理した情報を MBean として再公開します。これらの MBean は、org.apache.sling.healthcheck ドメイン以下にある JMX Web コンソールで検査できます。
ヘルスレポートインターフェイスには、AEM のようこそ画面のツール/運用/ヘルスレポートメニューからアクセスするか、次の URL から直接アクセスできます。
https://<serveraddress>:port/libs/granite/operations/content/healthreports/healthreportlist.html
カードシステムが表示する状態は、OK、警告、重要の 3 つです。この状態は、ルールおよびしきい値の結果です。ルールおよびしきい値は、カードの上にマウスポインターを置いてアクションバーのギアアイコンをクリックすることで設定できます。
AEM 6 には次の 2 種類のヘルスチェックがあります。
個別ヘルスチェックは、状態カードに対応する単一のヘルスチェックです。個別ヘルスチェックは、ルールまたはしきい値で設定でき、特定されたヘルスの問題を解決するための 1 つ以上のヒントおよびリンクを提供できます。「ログエラー」チェックを例に説明します。インスタンスログにエラーエントリがある場合、ヘルスチェックの詳細ページに表示されます。ページ上部の「診断ツール」セクションに、「ログメッセージ」アナライザーがあります。これにより、これらのエラーをより詳細に分析してロガーを再設定できます。
複合ヘルスチェックは、複数の個別チェックから情報を集約するチェックです。
複合ヘルスチェックは、フィルタータグを使用して設定します。基本的に、同じフィルタータグを持つ単一チェックはすべて、複合ヘルスチェックとしてグループ化されます。複合ヘルスチェックは、集約した単一チェックのステータスがすべて OK である場合にのみ OK ステータスとなります。
操作ダッシュボードで、個別および複合ヘルスチェックの両方の結果を視覚化できます。
個別ヘルスチェックは、2 段階の手順で作成します。Sling ヘルスチェックを実装し、ヘルスチェックのエントリをダッシュボードの設定ノードに追加します。
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」の場合、パス /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck
の末尾に「test」を追加します。
最終的なパスは次のようになります。
/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/test
/apps/settings/granite/operations/hc
パスに、true に設定された次のプロパティがあることを確認します。
sling:configCollectionInherit
sling:configPropertyInherit
これにより、設定マネージャーで新しい設定が /libs
の既存の設定と結合されます。
複合ヘルスチェックの役割は、一般的な機能のセットを共有する個別ヘルスチェックの数を集計することです。例えば、セキュリティ複合ヘルスチェックは、セキュリティ関連の検証を実行するすべての個別ヘルスチェックをグループ化します。複合チェックを作成するには、まず、新しい OSGI 設定を追加します。操作ダッシュボードに表示するために、シンプルなチェックでおこなったのと同じように、新しい設定ノードを追加する必要があります。
OSGI コンソールで web 設定マネージャーに移動します。これを行うには、https://serveraddress:port/system/console/configMgr
にアクセスします。
Apache Sling Composite Health Check というエントリを検索します。見つかったら、システムチェック用とセキュリティチェック用の 2 つの設定が既に使用可能であることを確認します。
設定の右側にある「+」ボタンを押して新しい設定を作成します。以下のような新しいウィンドウが表示されます。
設定を作成し、保存します。新しい設定で MBean が作成されます。
各設定プロパティの目的は次のとおりです。
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」タグを割り当ててインストールするだけで、操作ダッシュボードのセキュリティチェック複合チェックの下にヘルスチェックが自動的に表示されます。
ヘルスチェック名 | 説明 |
クエリパフォーマンス | このヘルスチェックは AEM 6.4 で簡素化され、最近リファクタリングされた このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=queriesStatus,type=HealthCheck です。 |
監視キューの長さ | 監視キューの長さは、すべてのイベントリスナーとバックグラウンドオブザーバーを繰り返し処理し、それらの
各キューの最大長は個別の設定(Oak と AEM)から取得され、このヘルスチェックからは設定できません。このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=ObservationQueueLengthHealthCheck,type=HealthCheck です。 |
クエリトラバーサルの制限 | クエリトラバーサルの制限は、
このヘルスチェックの 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 インデックス | このチェックは、
しきい値は設定可能で、このヘルスチェックの 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 です。 |
レプリケーションキュー | このチェックは、レプリケーションエージェントに対して繰り返され、そのキューを確認します。キューの上位にある項目について、チェックはエージェントがレプリケーションを試行した回数を確認します。エージェントが このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=replicationQueue,type=HealthCheck です。 |
Sling ジョブ |
Sling ジョブは、JobManager でのキューに登録されたジョブ数をチェックし、
maxNumQueueJobs しきい値と比較します。
キューに登録されたジョブの最大数のパラメーターのみが設定可能で、デフォルト値は 1000 です。 このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=slingJobs,type=HealthCheck です。 |
要求パフォーマンス | このチェックは、
このヘルスチェックの MBean は、 org.apache.sling.healthcheck:name=requestsStatus,type=HealthCheck です。 |
ログエラー | このチェックは、ログにエラーがある場合、警告ステータスを返します。 このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=logErrorHealthCheck,type=HealthCheck です。 |
ディスク容量 | ディスク容量チェックは、
どちらのしきい値も設定可能です。このチェックは、セグメントストアを含むインスタンスに対してのみ機能します。 このヘルスチェックの 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=codeCacheHealthCheck,type=HealthCheck です。 |
アクティブなバンドル | アクティブなバンドルは、すべてのバンドルの状態をチェックします。
無視リストパラメーターは設定可能です。 このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=inactiveBundles,type=HealthCheck です。 |
コードキャッシュのチェック | これは、Java 7 に存在する CodeCache バグをトリガーできるいくつかの JVM 条件を検証するヘルスチェックです。
このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=codeCacheHealthCheck,type=HealthCheck です。 |
リソース検索パスエラー | パス
このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=resourceSearchPathErrorHealthCheck,type=HealthCheck です。 |
デフォルトでは、標準のAEMインスタンスの場合、ヘルスチェックは 60 秒ごとに実行されます。
次の項目を設定できます。 期間 と OSGi 設定 クエリヘルスチェック設定 (com.adobe.granite.queries.impl.hc.QueryHealthCheckMetrics)。
ヘルスチェックダッシュボードは、Granite JMX Mbean 経由で Nagios と統合できます。以下の例では、AEM を実行しているサーバー上で使用されているメモリを表示するチェックの追加方法を説明します。
監視サーバーで Nagios を設定してインストールします。
次に、Nagios Remote Plugin Executor(NRPE)をインストールします。
Nagios および NRPE をシステムにインストールする方法について詳しくは、Nagios のドキュメントを参照してください。
AEM サーバーのホスト定義を追加します。これは、設定マネージャーを使用して、Nagios XI Web インターフェイス経由で実行できます。
以下は、Nagios Core を使用している場合のホスト設定ファイルの例です。
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
}
Nagios と NRPE を AEM サーバーにインストールします。
check_http_json プラグインを両方のサーバーにインストールします。
両方のサーバーで、汎用の JSON チェックコマンドを定義します。
define command{
command_name check_http_json-int
command_line /usr/lib/nagios/plugins/check_http_json --user "$ARG1$" --pass "$ARG2$" -u 'https://$HOSTNAME$:$ARG3$/$ARG4$' -e '$ARG5$' -w '$ARG6$' -c '$ARG7$'
}
AEM サーバー上の使用メモリのためのサービスを追加します。
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>
}
Nagios ダッシュボードで新しく作成されたサービスを確認します。
操作ダッシュボードからは、診断ツールにもアクセスできます。診断ツールは、ヘルスチェックダッシュボードからの警告の根本原因の発見やトラブルシューティングに役立つほか、システムオペレーターに重要なデバッグ情報を提供することもできます。
最も重要な機能は以下のとおりです。
「診断ツール」画面を開くには、AEM のようこそ画面からツール/操作/診断を選択します。次の URL に直接アクセスして画面にアクセスすることもできます:https://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"
拡張子を持つ要求このページには以下の項目が表示されます。
デフォルトでは、所要時間が長いほうから 20 個のページ要求が取り込まれますが、この制限は設定マネージャーで変更できます。
「クエリーパフォーマンス」ページでは、システムで実行される最も遅いクエリーを分析できます。この情報は、JMX Mbean のリポジトリから提供されます。Jackrabbit では、com.adobe.granite.QueryStat
JMX Mbean がこの情報を提供し、Oak リポジトリでは、org.apache.jackrabbit.oak.QueryStats.
が提供します。
このページには以下の項目が表示されます。
どのようなクエリでも、Oak は、リポジトリ内の oak:index ノードの下で定義されている Oak インデックスに基づいて最適な実行方法の計算を試みます。クエリごとに異なるインデックスが Oak によって選択されます。Oak によるクエリの実行方法を把握することが、クエリを最適化するための第一歩です。
クエリの説明を実行は、Oak によるクエリの実行方法を説明するツールです。これには、AEM のようこそ画面からツール/操作/診断を選択し、「クエリパフォーマンス」をクリックして「クエリの説明を実行」タブに切り替えることでアクセスできます。
機能
クエリの説明を実行の UI では、クエリを入力して「説明」ボタンを押すだけで使用できます。
「クエリの説明」セクションの最初のエントリが実際の説明です。この説明には、クエリの実行に使用されたインデックスのタイプが示されます。
2 つ目のエントリは実行計画です。
クエリを実行する前に実行時間を含めるボックスにチェックを入れると、クエリの実行時間も表示されます。この ノード数を含めるオプションを選択すると、ノード数が報告されます。これらを使用すると、より詳細な情報が得られ、アプリケーションやデプロイメントのインデックスの最適化に使用できます。
インデックスマネージャの目的は、インデックスのメンテナンスや、ステータスの表示などのインデックス管理を容易にすることです。
これには、AEM のようこそ画面からツール/操作/診断を選択し、「インデックスマネージャー**」ボタンをクリックしてアクセスできます。
この URL から直接アクセスすることもできます。https://serveraddress:port/libs/granite/operations/content/diagnosistools/indexManager.html
この UI で、画面左上隅の検索ボックスにフィルター条件を入力して、テーブル内のインデックスにフィルターを適用することができます。
これは、システムステータスおよび設定に関する有益な情報を含む zip のダウンロードをトリガーします。アーカイブには、インスタンス設定、バンドルのリスト、OSGI、Sling の指標と統計が含まれるので、ファイルのサイズが大きくなります。サイズの大きいステータスファイルの影響を減らすには、ステータス ZIP をダウンロードウィンドウを使用します。このウィンドウには、AEM/ツール/操作/診断/ステータス ZIP をダウンロードからアクセスできます。
このウィンドウでは、エクスポートするもの(ログファイルやスレッドダンプ)および現在の日付を基準にしてダウンロードに含めるログの日数を選択できます。
システム内に存在するスレッドに関する情報を含む zip ファイルをダウンロードします。ステータス、クラスローダー、スタックトレースなど、各スレッドに関する情報が提供されます。
後から分析するために、ヒープのスナップショットをダウンロードすることもできます。数百メガバイトものサイズの大きいファイルがダウンロードされることに注意してください。
自動メンテナンスタスクページでは、定期的な実行がスケジュールされている、推奨されるメンテナンスタスクを表示および追跡できます。タスクはヘルスチェックシステムに統合されています。タスクはインターフェイスから手動で実行することもできます。
操作ダッシュボードのメンテナンスページを開くには、AEM のようこそ画面からツール/操作/ダッシュボード/メンテナンスを選択するか、次のリンクに直接アクセスします。
https://serveraddress:port/libs/granite/operations/content/maintenance.html
操作ダッシュボードでは、次のタスクを使用できます。
日別メンテナンスウィンドウのデフォルトのタイミングは、午前 2 時から 5 時までです。週別メンテナンスウィンドウで実行するように設定されているタスクは、土曜日の午前 1 時から 2 時までに実行されます。
2 つのメンテナンスカードの歯車アイコンをクリックすることによって、タイミングを設定することもできます。
AEM 6.1 以降では、既存のメンテナンスウィンドウを月別で実行するように設定することもできます。
リビジョンのクリーンアップの実行について詳しくは、この記事を参照してください。
Lucene バイナリクリーンアップタスクを使用することで、Lucene バイナリをパージして、実行中のデータストアのサイズ要件を減らすことができます。これは、以前はデータストアのガベージコレクションの正常な実行に依存していましたが、Lucene のバイナリチャーンが毎日再要求されるようになったからです。
メンテナンスタスクは Lucene に関連したリビジョンガベージを減らすために開発されましたが、このタスクを実行すると、次のように全般的に効率が向上します。
Lucene バイナリクリーンアップタスクには、AEM/ツール/操作/メンテナンス/日別メンテナンスウィンドウ/Lucene バイナリクリーンアップからアクセスできます。
データストアのガベージコレクションについて詳しくは、専用のドキュメントページを参照してください。
ワークフローをメンテナンスダッシュボードからパージすることもできます。ワークフローのパージタスクを実行するには、次の手順が必要です。
ワークフローメンテナンスの詳細については、このページを参照してください。
監査ログのメンテナンスについては、別のドキュメントページを参照してください。
バージョンのパージメンテナンスタスクをスケジュールして、古いバージョンを自動的に削除できます。これにより、バージョンのパージツールを手動で実行する必要性を最小限に抑えることができます。バージョンのパージタスクをスケジュールして設定するには、ツール/操作/メンテナンス/週別メンテナンスウィンドウにアクセスし、次の手順に従います。
「追加」ボタンをクリックします。
ドロップダウンメニューから「バージョンのパージ」を選択します。
バージョンのパージタスクを設定するには、新しく作成されたバージョンのパージメンテナンスカードの歯車アイコンをクリックします。
AEM 6.4 では、次のようにバージョンのパージメンテナンスタスクを停止できるようになりました。
メンテナンスタスクを停止すると、タスクの実行は休止されますが、既に進行しているジョブの監視が途切れることはありません。
リポジトリサイズを最適化するためには、バージョン削除タスクを頻繁に実行する必要があります。トラフィックが限られている場合は、営業時間外にタスクをスケジュールする必要があります。
カスタムメンテナンスタスクは OSGi サービスとして実装できます。メンテナンスタスクのインフラストラクチャは Apache Sling のジョブ処理に基づいているので、メンテナンスタスクでは Java インターフェイス [org.apache.sling.event.jobs.consumer.JobExecutor](https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/consumer/JobExecutor.html)
を実装する必要があります。さらに、以下に示すいくつかのサービス登録プロパティがメンテナンスタスクとして検出されることを宣言する必要があります。
サービスプロパティ名 |
説明 | 例 |
タイプ |
granite.maintenance.isStoppable | タスクをユーザーが停止できるかどうかを定義するブール値属性。停止可能と宣言する場合は、タスクを実行中に、停止されたかどうかを確認し、適宜処理をおこなう必要があります。デフォルトは false です。 | true | オプション |
granite.maintenance.mandatory | タスクが必須であり、定期的に実行する必要があるかどうかを定義するブール値属性。タスクが必須であるものの、現時点でアクティブなスケジュールウィンドウに存在しない場合は、ヘルスチェックによってエラーとして報告されます。デフォルトは false です。 | true | オプション |
granite.maintenance.name | タスクの一意の名前 - タスクを参照するために使用されます。通常、これは単純な名前です。 | MyMaintenanceTask | 必須 |
granite.maintenance.title | このタスクに表示されるタイトル。 | My Special Maintenance Task | 必須 |
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
|
experiencemanager-java-maintenancetask-sample- src/main/java/com/adobe/granite/samples/maintenance/impl/DeleteTempFilesTask.java
サービスをデプロイすると、操作ダッシュボード UI に表示されます。利用可能なメンテナンススケジュールの 1 つに追加できます。
これにより、対応するリソースが /apps/granite/operations/config/maintenance/schedule
/taskname
に追加されます。タスクが実行モードに依存する場合は、granite.operations.conditions.runmode プロパティを該当するノードで設定し、このメンテナンスタスク用にアクティブにする必要のある実行モードの値を指定する必要があります。
システム概要ダッシュボードに、AEM インスタンスの設定、ハードウェアおよびヘルスの概要が表示されます。つまり、システムヘルスのステータスが明白になり、すべての情報が 1 つのダッシュボードに集約されます。
システム概要ダッシュボードの概要については、このビデオを参照してください。
システム概要ダッシュボードにアクセスするには、ツール/操作/システム概要に移動します。
次の表では、システム概要ダッシュボードに表示されるすべての情報について説明します。表示する関連情報がない場合(バックアップが進行中ではない、重要なヘルスチェックはないなど)は、それぞれのセクションに「エントリがありません」というメッセージが表示されます。
また、ダッシュボードの右上隅の「ダウンロード」ボタンをクリックして、ダッシュボード情報を要約した JSON
ファイルをダウンロードすることもできます。JSON
のエンドポイントは /libs/granite/operations/content/systemoverview/export.json
です。これを curl
スクリプトで使用して、外部監視をおこなうことができます。
セクション | 表示される情報 | これが重要になる状況 | リンク先 |
ヘルスチェック |
|
色の意味:
|
|
メンテナンスタスク |
|
色の意味:
|
|
システム |
|
該当なし | 該当なし |
インスタンス |
|
該当なし | 該当なし |
リポジトリ |
|
該当なし | 該当なし |
配布エージェント |
|
色の意味:
|
配布版ページ |
レプリケーションエージェント |
|
色の意味:
|
レプリケーションページ |
ワークフロー |
前述のステータスごとにクエリが実行されます(400 ミリ秒以内)。400 ミリ秒の時点で、その時点までに取得されたエントリ数が表示されます。 |
判断なし:
|
ワークフローエラーページ |
Sling ジョブ | Sling ジョブ数 - 特定のステータスのジョブの数(ある場合):
|
判断なし:
|
該当なし |
予測ノード数 | 予測数:
ノードの合計数は nodeCounterMBean から取得しますが、残りの統計は IndexInfoService から取得します。 |
該当なし | 該当なし |
バックアップ | この場合は、「オンラインバックアップを処理中」と表示されます。 | 該当なし | 該当なし |
インデックス作成 | 表示:
インデックスまたはクエリスレッドがスレッドダンプに存在する場合。 |
該当なし | 該当なし |