操作ダッシュボード operations-dashboard
はじめに introduction
AEM 6 の操作ダッシュボードは、システムオペレーターが AEM のシステムヘルスを一目で監視するために役立ちます。また、AEM が関連する側面に関して自動生成された診断情報も提供され、自己完結型のメンテナンス自動化を設定および実行して、プロジェクト運営とサポートケースを大幅に削減できます。操作ダッシュボードは、カスタムのヘルスチェックおよびメンテナンスタスクによって拡張できます。さらに、外部監視ツールから JMX を使用して操作ダッシュボードのデータにアクセスできます。
操作ダッシュボードの特徴は次のとおりです。
- ワンクリックのシステムステータスで、運営部門の効率向上に役立ちます。
- システムヘルスの概要を、1 つの場所で一元的に提供します。
- 問題の発見、分析および修正にかかる時間を短縮します。
- 自己完結型のメンテナンス自動化により、プロジェクトの運営コストを大幅に削減します。
AEM のようこそ画面から ツール/操作 に移動してアクセスできます。
ヘルスレポート health-reports
ヘルスレポートシステムは、Sling ヘルスチェックを使用して AEM インスタンスのヘルスに関する情報を提供します。これを行うには、OSGI、JMX、HTTP のいずれかのリクエスト(JSON 経由)またはタッチ UI を使用します。設定可能なカウンターの測定値やしきい値を提供し、場合によっては、問題の解決方法に関する情報も提供します。
以下で説明するような、様々な機能があります。
ヘルスチェック health-checks
ヘルスレポート は、特定の製品領域に関するヘルスの良好または不良を示すカードのシステムです。これらのカードは、Sling ヘルスチェックのビジュアライゼーションで、JMX および他のソースからデータを集計し、処理した情報を MBean として再公開します。これらの MBean は、org.apache.sling.healthcheck ドメイン以下にある JMX web コンソールで検査できます。
ヘルスレポートインターフェイスには、AEM のようこそ画面の ツール/運用/ヘルスレポート メニューからアクセスするか、次の URL から直接アクセスできます。
https://<serveraddress>:port/libs/granite/operations/content/healthreports/healthreportlist.html
カードシステムが表示する状態は、OK、警告、重要 の 3 つです。この状態は、ルールおよびしきい値の結果です。ルールおよびしきい値は、カードの上にマウスポインターを置いてアクションバーのギアアイコンをクリックすることで設定できます。
ヘルスチェックの種類 health-check-types
AEM 6 には次の 2 種類のヘルスチェックがあります。
- 個別ヘルスチェック
- 複合ヘルスチェック
個別ヘルスチェック は、ステータスカードに対応する単一のヘルスチェックです。個別ヘルスチェックは、ルールまたはしきい値で設定でき、特定されたヘルスの問題を解決するための 1 つ以上のヒントおよびリンクを提供できます。「ログエラー」チェックを例に説明します。インスタンスログにエラーエントリがある場合、ヘルスチェックの詳細ページに表示されます。ページ上部の「診断ツール」セクションに、「ログメッセージ」アナライザーがあります。これにより、これらのエラーをより詳細に分析してロガーを再設定できます。
複合ヘルスチェック は、複数の個別チェックから情報を集約するチェックです。
複合ヘルスチェックは、フィルタータグ を使用して設定します。基本的に、同じフィルタータグを持つ単一チェックはすべて、複合ヘルスチェックとしてグループ化されます。複合ヘルスチェックは、集約した単一チェックのステータスがすべて OK である場合にのみ OK ステータスとなります。
ヘルスチェックを作成する方法 how-to-create-health-checks
操作ダッシュボードで、個別および複合ヘルスチェックの両方の結果を視覚化できます。
個別ヘルスチェックの作成 creating-an-individual-health-check
個別ヘルスチェックは、2 段階の手順で作成します。Sling ヘルスチェックを実装し、ヘルスチェックのエントリをダッシュボードの設定ノードに追加します。
-
Sling ヘルスチェックを作成するには、Sling ヘルスチェックインターフェイスを実装する OSGI コンポーネントを作成する必要があります。このコンポーネントをバンドル内に追加します。コンポーネントのプロパティにより、ヘルスチェックが完全に特定されます。コンポーネントがインストールされると、ヘルスチェック用の JMX MBean が自動的に作成されます。詳しくは、Sling ヘルスチェックドキュメントを参照してください。
OSGI サービスコンポーネントの注釈を含む、Sling ヘルスチェックコンポーネントの例:
code language-java @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 } }
note note NOTE 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
- タイプ:
note note NOTE 上記のリソースパスを作成するには、ヘルスチェックの MBean 名が「test」の場合、パス /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck
の末尾に「test」を追加します。最終的なパスは次のようになります。 /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/test
note note NOTE /apps/settings/granite/operations/hc
パスに、true に設定された次のプロパティがあることを確認します。sling:configCollectionInherit
sling:configPropertyInherit
この手順により、設定マネージャーで新しい設定が /libs
の既存の設定と結合されます。 -
複合ヘルスチェックの作成 creating-a-composite-health-check
複合ヘルスチェックの役割は、一般的な機能のセットを共有するいくつかの個別ヘルスチェックを集約することです。例えば、セキュリティ複合ヘルスチェックは、セキュリティ関連の検証を実行するすべての個別ヘルスチェックをグループ化します。複合チェックを作成するには、まず、新しい OSGI 設定を追加します。操作ダッシュボードに表示させるために、シンプルなチェックと同じように、新しい設定ノードを追加する必要があります。
-
OSGI コンソールで web 設定マネージャーに移動します。次にアクセスします。
https://serveraddress:port/system/console/configMgr
-
Apache Sling Composite Health Check というエントリを検索します。見つかったら、システムチェック用とセキュリティチェック用の 2 つの設定が既に使用可能であることを確認します。
-
設定の右側にある「+」ボタンを押して設定を作成します。以下のような新しいウィンドウが表示されます。
-
設定を作成し、保存します。新しい設定で 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 タグのいずれかが含まれている個別および複合のすべてのヘルスチェックを集約します。
note note NOTE 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
- タイプ:
note note NOTE デフォルトでダッシュボードに既に存在する複合チェックの下に論理的に属する個々のヘルスチェックを作成した場合、自動的にキャプチャされ、それぞれの複合チェックの下にグループ化されます。したがって、これらのチェック用に設定ノードを作成する必要はありません。 例えば、個々のセキュリティヘルスチェックを作成し、「セキュリティ」タグを割り当てると、インストールされます。操作ダッシュボードのセキュリティチェック複合チェックの下に自動的に表示されます。 -
AEM で提供されているヘルスチェック health-checks-provided-with-aem
ヘルスチェック設定 health-check-configuration
デフォルトでは、標準の AEM インスタンスの場合、ヘルスチェックは 60 秒ごとに実行されます。
OSGi 設定の クエリヘルスチェック設定(com.adobe.granite.queries.impl.hc.QueryHealthCheckMetrics)で 期間 を設定できます。
外部サービスを使用した監視 monitoring-with-external-services
外部のテクノロジーやベンダーとの統合が可能です。関連する詳細については、ドキュメントを参照してください。
診断ツール diagnosis-tools
操作ダッシュボードからは、診断ツールにもアクセスできます。診断ツールは、ヘルスチェックダッシュボードからの警告の根本原因の発見やトラブルシューティングに役立つほか、システムオペレーターに重要なデバッグ情報を提供することもできます。
最も重要な機能は以下のとおりです。
- ログメッセージ分析
- ヒープおよびスレッドダンプにアクセスする機能
- 要求およびクエリーパフォーマンスの分析
「診断ツール」画面を開くには、AEM のようこそ画面から ツール/操作/診断 を選択します。次の URL に直接アクセスして画面にアクセスすることもできます:https://serveraddress:port/libs/granite/operations/content/diagnosis.html
ログメッセージ log-messages
ログメッセージユーザーインターフェイスには、デフォルトですべてのエラーメッセージが表示されます。表示されるログメッセージを増やす場合は、該当するログレベルでロガーを設定する必要があります。
ログメッセージではメモリ内のログ追加機能を使用するので、ログファイルとは関係ありません。また、この 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>
リクエストパフォーマンス request-performance
リクエストパフォーマンスページでは、処理時間が最も長いページリクエストを分析できます。このページではコンテンツリクエストのみが登録されます。具体的には、以下のリクエストが取り込まれます。
/content
の下のリソースにアクセスする要求/etc/design
の下のリソースにアクセスする要求".html"
拡張子を持つ要求
このページには以下の項目が表示されます。
- リクエストが行われた時刻
- URL とリクエストのメソッド
- 所要時間(ミリ秒単位)
デフォルトでは、所要時間が長いほうから 20 個のページリクエストが取り込まれますが、この制限は設定マネージャーで変更できます。
クエリーパフォーマンス query-performance
「クエリーパフォーマンス」ページでは、システムで実行される最も遅いクエリーを分析できます。この情報は、JMX Mbean のリポジトリから提供されます。Jackrabbit では、com.adobe.granite.QueryStat
JMX Mbean がこの情報を提供し、Oak リポジトリでは、org.apache.jackrabbit.oak.QueryStats.
が提供します。
このページには以下の項目が表示されます。
- クエリが行われた時刻
- クエリの言語
- クエリの発行回数
- クエリのステートメント
- 所要時間(ミリ秒単位)
クエリの説明を実行 explain-query
どのようなクエリでも、Oak は、リポジトリ内の oak:index ノードの下で定義されている Oak インデックスに基づいて最適な実行方法の計算を試みます。クエリごとに異なるインデックスが Oak によって選択されます。Oak によるクエリの実行方法を把握することが、クエリを最適化するための第一歩です。
クエリの説明を実行は、Oak によるクエリの実行方法を説明するツールです。ツールにアクセスするには、AEM のスタートアップスクリーンから ツール/運営/診断 を選択します。次に、「クエリパフォーマンス」をクリックして「クエリの説明を実行」タブに切り替えます。
機能
- Xpath、JCR-SQL および JCR-SQL2 クエリ言語をサポート
- 指定したクエリの実際の実行時間をレポート
- 時間のかかるクエリを検出し、潜在的に時間のかかる可能性のあるクエリに関する警告を表示
- クエリ実行に使用された Oak インデックスをレポート
- 実際の Oak クエリエンジンの説明を表示
- 時間のかかるクエリおよびよく使用されるクエリのリストをクリックで表示
クエリの説明を実行の UI に移動したら、クエリを入力して「説明」ボタンを押します。
「クエリの説明」セクションの最初のエントリが実際の説明です。この説明には、クエリの実行に使用されたインデックスのタイプが示されます。
2 つ目のエントリは実行計画です。
クエリを実行する前に「実行時間を含める」ボックスにチェックを入れると、このクエリが実行された時間も表示されます。「ノード数を含める」オプションを選択すると、ノード数が報告されます。報告からは、アプリケーションやデプロイメントでインデックスを最適化するために使用できる詳細情報が得られます。
インデックスマネージャー the-index-manager
インデックスマネージャーの目的は、インデックスのメンテナンスや、ステータスの表示などのインデックス管理を容易にすることです。
これには、AEM のようこそ画面から**ツール/操作/診断を選択し、「インデックスマネージャー」ボタンをクリックしてアクセスできます。
この URL から直接アクセスすることもできます。https://serveraddress:port/libs/granite/operations/content/diagnosistools/indexManager.html
この UI で、画面左上隅の検索ボックスにフィルター条件を入力して、テーブル内のインデックスにフィルターを適用できます。
ステータス ZIP をダウンロード download-status-zip
このアクションにより、システムのステータスおよび設定に関する有益な情報を含む zip のダウンロードが実行されます。アーカイブには、インスタンス設定、バンドルのリスト、OSGI、Sling の指標と統計が含まれるので、ファイルのサイズが大きくなります。サイズの大きいステータスファイルの影響を減らすには、ステータス ZIP をダウンロード ウィンドウを使用します。このウィンドウには、AEM/ツール/操作/診断/ステータス ZIP をダウンロード からアクセスできます。
このウィンドウでは、書き出すもの(ログファイルやスレッドダンプ)および現在の日付を基準にしてダウンロードに含めるログの日数を選択できます。
スレッドダンプをダウンロード download-thread-dump
このアクションにより、システム内に存在するスレッドに関する情報を含む zip ファイルをダウンロードが実行されます。ステータス、クラスローダー、スタックトレースなど、各スレッドに関する情報が提供されます。
ヒープダンプをダウンロード download-heap-dump
後から分析するために、ヒープのスナップショットをダウンロードすることもできます。このアクションにより、サイズの大きい(数百メガバイト)ファイルのダウンロードが実行されます。
自動メンテナンスタスク automated-maintenance-tasks
自動メンテナンスタスクページでは、定期的な実行がスケジュールされている、推奨されるメンテナンスタスクを表示およびトラックできます。タスクはヘルスチェックシステムに統合されています。タスクはインターフェイスから手動で実行することもできます。
運営ダッシュボードのメンテナンスページを開くには、AEM のようこそ画面から ツール/運営/ダッシュボード/メンテナンス を選択するか、次のリンクに直接アクセスします。
https://serveraddress:port/libs/granite/operations/content/maintenance.html
操作ダッシュボードでは、次のタスクを使用できます。
- 日別メンテナンスウィンドウ メニューの下の リビジョンのクリーンアップ タスク。
- 日別メンテナンスウィンドウ メニューの下の Lucene バイナリクリーンアップ タスク。
- 週別メンテナンスウィンドウ メニューの下の ワークフローのパージ タスク。
- 週別メンテナンスウィンドウ メニューの下の データストアのガベージコレクション タスク。
- 週別メンテナンスウィンドウ メニューの下の 監査ログのメンテナンス タスク。
- 週別メンテナンスウィンドウ メニューの下の バージョンのパージのメンテナンス タスク。
- 週別メンテナンスウィンドウ メニューの下の プロジェクトのパージ のメンテナンスタスク。「追加」オプションを使用します。
- 週別メンテナンスウィンドウ メニューの下の アドホックタスクのパージ のメンテナンスタスク。「追加」オプションを使用します。
日別メンテナンスウィンドウのデフォルトのタイミングは、午前 2:00~午前 5:00 です。週別メンテナンスウィンドウで実行するように設定されたタスクは、毎週土曜日の午前 1:00~午前 2:00 に実行されます。
また、2 つのメンテナンスカードのいずれかの歯車アイコンをクリックして、タイミングを設定することもできます。
リビジョンのクリーンアップ revision-clean-up
詳しくは、リビジョンのクリーンアップを参照してください。
Lucene バイナリクリーンアップ lucene-binaries-cleanup
Lucene バイナリのクリーンアップタスクを使用すると、Lucene バイナリをパージして、実行中のデータストアのサイズ要件を低減することができます。Lucene バイナリのチャーンは、これまでデータストアのガベージコレクションの実行の成功に依存していましたが、毎日再要求されるようになりました。
メンテナンスタスクは、Lucene 関連のリビジョンガベージの低減を目的として開発されましたが、このタスクを実行すると、次のように一般的な効率も向上します。
- データストアのガベージコレクションタスクを毎週実行すると、より迅速に完了できます。
- AEM の全体的なパフォーマンスがわずかに向上することもあります。
Lucene バイナリクリーンアップタスクには、AEM/ツール/操作/メンテナンス/日別メンテナンスウィンドウ/Lucene バイナリクリーンアップ からアクセスできます。
データストアのガベージコレクション data-store-garbage-collection
データストアのガベージコレクションについて詳しくは、専用のデータストアのガベージコレクションドキュメントページを参照してください。
ワークフローのパージ workflow-purge
ワークフローは、メンテナンスダッシュボードからパージすることもできます。ワークフローのパージタスクを実行するには、次の手順を実行します。
- 週別メンテナンスウィンドウ ページをクリックします。
- 次のページで、ワークフローのパージ カードの 再生 をクリックします。
監査ログのメンテナンス audit-log-maintenance
監査ログのメンテナンスについては、別のドキュメントページを参照してください。
バージョンのパージ version-purge
バージョンのパージメンテナンスタスクをスケジュールして、古いバージョンを自動的に削除できます。このアクションにより、バージョンのパージツールを手動で操作する必要性を最小限に抑えることができます。バージョンのパージタスクをスケジュールおよび設定するには、ツール/運営/メンテナンス/週別メンテナンスウィンドウ にアクセスして、次の手順を実行します。
-
「追加」をクリックします。
-
ドロップダウンメニューから「バージョンのパージ」を選択します。
-
バージョンのパージタスクを設定するには、新しく作成されたバージョンのパージメンテナンスカードの 歯車 アイコンをクリックします。
AEM 6.4 では、次の手順でバージョンのパージメンテナンスタスクを停止できます。
- 自動 - タスクの完了前にスケジュール済みのメンテナンスウィンドウを閉じると、タスクが自動的に停止します。次回のメンテナンスウィンドウを開くと、タスクは再開されます。
- 手動 - タスクを手動で停止するには、バージョンのパージメンテナンスカードで「停止」アイコンをクリックします。次回の実行時に、タスクは安全に再開されます。
プロジェクトのパージ project-purge
アドビプロジェクトのパージ設定(com.adobe.cq.projects.purge.Scheduler)の下の OSGI プロパティを設定します。
アドホックタスクのパージ purge-of-ad-hoc-tasks
アドホックタスクのパージ(com.adobe.granite.taskmanagement.impl.purge.TaskPurgeMaintenanceTask
)の下の OSGI プロパティを設定します。
カスタムメンテナンスタスク custom-maintenance-tasks
カスタムメンテナンスタスクは 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 プロパティを該当するノードで設定し、このメンテナンスタスク用にアクティブにする必要のある実行モードの値を指定する必要があります。
システム概要 system-overview
システム概要ダッシュボード に、AEM インスタンスの設定、ハードウェアおよびヘルスの概要が表示されます。システムヘルスのステータスが明白になり、すべての情報が 1 つのダッシュボードに集約されます。
アクセス方法 how-to-access
システム概要ダッシュボードにアクセスするには、ツール/操作/システム概要 に移動します。
システム概要ダッシュボードの説明 system-overview-dashboard-explained
次の表では、システム概要ダッシュボードに表示されるすべての情報について説明します。表示する関連情報がない場合(バックアップが進行中ではない、重要なヘルスチェックはないなど)は、それぞれのセクションに「エントリがありません」というメッセージが表示されます。
また、ダッシュボードの右上隅の「ダウンロード」ボタンをクリックして、ダッシュボード情報を要約した JSON
ファイルをダウンロードすることもできます。JSON
のエンドポイントは /libs/granite/operations/content/systemoverview/export.json
です。これを curl
スクリプトで使用して、外部監視を行うことができます。