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 Configuration Managerに移動します。これは、https://serveraddress:port/system/console/configMgr
にアクセスすることで可能です
Apache Sling Composite Health Check というエントリを検索します。見つかったら、システムチェック用とセキュリティチェック用の 2 つの設定が既に使用可能なことを確認します。
設定の右側にある「+」ボタンを押して新しい設定を作成します。以下のような新しいウィンドウが表示されます。
設定を作成し、保存します。新しい設定で MBean が作成されます。
各設定プロパティの目的は次のとおりです。
hc.tags
タグのいずれかが含まれているすべての個別および複合ヘルスチェックを集約します。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=querysStatus,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 Jobsは、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です。 |
ディスク容量 | Disk Spaceチェックでは、
どちらのしきい値も設定可能です。このチェックは、セグメントストアを含むインスタンスでのみ機能します。 このヘルスチェックの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 条件を検証するヘルスチェックです。
このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=codeCacheHealthCheck,type=HealthCheck です。 |
リソース検索パスエラー | パス
このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=resourceSearchPathErrorHealthCheck,type=HealthCheck です。 |
ヘルスチェックダッシュボードは、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
ログメッセージユーザーインターフェイスには、デフォルトですべてのエラーメッセージが表示されます。表示されるログメッセージを増やす場合は、該当するログレベルでロガーを設定する必要があります。
ログメッセージはメモリ内ログアペンダーを使用するので、ログファイルとは関係しません。もう1つの結果として、このUIでログレベルを変更しても、従来のログファイルに記録される情報は変更されません。このUIでロガーを追加および削除すると、メモリ内ロガーにのみ影響します。また、ロガー設定の変更はメモリ内ロガーの将来に反映されます。既にログに記録され、関連しなくなったエントリは削除されませんが、今後同様のエントリはログに記録されません。
ログに記録する内容を設定するには、UI の左上にあるギアボタンから、ロガーを設定します。そこで、ロガーの設定を追加、削除または更新できます。ロガーの設定は、ログレベル(警告/情報/デバッグ)とフィルター名で構成されます。フィルター名には、記録されるログメッセージのソースをフィルター処理する役割があります。また、指定したレベルのすべてのログメッセージをロガーで取り込む必要がある場合は、フィルター名を「root」とします。ロガーのレベルを設定すると、指定したレベル以上のすべてのメッセージの取り込みがトリガーされます。
例:
すべてのエラーメッセージを取り込む計画をしている場合は、設定は不要です。エラーメッセージはすべてデフォルトで取り込まれます。
エラー、警告、情報のすべてのメッセージを取り込む計画をしている場合は、ロガー名を「root」に、ロガーレベルを情報に設定します。
特定のパッケージ(com.adobe.granite など)からのすべてのメッセージを取り込む計画をしている場合は、ロガー名を「com.adobe.granite」に、ロガーレベルをデバッグに設定します(エラー、警告、情報、デバッグのすべてのメッセージが取り込まれます)。以下の図を参照してください。
指定したフィルター経由でエラーメッセージのみを取り込むロガー名は設定できません。デフォルトで、すべてのエラーメッセージが取り込まれます。
ログメッセージユーザーインターフェイスには、実際のエラーログは反映されません。UI で他のタイプのログメッセージを設定しない限り、エラーメッセージのみが表示されます。特定のログメッセージを表示する方法については、上記の説明を参照してください。
診断ページの設定はログファイルへの記録内容には影響せず、その逆も同様です。したがって、エラーログで情報メッセージが見つかったとしても、ログメッセージの UI には表示されない場合があります。また、エラーログに影響を与えずに、特定のパッケージからのデバッグメッセージを UI を通して見つけることもできます。ログファイルの設定方法について詳しくは、ログを参照してください。
AEM 6.4では、メンテナンスタスクはINFOレベルでより詳細な情報を豊富な形式で初期状態でログアウトされます。これにより、メンテナンスタスクの状態がよりわかりやすくなっています。
メンテナンスタスクのアクティビティを監視し、対処するためにサードパーティツール(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 つ目のエントリは実行計画です。
クエリを実行する前に「実行時間を含める」ボックスをチェックすると、このクエリが実行された時間も示され、アプリケーションやデプロイメントでインデックスを最適化するために使用できる詳細情報が得られます。
インデックスマネージャの目的は、インデックスのメンテナンスや、ステータスの表示などのインデックス管理を容易にすることです。
スタートアップスクリーンからツール→操作→診断→に移動し、インデックスマネージャボタンをクリックするとアクセスできます。
また、次の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 Binarys Cleanupタスクには、次の場所からアクセスできます。AEM > Tools > Operations > Maintenance > Daily Maintenance Window > Lucene Binarys Cleanup。
データストアのガベージコレクションについて詳しくは、専用のドキュメントページを参照してください。
ワークフローをメンテナンスダッシュボードからパージすることもできます。ワークフローのパージタスクを実行するには、次の手順が必要です。
ワークフローメンテナンスの詳細については、このページを参照してください。
監査ログのメンテナンスについて詳しくは、別個のドキュメントページを参照してください。
バージョンのパージメンテナンスタスクをスケジュールして、古いバージョンを自動的に削除できます。その結果、バージョン削除ツールを手動で使用する必要が最小限に抑えられます。ツール/操作/メンテナンス/週別メンテナンスウィンドウにアクセスし、次の手順に従って、バージョンの削除タスクをスケジュールおよび設定できます。
追加ボタンをクリックします。
ドロップダウンメニューから「バージョンの削除」を選択します。
バージョンの削除タスクを設定するには、新しく作成したバージョンの削除メンテナンスカードの歯車アイコンをクリックします。
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に表示されます。 このファイルは、次のいずれかの使用可能なメンテナンススケジュールに追加できます。
これにより、対応するリソースが/apps/granite/operations/config/maintenance/schedule
/taskname
に追加されます。タスクが実行モードに依存する場合は、このメンテナンスタスクでアクティブにする必要があるrunmodeの値を持つプロパティgranite.operations.conditions.runmodeをそのノードに設定する必要があります。
システム概要ダッシュボードには、AEMインスタンスの構成、ハードウェア、正常性の概要が表示されます。 つまり、システムヘルスのステータスが明白になり、すべての情報が 1 つのダッシュボードに集約されます。
システム概要ダッシュボードの概要については、このビデオを参照してください。
「システム概要」ダッシュボードにアクセスするには、ツール/操作/システム概要に移動します。
次の表では、システム概要ダッシュボードに表示されるすべての情報について説明します。表示する関連情報がない場合(バックアップが進行中ではない、重要なヘルスチェックはないなど)は、それぞれのセクションに「エントリがありません」というメッセージが表示されます。
ダッシュボード情報を要約したJSON
ファイルは、ダッシュボードの右上隅にある[ダウンロード]ボタンをクリックしてダウンロードすることもできます。JSON
エンドポイントは/libs/granite/operations/content/systemoverview/export.json
で、外部監視用のcurl
スクリプトで使用できます。
セクション | 表示される情報 | これが重要になる状況 | リンク先 |
ヘルスチェック |
|
色の意味:
|
|
メンテナンスタスク |
|
色の意味:
|
|
システム |
|
該当なし | 該当なし |
インスタンス |
|
該当なし | 該当なし |
リポジトリ |
|
該当なし | 該当なし |
配布エージェント |
|
色の意味:
|
配布版ページ |
レプリケーションエージェント |
|
色の意味:
|
レプリケーションページ |
ワークフロー |
前述のステータスごとにクエリが実行されます(400 ミリ秒以内)。400 ミリ秒の時点で、その時点までに取得されたエントリ数が表示されます。 |
判断なし:
|
ワークフローエラーページ |
Sling ジョブ | Sling ジョブ数 - 特定のステータスのジョブの数(ある場合):
|
判断なし:
|
該当なし |
予測ノード数 | 予測数:
ノードの合計数はnodeCounterMBeanから取得され、残りの統計はIndexInfoServiceから取得されます。 |
該当なし | 該当なし |
バックアップ | この場合は、「オンラインバックアップを処理中」と表示されます。 | 該当なし | 該当なし |
インデックス作成 | ディスプレイ:
インデックスまたはクエリスレッドがスレッドダンプに存在する場合。 |
該当なし | 該当なし |