操作ダッシュボード

はじめに

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 から直接アクセスできます。

https://<serveraddress>:port/libs/granite/operations/content/healthreports/healthreportlist.html

カードシステムが表示する状態は、OK、警告、重要​の 3 つです。この状態は、ルールおよびしきい値の結果です。ルールおよびしきい値は、カードの上にマウスポインターを置いてアクションバーのギアアイコンをクリックすることで設定できます。

ヘルスチェックの種類

AEM 6 には次の 2 種類のヘルスチェックがあります。

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

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

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

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

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

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

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

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

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

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 が作成されます。

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

   • 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 つずつ作成されます。**

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 サーバーのホスト定義を追加します。これは、設定マネージャーを使用して、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

ログメッセージ

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

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

ログに記録する内容を設定するには、UI の左上にあるギアボタンから、ロガーを設定します。そこで、ロガーの設定を追加、削除または更新できます。ロガーの設定は、ログレベル（警告／情報／デバッグ）と​フィルター名​で構成されます。フィルター名​には、記録されるログメッセージのソースをフィルター処理する役割があります。また、指定したレベルのすべてのログメッセージをロガーで取り込む必要がある場合は、フィルター名を「root」とします。ロガーのレベルを設定すると、指定したレベル以上のすべてのメッセージの取り込みがトリガーされます。

例：

• すべての​エラー​メッセージを取り込む計画をしている場合は、設定は不要です。エラーメッセージはすべてデフォルトで取り込まれます。

• エラー、警告、情報​のすべてのメッセージを取り込む計画をしている場合は、ロガー名を「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 によるクエリの実行方法を把握することが、クエリを最適化するための第一歩です。

クエリの説明を実行は、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 ファイルをダウンロードします。ステータス、クラスローダー、スタックトレースなど、各スレッドに関する情報が提供されます。

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

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

自動メンテナンスタスク

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

操作ダッシュボードのメンテナンスページを開くには、AEM のようこそ画面から​ツール／操作／ダッシュボード／メンテナンス​を選択するか、次のリンクに直接アクセスします。

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

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

1. 日別メンテナンスウィンドウ​メニューの下の​リビジョンのクリーンアップ​タスク。
2. 日別メンテナンスウィンドウ​メニューの下の Lucene バイナリクリーンアップ​タスク。
3. 週別メンテナンスウィンドウ​メニューの下の​ワークフローのパージ​タスク。
4. 週別メンテナンスウィンドウ​メニューの下の​データストアのガベージコレクション​タスク。
5. 週別メンテナンスウィンドウ​メニューの下の​監査ログのメンテナンス​タスク。
6. 週別メンテナンスウィンドウ​メニューの下の​バージョンのパージのメンテナンス​タスク。

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

2 つのメンテナンスカードの歯車アイコンをクリックすることによって、タイミングを設定することもできます。

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

リビジョンのクリーンアップの実行について詳しくは、この記事を参照してください。

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 スクリプトで使用して、外部監視をおこなうことができます。