AEM 6 の操作ダッシュボードは、システムオペレーターがAEMシステムの正常性を一目で監視するのに役立ちます。 また、AEMの関連する側面に関する自動生成診断情報を提供し、自己完結型のメンテナンス自動化を設定および実行して、プロジェクトの運用やサポートケースを大幅に削減できます。 操作ダッシュボードは、カスタムヘルスチェックおよびメンテナンスタスクを使用して拡張できます。 また、操作ダッシュボードのデータは、JMX を介して外部の監視ツールからアクセスできます。
操作ダッシュボード:
AEM のようこそ画面からツール/操作に移動してアクセスできます。
操作ダッシュボードにアクセスするには、ログインしたユーザーが「オペレーター」ユーザーグループに属している必要があります。 詳しくは、 ユーザー、グループ、アクセス権の管理.
ヘルスレポートシステムは、Sling ヘルスチェックを通じてAEMインスタンスのヘルスに関する情報を提供します。 この操作は、OSGI、JMX、HTTP リクエスト(JSON を介する)またはタッチ UI を介して実行します。 設定可能な特定のカウンターの測定値としきい値を提供し、場合によっては問題の解決方法に関する情報を提供します。
以下で説明するような、様々な機能があります。
この ヘルスレポート は、特定の製品領域に関する良い状態または悪い状態を示すカードのシステムです。 これらのカードは、Sling ヘルスチェックのビジュアライゼーションで、JMX や他のソースからのデータを集計し、処理された情報を MBean として再び公開します。 これらの MBean は、 JMX Web コンソール、 org.apache.sling.healthcheck ドメイン。
ヘルスレポートインターフェイスには、AEM のようこそ画面のツール/運用/ヘルスレポートメニューからアクセスするか、次の URL から直接アクセスできます。
https://<serveraddress>:port/libs/granite/operations/content/healthreports/healthreportlist.html
カードシステムが表示する状態は、OK、警告、重要の 3 つです。この状態は、ルールおよびしきい値の結果です。ルールおよびしきい値は、カードの上にマウスポインターを置いてアクションバーのギアアイコンをクリックすることで設定できます。
AEM 6 には、次の 2 種類のヘルスチェックがあります。
An 個別ヘルスチェック は、ステータスカードに対応する単一のヘルスチェックです。 個々のヘルスチェックは、ルールやしきい値を使用して設定でき、特定されたヘルスの問題を解決するための 1 つ以上のヒントやリンクを提供できます。 次に、「エラーをログに記録」チェックの例を示します。インスタンスログに ERROR エントリがある場合は、ヘルスチェックの詳細ページでそれらを見つけます。 ページ上部の「診断ツール」セクションに「ログメッセージ」アナライザーへのリンクが表示され、これらのエラーをより詳細に分析し、ロガーを再設定できます。
A 複合ヘルスチェック は、複数の個々のチェックから情報を集計するチェックです。
複合ヘルスチェックは次の手順で設定します。 タグのフィルター. 基本的に、同じフィルタータグを持つすべての単一のチェックは、複合ヘルスチェックとしてグループ化されます。 複合ヘルスチェックは、集計するすべてのチェックに OK ステータスがある場合にのみ OK ステータスになります。
操作ダッシュボードで、個々のヘルスチェックと複合ヘルスチェックの両方の結果を視覚化できます。
個々のヘルスチェックの作成には、次の 2 つの手順が含まれます。Sling ヘルスチェックを実装し、ダッシュボードの設定ノードにヘルスチェックのエントリを追加します。
Sling ヘルスチェックを作成するには、Sling HealthCheck インターフェイスを実装する 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
. ノードのリソースプロパティは、 hc.mean.name (OSGi 設定内)
例えば、設定を作成し、 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
デフォルトでダッシュボードに既に存在する複合チェックの下に論理的に属する個々のヘルスチェックを作成すると、自動的にキャプチャされ、それぞれの複合チェックの下にグループ化されます。 したがって、これらのチェック用に設定ノードを作成する必要はありません。
例えば、個々のセキュリティヘルスチェックを作成する場合は、「セキュリティ」タグが付いている必要があります。 これは、[ 操作 ] ダッシュボードの [ セキュリティチェック ] 複合チェックの下に自動的に表示されます。
ヘルスチェック名 | 説明 |
クエリパフォーマンス | このヘルスチェックは簡略化されました 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 です。 |
同期済みのクロック | このチェックは、 document nodestore クラスター. 次のステータスを返します。
このヘルスチェックの Mbean は、org.apache.sling.healthcheck:name=slingDiscoveryOakSynchronizedClocks,type=HealthCheck です。 |
非同期インデックス | 非同期インデックスのチェック:
Critical ステータスと Warn ステータスの両方のしきい値を設定できます。 このヘルスチェックの 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 しきい値と比較します。
設定できるのは、queued jobs パラメーターの最大数のみで、デフォルト値は 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 です。 |
スケジューラーヘルスチェック | このチェックは、インスタンスで Quartz ジョブが 60 秒以上実行されている場合に警告を返します。 許容可能な期間しきい値は設定できます。 このヘルスチェックの 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サーバーのホスト定義を追加します。 このタスクは、Configuration Manager を使用して 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 ダッシュボードで新しく作成されたサービスを確認します。
また、Operation Dashboard では、Health Check Dashboard からの警告の根本原因の特定とトラブルシューティングに役立つ診断ツールにアクセスし、システムオペレーターに重要なデバッグ情報を提供できます。
最も重要な機能は次のとおりです。
「診断ツール」画面を開くには、AEM のようこそ画面からツール/操作/診断を選択します。次の URL に直接アクセスして画面にアクセスすることもできます:https://serveraddress:port/libs/granite/operations/content/diagnosis.html
ログメッセージユーザーインターフェイスには、デフォルトですべての ERROR メッセージが表示されます。 さらにログメッセージを表示する場合は、適切なログレベルでロガーを設定します。
ログメッセージはメモリログアペンダーを使用するので、ログファイルとは関係ありません。 もう 1 つの結果として、この UI でログレベルを変更しても、従来のログファイルに記録される情報は変更されません。 この UI でのロガーの追加と削除は、メモリロガーにのみ影響します。 また、ロガー設定の変更は、in memory logger の将来に反映されます。 既にログに記録され、関連性がなくなったエントリは削除されませんが、類似したエントリは今後ログに記録されません。
UI の左上の歯車ボタンからロガー設定を指定することで、ログに記録する内容を設定できます。 ここで、ロガー設定を追加、削除または更新できます。 ロガー設定は、 ログレベル (WARN / INFO / DEBUG) と フィルター名. この フィルター名 には、ログに記録されるログメッセージのソースをフィルタリングする役割があります。 または、ロガーが指定されたレベルのすべてのログメッセージを取り込む場合、フィルター名は「root". ロガーのレベルを設定すると、指定したレベル以上のすべてのトリガーがキャプチャされます。
例:
すべての エラー messages — 設定は不要です。 デフォルトでは、すべての ERROR メッセージが取り込まれます。
すべての エラー, 警告 および 情報 messages — ロガー名は次のように設定する必要があります。"root」、およびロガーレベルは次の場所に設定します。 情報.
特定のパッケージ(com.adobe.granite など)からのすべてのメッセージをキャプチャする予定がある場合は、ロガー名を次のように設定する必要があります。"com.adobe.granite"と入力します。 また、ロガーレベルは次のように設定されます。 デバッグ ( これにより、 エラー, 警告, 情報、および デバッグ メッセージ ) に含まれます。
指定したフィルタを介して ERROR メッセージのみを取り込むロガー名を設定することはできません。 デフォルトでは、すべての ERROR メッセージが取り込まれます。
ログメッセージのユーザーインターフェイスには、実際のエラーログは反映されていません。 UI で他のタイプのログメッセージを設定しない限り、ERROR メッセージのみが表示されます。 特定のログメッセージを表示する方法については、上記の手順を参照してください。
診断ページの設定は、ログファイルの記録内容に影響しません。逆に、ログファイルの記録内容にも影響しません。 したがって、エラーログが INFO メッセージを取得する場合がありますが、ログメッセージ UI に表示されないことがあります。 また、UI を使用すると、エラーログに影響を与えることなく、特定のパッケージから DEBUG メッセージを取得できます。 ログファイルの設定方法について詳しくは、 ログ.
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 がクエリを実行する方法を説明するツールです。 アクセスするには、 ツール/運営/診断 AEMのようこそ画面から 次に、「 クエリパフォーマンス そして、 クエリの説明を実行 タブをクリックします。
機能
「クエリの説明を実行」UI を表示したら、クエリを入力し、 説明 ボタン:
「クエリの説明」セクションの最初のエントリは、実際の説明です。 この説明は、クエリの実行に使用されたインデックスのタイプを示します。
2 つ目のエントリは実行プランです。
ティック 実行時間を含める ボックスを開いてからクエリを実行すると、そのクエリが実行された時間も表示されます。 この ノード数を含める オプションは、ノード数をレポートします。 レポートでは、アプリケーションやデプロイメントのインデックスの最適化に使用できる詳細情報を確認できます。
インデックスマネージャの目的は、インデックスの管理や、インデックスのステータスの表示など、インデックスの管理を容易にすることです。
これには、AEM のようこそ画面からツール/操作/診断を選択し、「インデックスマネージャー**」ボタンをクリックしてアクセスできます。
この URL から直接アクセスすることもできます。https://serveraddress:port/libs/granite/operations/content/diagnosistools/indexManager.html
UI を使用して、画面の左上隅にある検索ボックスにフィルター条件を入力することで、テーブル内のインデックスをフィルタリングできます。
このアクションは、トリガーのステータスと設定に関する有用な情報を含む zip のダウンロードを行います。 アーカイブには、インスタンス設定、バンドルのリスト、OSGI、Sling 指標および統計が含まれています。これにより、大きなファイルが生成される場合があります。 サイズの大きいステータスファイルの影響を減らすには、ステータス ZIP をダウンロードウィンドウを使用します。このウィンドウには、AEM/ツール/操作/診断/ステータス ZIP をダウンロードからアクセスできます。
このウィンドウから、エクスポートする対象(ログファイルおよびスレッドダンプ)と、現在の日付を基準にしたダウンロードに含まれるログの日数を選択できます。
このアクションは、トリガーに存在するスレッドに関する情報を含む zip のダウンロードを行います。 各スレッドに関する情報(ステータス、クラスローダ、スタックトレースなど)が提供されます。
ヒープのスナップショットをダウンロードして、後で分析できます。 このアクションは、大きな(数百 MB の)ファイルのダウンロードをトリガーします。
自動メンテナンスタスクページでは、定期的な実行がスケジュールされている推奨メンテナンスタスクを表示および追跡できます。 タスクはヘルスチェックシステムと統合されています。 タスクは、インターフェイスから手動で実行することもできます。
運用ダッシュボードのメンテナンスページに移動するには、AEMのようこそ画面からに移動します。 ツール/運営/ダッシュボード/メンテナンスまたはこのリンクを直接クリックしてください。
https://serveraddress:port/libs/granite/operations/content/maintenance.html
操作ダッシュボードでは、次のタスクを使用できます。
日別メンテナンスウィンドウのデフォルトのタイミングは、午前 2:00~午前 5:00 です。週別メンテナンスウィンドウで実行するように設定されたタスクは、土曜日の午前 1:00~午前 2:00 に実行されます。
また、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 | このタスクに表示されるタイトル | 特別メンテナンスタスク | 必須 |
job.topics | メンテナンスタスクの一意のトピックです。 Apache Sling ジョブ処理は、メンテナンスタスクを実行するためにこのトピックでジョブを開始します。タスクがこのトピックに登録されているので、実行されます。 トピックはで始める必要があります com/adobe/granite/maintenance/job/ |
com/adobe/granite/maintenance/job/MyMaintenanceTask | 必須 |
上記のサービスプロパティとは別に、 process()
メソッド JobConsumer
インターフェイスは、メンテナンスタスクに実行する必要があるコードを追加して実装する必要があります。 指定された 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インスタンスの設定、ハードウェア、ヘルスの概要を表示します。 システムのヘルスステータスは透過的で、すべての情報が単一のダッシュボードに集計されます。
システム概要ダッシュボードの概要については、このビデオを参照してください。
システム概要ダッシュボードにアクセスするには、ツール/操作/システム概要に移動します。
次の表に、「システム概要」ダッシュボードに表示されるすべての情報を示します。 表示する関連情報がない場合(バックアップが進行中でない場合など、重要なヘルスチェックがない場合など)は、各セクションに「エントリなし」メッセージが表示されます。
また、 JSON
ファイルをクリックしてダッシュボード情報を要約する ダウンロード 」ボタンをクリックします。 この JSON
endpoint is /libs/granite/operations/content/systemoverview/export.json
また、 curl
外部監視用のスクリプト。
セクション | 表示される情報 | これが重要になる状況 | リンク先 |
ヘルスチェック |
|
視覚的に示す:
|
|
メンテナンスタスク |
|
視覚的に示す:
|
|
システム |
|
該当なし | 該当なし |
インスタンス |
|
該当なし | 該当なし |
リポジトリ |
|
該当なし | 該当なし |
配布エージェント |
|
視覚的に示す:
|
配布ページ |
レプリケーションエージェント |
|
視覚的に示す:
|
レプリケーションページ |
ワークフロー |
上記に示した各ステータスに対して、クエリが実行されます(制限は 400 ミリ秒)。 400 ミリ秒で、その時点までに取得されたエントリ数が表示されます。 |
未解釈:
|
ワークフローエラーページ |
Sling ジョブ | Sling ジョブ数 — 特定のステータスのジョブの数(存在する場合):
|
未解釈:
|
該当なし |
予測ノード数 | 推定数:
ノードの合計数は nodeCounterMBean から取得しますが、残りの統計は IndexInfoService から取得します。 |
該当なし | 該当なし |
バックアップ | [ オンラインバックアップ中 ] が表示された場合は、[ オンラインバックアップ中 ] と表示されます。 | 該当なし | 該当なし |
インデックス作成 | 表示:
インデックス作成またはクエリスレッドがスレッドダンプに存在する場合。 |
該当なし | 該当なし |