操作ダッシュボード

はじめに

AEM 6 の操作ダッシュボードは、システムオペレーターがAEMシステムの正常性を一目で監視するのに役立ちます。 また、AEM が関連する側面に関して自動生成された診断情報も提供され、自己完結型のメンテナンス自動化を設定および実行して、プロジェクト操作とサポートケースを大幅に削減できます。操作ダッシュボードは、カスタムヘルスチェックおよびメンテナンスタスクを使用して拡張できます。 また、操作ダッシュボードのデータは、JMX を介して外部の監視ツールからアクセスできます。

操作ダッシュボード：

• ワンクリックでのシステムステータスで、運用部門の効率化を支援
• システムヘルスの概要を、1 つの場所で一元的に提供します。
• 問題の検出、分析、修正に要する時間を短縮
• 自己完結型のメンテナンスを自動化し、プロジェクト運用コストを大幅に削減

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 種類のヘルスチェックがあります。

1. 個々のヘルスチェック
2. 複合ヘルスチェック

An 個別ヘルスチェック は、ステータスカードに対応する単一のヘルスチェックです。 個々のヘルスチェックは、ルールやしきい値を使用して設定でき、特定されたヘルスの問題を解決するための 1 つ以上のヒントやリンクを提供できます。 次に、「エラーをログに記録」チェックの例を示します。インスタンスログに ERROR エントリがある場合、ヘルスチェックの詳細ページに表示されます。 ページの上部に、「診断ツール」セクションの「ログメッセージ」アナライザーへのリンクが表示されます。これにより、これらのエラーをより詳細に分析し、ロガーを再設定できます。

A 複合ヘルスチェック は、複数の個々のチェックから情報を集計するチェックです。

複合ヘルスチェックは、フィルタータグ​を使用して設定します。基本的に、同じフィルタータグを持つ単一チェックはすべて、複合ヘルスチェックとしてグループ化されます。複合ヘルスチェックは、集約した単一チェックのステータスがすべて OK である場合にのみ OK ステータスとなります。

ヘルスチェックを作成する方法

操作ダッシュボードで、個別および複合ヘルスチェックの両方の結果を視覚化できます。

個々のヘルスチェックの作成

個々のヘルスチェックの作成には、次の 2 つの手順が含まれます。Sling ヘルスチェックを実装し、ダッシュボードの設定ノードにヘルスチェックのエントリを追加します。

1. 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 の名前を定義します。

2. ヘルスチェックの作成後、操作ダッシュボードインターフェイスでアクセスできるように、新しい設定ノードを作成する必要があります。この手順では、ヘルスチェックの 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 設定を追加することです。 操作ダッシュボードに表示するには、簡単なチェックと同じ方法で、新しい設定ノードを追加する必要があります。

1. OSGI コンソールで web 設定マネージャーに移動します。これを行うには、https://serveraddress:port/system/console/configMgr にアクセスします。

2. Apache Sling Composite Health Check というエントリを検索します。見つかったら、システムチェック用とセキュリティチェック用の 2 つの設定が既に使用可能であることを確認します。

3. 設定の右側にある「+」ボタンを押して新しい設定を作成します。以下のような新しいウィンドウが表示されます。

   

4. 設定を作成して保存します。 新しい設定で Mbean が作成されます。

   各設定プロパティの目的は次のとおりです。

   • 名前 (hc.name): 複合ヘルスチェックの名前。 意味のある名前を付けることをお勧めします。
   • タグ (hc.tags): このヘルスチェックのタグ。 この複合ヘルスチェックが別の複合ヘルスチェックの一部を目的とする場合（ヘルスチェックの階層など）、この複合が関連するタグを追加します。
   • MBean 名 (hc.mbean.name): この複合ヘルスチェックの JMX MBean に与える Mbean の名前。
   • Filter Tags（filter.tags）：​これは複合ヘルスチェック専用のプロパティです。複合が集約するタグを指定します。複合ヘルスチェックは、そのグループの下に、この複合のいずれかのフィルタータグに一致するタグを持つすべてのヘルスチェックを集約します。例えば、test および check というフィルタータグを持つ複合ヘルスチェックは、タグプロパティ（hc.tags）に test タグと check タグのいずれかが含まれている個別および複合のすべてのヘルスチェックを集約します。
   メモ

   Apache Sling 複合ヘルスチェックの新しい設定ごとに、新しい JMX Mbean が 1 つずつ作成されます。**

5. 最後に、上記で作成した複合ヘルスチェックのエントリを、操作ダッシュボードの設定ノードに追加する必要があります。この手順は、個別ヘルスチェックの場合と同じです。タイプが 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 で提供されているヘルスチェック

Nagios での監視

ヘルスチェックダッシュボードは、Granite JMX Mbean 経由で Nagios と統合できます。以下の例では、AEM を実行しているサーバー上で使用されているメモリを表示するチェックの追加方法を説明します。

1. 監視サーバーで Nagios を設定してインストールします。

2. 次に、Nagios Remote Plugin Executor（NRPE）をインストールします。

   メモ

   Nagios と NRPE をシステムにインストールする方法について詳しくは、 Nagios ドキュメント.

3. AEMサーバーのホスト定義を追加します。 これは、Configuration Manager を使用して Nagios XI Web インターフェイスで実行できます。

   1. ブラウザーを開き、Nagios サーバーを指します。
   2. トップメニューの「Configure」ボタンをクリックします。
   3. 左側のウィンドウで、「Advanced Configuration」の下の「Core Config Manager」をクリックします。
   4. 「Monitoring」セクションの下の「Hosts」リンクをクリックします。
   5. ホスト定義を追加します。

   

   以下は、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
   }
   

4. Nagios と NRPE を AEM サーバーにインストールします。

5. のインストール check_http_json プラグインを両方のサーバーで使用できます。

6. 両方のサーバーに汎用の 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$'
   
   }
   

7. 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>
   
       }
   

8. Nagios ダッシュボードで新しく作成されたサービスを確認します。

   

診断ツール

操作ダッシュボードでは、ヘルスチェックダッシュボードから発生する警告の根本原因の特定とトラブルシューティングに役立つ診断ツールにアクセスし、システムオペレーターに重要なデバッグ情報を提供することもできます。

最も重要な機能は次のとおりです。

• ログメッセージアナライザ
• ヒープとスレッドダンプにアクセスする機能
• 要求およびクエリーパフォーマンスの分析

「診断ツール」画面を開くには、AEM のようこそ画面から​ツール／操作／診断​を選択します。次の URL に直接アクセスして画面にアクセスすることもできます：https://serveraddress:port/libs/granite/operations/content/diagnosis.html

ログメッセージ

ログメッセージユーザーインターフェイスには、デフォルトですべての ERROR メッセージが表示されます。 さらにログメッセージを表示する場合は、適切なログレベルでロガーを設定する必要があります。

ログメッセージではメモリ内のログ追加機能を使用するので、ログファイルとは関係ありません。また、この UI でログレベルを変更しても、従来のログファイルに記録される情報は変更されません。この UI でのロガーの追加および削除は、メモリ内のロガーのみに影響します。また、ロガーの設定を変更すると、それ以降のメモリ内ロガーに反映されます。既にログに記録されていて該当しなくなったエントリは削除されませんが、同様のエントリは今後は記録されません。

UI の左上の歯車ボタンからロガー設定を指定することで、ログに記録する内容を設定できます。 ここで、ロガー設定を追加、削除または更新できます。 ロガー設定は、 ログレベル (WARN / INFO / DEBUG) と フィルター名. この フィルター名 には、ログに記録されるログメッセージのソースをフィルタリングする役割があります。 または、ロガーが指定されたレベルのすべてのログメッセージを取り込む場合、フィルター名は「root". ロガーのレベルを設定すると、指定したレベル以上のすべてのメッセージのキャプチャがトリガーされます。

例：

• すべての エラー messages — 設定は不要です。 デフォルトでは、すべての ERROR メッセージが取り込まれます。

• すべての エラー, 警告 および 情報 messages — ロガー名は次のように設定する必要があります。"root」、およびロガーレベルは次の場所に設定します。 情報.

• 特定のパッケージ（com.adobe.granite など）からのすべてのメッセージをキャプチャする予定がある場合は、ロガー名を次のように設定する必要があります。"com.adobe.granite"とロガーレベルを次のように設定します。 デバッグ ( これは、 エラー, 警告, 情報 および デバッグ メッセージ ) に含まれます。

Log level: INFO
DATE+TIME [MaintanceLogger] Name=<MT_NAME>, Status=<MT_STATUS>, Time=<MT_TIME>, Error=<MT_ERROR>, Details=<MT_DETAILS>

リクエストのパフォーマンス

リクエストのパフォーマンスページを使用すると、処理されるページリクエストの処理速度が最も遅いものを分析できます。 このページに登録されるのはコンテンツリクエストのみです。 具体的には、次のリクエストが取り込まれます。

1. /content の下のリソースにアクセスする要求
2. /etc/design の下のリソースにアクセスする要求
3. ".html" 拡張子を持つ要求

ページには次の情報が表示されます。

• リクエストがおこなわれた時刻
• リクエストの URL とメソッド
• 時間（ミリ秒）

デフォルトでは、最も遅い 20 件のページリクエストが取り込まれますが、この制限は設定マネージャーで変更できます。

クエリーパフォーマンス

「クエリーパフォーマンス」ページでは、システムで実行される最も遅いクエリーを分析できます。この情報は、JMX Mbean のリポジトリから提供されます。Jackrabbit では、com.adobe.granite.QueryStat JMX Mbean がこの情報を提供し、Oak リポジトリでは、org.apache.jackrabbit.oak.QueryStats. が提供します。

ページには次の情報が表示されます。

• クエリが実行された時刻
• クエリの言語
• クエリが発行された回数
• クエリの文
• 時間（ミリ秒）

クエリの説明を実行

Oak は、任意のクエリに対して、リポジトリ内の oak:index ノード。 クエリに応じて、Oak で異なるインデックスが選択される場合があります。 Oak がクエリを実行する方法を理解することは、クエリを最適化する最初の手順です。

クエリの説明を実行は、Oak がクエリを実行する方法を説明するツールです。 アクセスするには、 ツール/運営/診断 AEMのようこそ画面から、 クエリパフォーマンス そして、 クエリの説明を実行 タブをクリックします。

機能

• Xpath、JCR-SQL および JCR-SQL2 クエリ言語をサポート
• 指定したクエリの実際の実行時間をレポート
• 時間のかかるクエリを検出し、潜在的に時間のかかる可能性のあるクエリに関する警告を表示
• クエリの実行に使用された Oak インデックスをレポートします
• 実際の Oak クエリエンジンの説明を表示
• クリックして読み込むことができる、遅いクエリと人気の高いクエリのリストを提供します

「クエリの説明を実行」UI を表示したら、クエリを入力し、 説明 ボタン：

「クエリの説明」セクションの最初のエントリは、実際の説明です。 説明は、クエリの実行に使用されたインデックスのタイプを示します。

2 つ目のエントリは実行プランです。

ティック 実行時間を含める ボックスを開いてからクエリを実行すると、でクエリが実行された時間も表示され、アプリケーションやデプロイメントのインデックスの最適化に使用できる詳細情報が表示されます。

インデックスマネージャ

インデックスマネージャの目的は、インデックスの管理や、インデックスのステータスの表示など、インデックスの管理を容易にすることです。

これには、AEM のようこそ画面から​ツール／操作／診断を選択し、「​インデックスマネージャー**」ボタンをクリックしてアクセスできます。

この URL から直接アクセスすることもできます。https://serveraddress:port/libs/granite/operations/content/diagnosistools/indexManager.html

UI を使用して、画面の左上隅にある検索ボックスにフィルター条件を入力することで、テーブル内のインデックスをフィルタリングできます。

ステータス ZIP をダウンロード

これにより、トリガーのステータスと設定に関する有用な情報を含む zip のダウンロードが行われます。 アーカイブには、インスタンス設定、バンドルのリスト、OSGI、Sling の指標と統計が含まれるので、ファイルのサイズが大きくなります。ステータス ZIP をダウンロード​ウィンドウを使用して、大きなステータスファイルの影響を減らすことができます。 このウィンドウには、AEM／ツール／操作／診断／ステータス ZIP をダウンロード​からアクセスできます。

このウィンドウでは、エクスポートするもの（ログファイルやスレッドダンプ）および現在の日付を基準にしてダウンロードに含めるログの日数を選択できます。

スレッドダンプをダウンロード

これにより、トリガーに存在するスレッドに関する情報を含む zip のダウンロードがシステムに含まれます。 各スレッドに関する情報（ステータス、クラスローダ、スタックトレースなど）が提供されます。

ヒープダンプをダウンロード

また、後で分析するために、ヒープのスナップショットをダウンロードすることもできます。 これにより、数百 MB の順で、大きなファイルのダウンロードがトリガーになることに注意してください。

自動メンテナンスタスク

自動メンテナンスタスクページでは、定期的な実行がスケジュールされている推奨メンテナンスタスクを表示および追跡できます。 タスクはヘルスチェックシステムと統合されています。 タスクは、インターフェイスから手動で実行することもできます。

操作ダッシュボードのメンテナンスページに移動するには、に移動する必要があります。 ツール/運営/ダッシュボード/メンテナンス AEMのようこそ画面から、または次のリンクに直接移動します。

https://serveraddress:port/libs/granite/operations/content/maintenance.html

操作ダッシュボードでは、次のタスクを使用できます。

1. 「リビジョンのクリーンアップ」タスク ( 日別メンテナンスウィンドウ メニュー

2. Lucene バイナリクリーンアップ​タスクは、 日別メンテナンスウィンドウ メニュー

3. ワークフローのパージ​タスク ( 週別メンテナンスウィンドウ メニュー

4. 週別メンテナンスウィンドウ​メニューの下の​データストアのガベージコレクション​タスク。

5. 週別メンテナンスウィンドウ​メニューの下の​監査ログのメンテナンス​タスク。

6. 週別メンテナンスウィンドウ​メニューの下の​バージョンのパージのメンテナンス​タスク。

毎日のメンテナンスウィンドウのデフォルトのタイミングは、午前 2 時から午前 5 時です。 週別メンテナンスウィンドウで実行するように設定されたタスクは、土曜日の午前 1 時から 2 時の間に実行されます。

また、2 つのメンテナンスカードのギアアイコンを押すことで、タイミングを設定することもできます。

リビジョンのクリーンアップ

AEM 6.4 でのリビジョンのクリーンアップの実行の詳細については、 この専用記事を参照してください.

Lucene バイナリクリーンアップ

Lucene バイナリクリーンアップタスクを使用すると、Lucene バイナリをパージし、実行中のデータストアのサイズ要件を減らすことができます。 これは、以前はデータストアのガベージコレクションの正常な実行に依存していましたが、Lucene のバイナリチャーンが毎日再要求されるようになったからです。

メンテナンスタスクは Lucene 関連のリビジョンガベージを減らすために開発されましたが、タスクを実行すると、次のような一般的な効率の向上が得られます。

• データストアのガベージコレクションタスクの毎週の実行は、より迅速に完了します
• AEM の全体的なパフォーマンスがわずかに向上することもあります。

Lucene バイナリクリーンアップタスクには、AEM／ツール／操作／メンテナンス／日別メンテナンスウィンドウ／Lucene バイナリクリーンアップ​からアクセスできます。

データストアのガベージコレクション

データストアのガベージコレクションについて詳しくは、 ドキュメントページ.

ワークフローのパージ

ワークフローは、メンテナンスダッシュボードからパージすることもできます。 ワークフローのパージタスクを実行するには、次の操作が必要です。

1. をクリックします。 週別メンテナンスウィンドウ ページ。
2. 次のページで、 再生 ボタン ワークフローのパージ カード。

監査ログのメンテナンス

監査ログのメンテナンスについては、別のドキュメントページを参照してください。

バージョンのパージ

バージョンのパージメンテナンスタスクをスケジュールして、古いバージョンを自動的に削除できます。これにより、バージョンのパージツールを手動で実行する必要性を最小限に抑えることができます。バージョンのパージタスクをスケジュールして設定するには、ツール／操作／メンテナンス／週別メンテナンスウィンドウ​にアクセスし、次の手順に従います。

1. 「追加」ボタンをクリックします。

2. ドロップダウンメニューから「バージョンのパージ」を選択します。

   

3. バージョンのパージタスクを設定するには、新しく作成されたバージョンのパージメンテナンスカードの​歯車​アイコンをクリックします。

   

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) を実装する必要があります。さらに、以下に示すいくつかのサービス登録プロパティがメンテナンスタスクとして検出されることを宣言する必要があります。

上記のサービスプロパティとは別に、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 スクリプトで使用して、外部監視をおこなうことができます。

Business.Adobe.com リソース

Ecommerce Integrations Asset Collections Personalized Communications Embedded Charts Dynamic Forms Content Management System