操作ダッシュボード

はじめに

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 Configuration Manager に移動します。 アクセス 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): 複合ヘルスチェックに固有のプロパティ。 これらのタグは複合によって集計されます。 複合ヘルスチェックは、この複合のフィルタタグのいずれかに一致するタグを持つすべてのヘルスチェックをグループの下に集計します。 例えば、フィルタータグを持つ複合ヘルスチェック テスト および check​は、 テスト および check タグプロパティ ( hc.tags) をクリックします。
   メモ

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

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

ヘルスチェック設定

デフォルトでは、標準の AEM インスタンスの場合、ヘルスチェックは 60 秒ごとに実行されます。

OSGi 設定の​クエリヘルスチェック設定（com.adobe.granite.queries.impl.hc.QueryHealthCheckMetrics）で​期間​を設定できます。

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 ダッシュボードで新しく作成されたサービスを確認します。

   

診断ツール

また、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"と入力します。 また、ロガーレベルは次のように設定されます。 デバッグ ( これにより、 エラー, 警告, 情報、および デバッグ メッセージ ) に含まれます。

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:00～午前 5:00 です。週別メンテナンスウィンドウで実行するように設定されたタスクは、土曜日の午前 1:00～午前 2:00 に実行されます。

また、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).さらに、次に示すように、メンテナンスタスクとして検出されるサービス登録プロパティを複数宣言する必要があります。

上記のサービスプロパティとは別に、 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 外部監視用のスクリプト。

Business.Adobe.com リソース

Auto Form Fill Asset Collections Embedded Charts Mobile Forms Theme Editor Version History