操作ダッシュボード operations-dashboard

はじめに introduction

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

操作ダッシュボードの特徴は次のとおりです。

  • ワンクリックのシステムステータスで、運営部門の効率向上に役立ちます。
  • システムヘルスの概要を、1 つの場所で一元的に提供します。
  • 問題の発見、分析および修正にかかる時間を短縮します。
  • 自己完結型のメンテナンス自動化により、プロジェクトの運営コストを大幅に削減します。

AEM のようこそ画面から​ ツール操作 ​に移動してアクセスできます。

NOTE
操作ダッシュボードにアクセスするには、「オペレーター」ユーザーグループの一員としてログインする必要があります。詳しくは、ユーザー、グループおよびアクセス権限の管理に関するドキュメントを参照してください。

ヘルスレポート 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

chlimage_1-116

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

chlimage_1-117

ヘルスチェックの種類 health-check-types

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

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

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

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

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

ヘルスチェックを作成する方法 how-to-create-health-checks

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

個別ヘルスチェックの作成 creating-an-individual-health-check

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

  1. 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 の名前を定義します。
  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
    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 設定を追加します。操作ダッシュボードに表示させるために、シンプルなチェックと同じように、新しい設定ノードを追加する必要があります。

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

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

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

    chlimage_1-23

  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 タグのいずれかが含まれている個別および複合のすべてのヘルスチェックを集約します。
    note note
    NOTE
    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
    note note
    NOTE
    デフォルトでダッシュボードに既に存在する複合チェックの下に論理的に属する個々のヘルスチェックを作成した場合、自動的にキャプチャされ、それぞれの複合チェックの下にグループ化されます。したがって、これらのチェック用に設定ノードを作成する必要はありません。
    例えば、個々のセキュリティヘルスチェックを作成し、「セキュリティ」タグを割り当てると、インストールされます。操作ダッシュボードのセキュリティチェック複合チェックの下に自動的に表示されます。

AEM で提供されているヘルスチェック health-checks-provided-with-aem

ヘルスチェック名
説明
クエリパフォーマンス

このヘルスチェックは AEM 6.4 で簡素化され、最近リファクタリングされた Oak QueryStats MBean(具体的には SlowQueries 属性)をチェックするようになりました。処理に時間のかかるクエリが統計に含まれている場合、ヘルスチェックは警告を返します。それ以外の場合は、OK ステータスを返します。

このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=queriesStatus,type=HealthCheck です。

監視キューの長さ

監視キューの長さは、すべてのイベントリスナーとバックグラウンドオブザーバーを繰り返し処理し、それらの queueSize maxQueueSize と比較します。

  • queueSize 値が maxQueueSize 値を超えた場合(つまり、イベントがドロップされた場合)、重要ステータスを返します。
  • queueSize 値が maxQueueSize * WARN_THRESHOLD を超えた場合は、警告を返します(デフォルト値は 0.75)。

各キューの最大長は個別の設定(Oak と AEM)から取得され、このヘルスチェックからは設定できません。このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=ObservationQueueLengthHealthCheck,type=HealthCheck です。

クエリトラバーサルの制限

クエリトラバーサルの制限は、QueryEngineSettings MBean(具体的には LimitInMemory 属性と LimitReads 属性)をチェックし、次のステータスを返します。

  • いずれかの制限が 以上の場合、警告ステータスを返します。 Integer.MAX_VALUE
  • いずれかの制限が 10,000(Oak の推奨設定)より低い場合、警告ステータスを返します。
  • QueryEngineSettings またはいずれかの制限を取得できない場合、重要ステータスを返します。

このヘルスチェックの Mbean は、org.apache.sling.healthcheck:name=queryTraversalLimitsBundle,type=HealthCheck です。

同期済みのクロック

このチェックは、ドキュメントノードストアクラスターにのみ関連しています。次のステータスを返します。

  • インスタンスクロックが同期しなくなり、事前定義された低しきい値を超えた場合、警告ステータスを返します
  • インスタンスクロックが同期しなくなり、事前定義された高しきい値を超えた場合、重要ステータスを返します

このヘルスチェックの Mbean は、org.apache.sling.healthcheck:name=slingDiscoveryOakSynchronizedClocks,type=HealthCheck です。

非同期インデックス

非同期インデックスのチェック:

  • 1 つ以上のインデックス作成レーンが失敗した場合に、重大ステータスを返します

  • すべてのインデックス作成レーンについて lastIndexedTime をチェックし、次のことを行います。

    • 2 時間以上前である場合は、重大ステータスを返します
    • 2 時間~45 分前の場合は、警告ステータスを返します
    • 45 分前以内の場合は、OK ステータスを返します
  • いずれの条件も満たさない場合は、OK ステータスを返します

重要ステータスと警告ステータスの両方のしきい値を設定できます。このヘルスチェックの Mbean は、org.apache.sling.healthcheck:name=asyncIndexHealthCheck,type=HealthCheck です。

注意: このヘルスチェックは、AEM 6.4 で使用でき、AEM 6.3.0.1 に移植されています。

大きい Lucene インデックス

このチェックは、Lucene Index Statistics MBean によって公開されたデータを使用して大きいインデックスを識別し、次のステータスを返します。

  • 10 億を超えるドキュメントを含むインデックスがある場合は、警告ステータス
  • 15 億を超えるドキュメントを含むインデックスがある場合は、重要ステータス

しきい値は設定可能で、このヘルスチェックの MBean は org.apache.sling.healthcheck:name=largeIndexHealthCheck,type=HealthCheck です。

メモ: このヘルスチェックは AEM 6.4 で使用でき、AEM 6.3.2.0 に移植されています。

システムメンテナンス

システムメンテナンスは複合チェックで、すべてのメンテナンスタスクが設定した通りに実行されている場合は OK を返します。次の点に注意してください。

  • 各メンテナンスタスクは、関連するヘルスチェックを伴います。
  • タスクがメンテナンスウィンドウに追加されていない場合、そのヘルスチェックは重要ステータスを返します
  • 監査ログおよびワークフローのパージのメンテナンスタスクを設定するか、メンテナンスウィンドウから削除します。未設定のままにすると、これらのタスクは最初の実行で失敗し、システムメンテナンスチェックで重要ステータスが返されます。
  • AEM 6.4 では、Lucene バイナリのメンテナンスタスクのチェックもあります
  • AEM 6.2 以前では、タスクが実行されないため、システムメンテナンスチェックは起動直後に警告ステータスを返します。6.3 以降では、最初のメンテナンスウィンドウに到達していない場合は OK を返します。

このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=systemchecks,type=HealthCheck です。

レプリケーションキュー

このチェックは、レプリケーションエージェントに対して繰り返し行われ、そのキューを確認します。キューの上位にある項目については、エージェントによるレプリケーションの試行回数が確認されます。エージェントが numberOfRetriesAllowed パラメーターの値より多くレプリケーションを試行した場合、警告を返します。numberOfRetriesAllowed パラメーターは設定可能です。

このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=replicationQueue,type=HealthCheck です。

Sling ジョブ

Sling ジョブは、JobManager でのキューに登録されたジョブ数をチェックし、maxNumQueueJobs しきい値と比較します。

  • キューに maxNumQueueJobs より多くある場合、重大ステータスを返します
  • 1 時間を超えて長時間実行されているアクティブなジョブがある場合は、重大ステータスを返します
  • キューに登録されたジョブがあり、最後に完了したジョブの時間が 1 時間を超えている場合は、重大ステータスを返します

設定できるのは、キューに登録されたジョブのパラメーターの最大数のみで、デフォルト値は 1000 です。

このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=slingJobs,type=HealthCheck です。

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

このチェックは、granite.request.metrics.timer Sling 指標を確認します。

  • 75 パーセンタイルの値が重大ステータスのしきい値(デフォルト値は 500 ミリ秒)を超えている場合は、重大ステータスを返します
  • 75 パーセンタイルの値が警告ステータスのしきい値(デフォルト値は 200 ミリ秒)を超えている場合は、警告ステータスを返します

このヘルスチェックの MBean は、 org.apache.sling.healthcheck:name=requestsStatus,type=HealthCheck です。

ログエラー

このチェックでは、ログにエラーがある場合に警告ステータスを返します。

このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=logErrorHealthCheck,type=HealthCheck です。

ディスク容量

ディスク容量チェックは、FileStoreStats MBean を確認し、ノードストアのサイズおよびノードストアパーティション上の使用可能なディスク容量を取得します。

  • リポジトリサイズに対する使用可能なディスク容量の割合が警告ステータスのしきい値(デフォルト値は 10)未満の場合は、警告ステータスを返します
  • リポジトリサイズに対する使用可能なディスク容量の割合が重大ステータスのしきい値(デフォルト値は 2)未満の場合は、重大ステータスを返します

どちらのしきい値も設定可能です。このチェックは、セグメントストアを含むインスタンスに対してのみ機能します。

このヘルスチェックの 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 条件を検証するヘルスチェックです。

  • コードキャッシュのフラッシュが有効な Java™ 7 でインスタンスが実行されている場合は、警告ステータスを返します
  • Java™ 7 でインスタンスが実行されていて、予約済みコードキャッシュのサイズが最小しきい値(デフォルト値は 90 MB)よりも小さい場合は、警告ステータスを返します

minimum.code.cache.size しきい値は設定可能です。このバグについて詳しくは、こちらのページで Bug ID 8012547 を検索してください

このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=codeCacheHealthCheck,type=HealthCheck です。

リソース検索パスエラー

パス /apps/foundation/components/primary にリソースがあるかどうかをチェックします。

  • 次の下に子ノードがある場合は、警告ステータスを返します /apps/foundation/components/primary

このヘルスチェックの MBean は、org.apache.sling.healthcheck:name=resourceSearchPathErrorHealthCheck,type=HealthCheck です。

ヘルスチェック設定 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

chlimage_1-120

ログメッセージ log-messages

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

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

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

例:

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

  • エラー警告情報 ​のすべてのメッセージを取り込む計画をしている場合は、ロガー名を「root」に、ロガーレベルを​ 情報 ​に設定します。

  • 特定のパッケージ(com.adobe.granite など)からのすべてのメッセージを取り込む計画をしている場合は、ロガー名を「com.adobe.granite」に設定します。また、ロガーレベルを​ デバッグ ​に設定します(これにより、エラー警告情報デバッグ ​のすべてのメッセージが取り込まれます)。以下の図を参照してください。

chlimage_1-121

NOTE
指定したフィルター経由でエラーメッセージのみを取り込むロガー名は設定できません。デフォルトで、すべてのエラーメッセージが取り込まれます。
NOTE
ログメッセージユーザーインターフェイスには、実際のエラーログは反映されません。UI で他のタイプのログメッセージを設定しない限り、エラーメッセージのみが表示されます。特定のログメッセージを表示する方法については、上記の説明を参照してください。
NOTE
診断ページの設定はログファイルへの記録内容には影響せず、その逆も同様です。したがって、エラーログで情報メッセージが見つかったとしても、ログメッセージの UI には表示されない場合があります。また、エラーログに影響を与えずに、特定のパッケージからのデバッグメッセージを UI を通して見つけることもできます。ログファイルの設定方法について詳しくは、ログを参照してください。
NOTE
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>

リクエストパフォーマンス request-performance

リクエストパフォーマンスページでは、処理時間が最も長いページリクエストを分析できます。このページではコンテンツリクエストのみが登録されます。具体的には、以下のリクエストが取り込まれます。

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

chlimage_1-122

このページには以下の項目が表示されます。

  • リクエストが行われた時刻
  • URL とリクエストのメソッド
  • 所要時間(ミリ秒単位)

デフォルトでは、所要時間が長いほうから 20 個のページリクエストが取り込まれますが、この制限は設定マネージャーで変更できます。

クエリーパフォーマンス query-performance

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

このページには以下の項目が表示されます。

  • クエリが行われた時刻
  • クエリの言語
  • クエリの発行回数
  • クエリのステートメント
  • 所要時間(ミリ秒単位)

chlimage_1-123

クエリの説明を実行 explain-query

どのようなクエリでも、Oak は、リポジトリ内の oak:index ノードの下で定義されている Oak インデックスに基づいて最適な実行方法の計算を試みます。クエリごとに異なるインデックスが Oak によって選択されます。Oak によるクエリの実行方法を把握することが、クエリを最適化するための第一歩です。

クエリの説明を実行は、Oak によるクエリの実行方法を説明するツールです。ツールにアクセスするには、AEM のスタートアップスクリーンから​ ツール/運営/診断 ​を選択します。次に、「クエリパフォーマンス」をクリックして「クエリの説明を実行」タブに切り替えます。

機能

  • Xpath、JCR-SQL および JCR-SQL2 クエリ言語をサポート
  • 指定したクエリの実際の実行時間をレポート
  • 時間のかかるクエリを検出し、潜在的に時間のかかる可能性のあるクエリに関する警告を表示
  • クエリ実行に使用された Oak インデックスをレポート
  • 実際の Oak クエリエンジンの説明を表示
  • 時間のかかるクエリおよびよく使用されるクエリのリストをクリックで表示

クエリの説明を実行の UI に移動したら、クエリを入力して「説明」ボタンを押します。

chlimage_1-124

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

2 つ目のエントリは実行計画です。

クエリを実行する前に「実行時間を含める」ボックスにチェックを入れると、このクエリが実行された時間も表示されます。「ノード数を含める」オプションを選択すると、ノード数が報告されます。報告からは、アプリケーションやデプロイメントでインデックスを最適化するために使用できる詳細情報が得られます。

chlimage_1-125

インデックスマネージャー 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_status_zip

スレッドダンプをダウンロード download-thread-dump

このアクションにより、システム内に存在するスレッドに関する情報を含む zip ファイルをダウンロードが実行されます。ステータス、クラスローダー、スタックトレースなど、各スレッドに関する情報が提供されます。

ヒープダンプをダウンロード download-heap-dump

後から分析するために、ヒープのスナップショットをダウンロードすることもできます。このアクションにより、サイズの大きい(数百メガバイト)ファイルのダウンロードが実行されます。

自動メンテナンスタスク automated-maintenance-tasks

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

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

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

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

  1. 日別メンテナンスウィンドウ ​メニューの下の​ リビジョンのクリーンアップ ​タスク。
  2. 日別メンテナンスウィンドウ ​メニューの下の Lucene バイナリクリーンアップ ​タスク。
  3. 週別メンテナンスウィンドウ ​メニューの下の​ ワークフローのパージ ​タスク。
  4. 週別メンテナンスウィンドウ ​メニューの下の​ データストアのガベージコレクション ​タスク。
  5. 週別メンテナンスウィンドウ ​メニューの下の​ 監査ログのメンテナンス ​タスク。
  6. 週別メンテナンスウィンドウ ​メニューの下の​ バージョンのパージのメンテナンス ​タスク。
  7. 週別メンテナンスウィンドウ ​メニューの下の​ プロジェクトのパージ ​のメンテナンスタスク。「追加」オプションを使用します。
  8. 週別メンテナンスウィンドウ ​メニューの下の​ アドホックタスクのパージ ​のメンテナンスタスク。「追加」オプションを使用します。

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

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

chlimage_1-126

NOTE
AEM 6.1 以降では、既存のメンテナンスウィンドウを毎月実行するように設定することもできます。

リビジョンのクリーンアップ revision-clean-up

詳しくは、リビジョンのクリーンアップを参照してください。

Lucene バイナリクリーンアップ lucene-binaries-cleanup

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

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

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

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

データストアのガベージコレクション data-store-garbage-collection

データストアのガベージコレクションについて詳しくは、専用のデータストアのガベージコレクションドキュメントページを参照してください。

ワークフローのパージ workflow-purge

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

  1. 週別メンテナンスウィンドウ ​ページをクリックします。
  2. 次のページで、ワークフローのパージ ​カードの​ 再生 ​をクリックします。
NOTE
ワークフローメンテナンスについて詳しくは、ワークフローインスタンスの管理を参照してください。

監査ログのメンテナンス audit-log-maintenance

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

バージョンのパージ version-purge

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

  1. 追加」をクリックします。

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

    version_purge_maintenancetask

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

    version_purge_taskconfiguration

AEM 6.4 では、次の手順でバージョンのパージメンテナンスタスクを停止できます。

  • 自動 - タスクの完了前にスケジュール済みのメンテナンスウィンドウを閉じると、タスクが自動的に停止します。次回のメンテナンスウィンドウを開くと、タスクは再開されます。
  • 手動 - タスクを手動で停止するには、バージョンのパージメンテナンスカードで「停止」アイコンをクリックします。次回の実行時に、タスクは安全に再開されます。
NOTE
メンテナンスタスクを停止すると、既に処理中のジョブのトラックを維持しながら、実行を一時停止できます。
CAUTION
リポジトリサイズを最適化するには、バージョンのパージタスクを頻繁に実行する必要があります。トラフィック量が限られている場合は、このタスクを営業時間外にスケジュールする必要があります。

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

サービスプロパティ名
説明
タイプ
granite.maintenance.isStoppable
ユーザーがタスクを停止できるかどうかを定義するブーリアン属性。タスクを停止可能と宣言した場合は、実行中に停止されたかどうかをチェックし、それに応じて対処する必要があります。デフォルトは false です。
true
オプション
granite.maintenance.mandatory
タスクが必須であり、定期的に実行する必要があるかどうかを定義するブール値属性。タスクが必須であるものの、現時点でアクティブなスケジュールウィンドウに存在しない場合は、ヘルスチェックによってエラーとして報告されます。デフォルトは false です。
true
オプション
granite.maintenance.name
タスクの一意の名前。タスクを参照する際に使用します。単純な名前にします。
MyMaintenanceTask
必須
granite.maintenance.title
このタスクに表示されるタイトル。
My Special Maintenance Task
必須
job.topics
メンテナンスタスクの一意のトピック。
Apache Sling のジョブ処理では、このトピックからジョブを開始してメンテナンスタスクを実行し、このトピック用にタスクが登録されるとタスクが実行されます。
トピック名は com/adobe/granite/maintenance/job/ から始める必要があります。
com/adobe/granite/maintenance/job/MyMaintenanceTask
必須

上記のサービスプロパティとは別に、JobConsumer インターフェイスの process() メソッドに、メンテナンスタスクのために実行されるべきコードを追加して実装する必要があります。指定された JobExecutionContext を使用して、ステータス情報を出力したり、ジョブがユーザーによって停止されたかどうかを確認したり、結果(成功または失敗)を作成したりできます。

すべてのインストールでメンテナンスタスクを実行することが適切ではない状況の場合(パブリッシュインスタンスでのみ実行する場合など)は、@Component(policy=ConfigurationPolicy.REQUIRE) を追加することにより、サービスをアクティブにする設定を必要とするように指定できます。その後、該当する設定をリポジトリ内で実行モード依存としてマークできます。詳しくは、OSGi の設定を参照してください。

以下のカスタムメンテナンスタスクの例では、設定可能な一時ディレクトリから、過去 24 時間以内に変更されたファイルを削除します。

src/main/java/com/adobe/granite/samples/maintenance/impl/DeleteTempFilesTask.java

/*

* #%L

* sample-maintenance-task

* %%

* Copyright (C) 2014 Adobe

* %%

* Licensed under the Apache License, Version 2.0 (the "License");

* you may not use this file except in compliance with the License.

* You may obtain a copy of the License at

*

* https://www.apache.org/licenses/LICENSE-2.0

*

* Unless required by applicable law or agreed to in writing, software

* distributed under the License is distributed on an "AS IS" BASIS,

* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

* See the License for the specific language governing permissions and

* limitations under the License.

* #L%

*/

``

package com.adobe.granite.samples.maintenance.impl;

``

import java.io.File;

import java.util.Calendar;

import java.util.Collection;

import java.util.Map;

``

import org.apache.commons.io.FileUtils;

import org.apache.commons.io.filefilter.IOFileFilter;

import org.apache.commons.io.filefilter.TrueFileFilter;

import org.apache.felix.scr.annotations.Activate;

import org.apache.felix.scr.annotations.Component;

import org.apache.felix.scr.annotations.Properties;

import org.apache.felix.scr.annotations.Property;

import org.apache.felix.scr.annotations.Service;

import org.apache.sling.commons.osgi.PropertiesUtil;

import org.apache.sling.event.jobs.Job;

import org.apache.sling.event.jobs.consumer.JobConsumer;

import org.apache.sling.event.jobs.consumer.JobExecutionContext;

import org.apache.sling.event.jobs.consumer.JobExecutionResult;

import org.apache.sling.event.jobs.consumer.JobExecutor;

import org.slf4j.Logger;

import org.slf4j.LoggerFactory;

``

import com.adobe.granite.maintenance.MaintenanceConstants;

``

@Component(metatype = true,

label = "Delete Temp Files Maintenance Task",

description = "Maintatence Task which deletes files from a configurable temporary directory which have been modified in the last 24 hours.")

@Service

@Properties({

@Property(name = MaintenanceConstants.PROPERTY_TASK_NAME, value = "DeleteTempFilesTask", propertyPrivate = true),

@Property(name = MaintenanceConstants.PROPERTY_TASK_TITLE, value = "Delete Temp Files", propertyPrivate = true),

@Property(name = JobConsumer.PROPERTY_TOPICS, value = MaintenanceConstants.TASK_TOPIC_PREFIX

+ "DeleteTempFilesTask", propertyPrivate = true) })

public class DeleteTempFilesTask implements JobExecutor {

``

private static final Logger log = LoggerFactory.getLogger(DeleteTempFilesTask.class);

``

@Property(label = "Temporary Directory", description="Temporary Directory. Defaults to the java.io.tmpdir system property.")

private static final String PROP_TEMP_DIR = "temp.dir";

``

private File tempDir;

``

@Activate

private void activate(Map<string, object=""> properties) {

this.tempDir = new File(PropertiesUtil.toString(properties.get(PROP_TEMP_DIR),

System.getProperty("java.io.tmpdir")));

}

``

@Override

public JobExecutionResult process(Job job, JobExecutionContext context) {

log.info("Deleting old temp files from {}.", tempDir.getAbsolutePath());

Collection<file> files = FileUtils.listFiles(tempDir, new LastModifiedBeforeYesterdayFilter(),

TrueFileFilter.INSTANCE);

int counter = 0;

for (File file : files) {

log.debug("Deleting file {}.", file.getAbsolutePath());

counter++;

file.delete();

// TODO - capture the output of delete() and do something useful with it

}

return context.result().message(String.format("Deleted %s files.", counter)).succeeded();

}

``

/**

* IOFileFilter which filters out files which have been modified in the last 24 hours.

*

*/

private static class LastModifiedBeforeYesterdayFilter implements IOFileFilter {

``

private final long minTime;

``

private LastModifiedBeforeYesterdayFilter() {

Calendar cal = Calendar.getInstance();

cal.add(Calendar.DATE, -1);

this.minTime = cal.getTimeInMillis();

}

``

@Override

public boolean accept(File dir, String name) {

// this method is never actually called.

return false;

}

``

@Override

public boolean accept(File file) {

return file.lastModified() <= this.minTime;

}

}

``

}

<file></string,>

experiencemanager-java-maintenancetask-sample- src/main/java/com/adobe/granite/samples/maintenance/impl/DeleteTempFilesTask.java

サービスをデプロイすると、操作ダッシュボード UI に表示されます。利用可能なメンテナンススケジュールの 1 つに追加できます。

chlimage_1-127

このアクションにより、対応するリソースが /apps/granite/operations/config/maintenance/schedule/taskname に追加されます。タスクが実行モードに依存する場合は、granite.operations.conditions.runmode プロパティを該当するノードで設定し、このメンテナンスタスク用にアクティブにする必要のある実行モードの値を指定する必要があります。

システム概要 system-overview

システム概要ダッシュボード ​に、AEM インスタンスの設定、ハードウェアおよびヘルスの概要が表示されます。システムヘルスのステータスが明白になり、すべての情報が 1 つのダッシュボードに集約されます。

NOTE
システム概要ダッシュボードの概要については、このビデオを参照してください。

アクセス方法 how-to-access

システム概要ダッシュボードにアクセスするには、ツール/操作/システム概要 ​に移動します。

system_overview_dashboard

システム概要ダッシュボードの説明 system-overview-dashboard-explained

次の表では、システム概要ダッシュボードに表示されるすべての情報について説明します。表示する関連情報がない場合(バックアップが進行中ではない、重要なヘルスチェックはないなど)は、それぞれのセクションに「エントリがありません」というメッセージが表示されます。

また、ダッシュボードの右上隅の「ダウンロード」ボタンをクリックして、ダッシュボード情報を要約した JSON ファイルをダウンロードすることもできます。JSON のエンドポイントは /libs/granite/operations/content/systemoverview/export.json です。これを curl スクリプトで使用して、外部監視を行うことができます。

セクション
表示される情報
これが重要になる状況
リンク先
ヘルスチェック
  • 重要ステータスのチェックのリスト
  • 警告ステータスのチェックのリスト

色の意味:

  • 赤色のタグは重要なチェック
  • オレンジ色のタグは警告のチェック
  • ヘルスレポートページ
メンテナンスタスク
  • 失敗したタスクのリスト
  • 現在実行中のタスクのリスト
  • 前回の実行で成功したタスクのリスト
  • 実行しなかったタスクのリスト
  • スケジュールが未設定のタスクのリスト

色の意味:

  • 赤色のタグは失敗したタスク
  • オレンジ色のタグは実行中のタスク(これらはパフォーマンスに影響する可能性があります)
  • 灰色のタグはその他のすべてのステータス
  • メンテナンスタスクページ
システム
  • オペレーティングシステムおよび OS バージョン(Mac OS X など)
  • システム負荷平均(OperatingSystemMXBeanusable から取得されます)
  • ディスク領域(ホームディレクトリがあるパーティション)
  • 最大ヒープ(MemoryMXBean によって返されます)
該当なし
該当なし
インスタンス
  • AEM のバージョン
  • 実行モードのリスト
  • インスタンスが開始された日付
該当なし
該当なし
リポジトリ
  • Oak のバージョン

  • ノードストアのタイプ(セグメント Tar またはドキュメント)

    • タイプがドキュメントの場合は、ドキュメントストアのタイプが表示されます(RDB または Mongo)。
  • カスタムデータストアがある場合:

    • ファイルデータストアの場合は、パスが表示されます。
    • S3 データストアの場合は、S3 バケットの名前が表示されます。
    • 共有 S3 データストアの場合は、S3 バケットの名前が表示されます。
    • Azure データストアの場合は、コンテナが表示されます。
  • カスタムの外部データストアがない場合は、このことを示すメッセージが表示されます。

該当なし
該当なし
配布エージェント
  • キューがブロックされているエージェントのリスト
  • 設定が正しくないエージェントのリスト(「設定エラー」)
  • キューの処理が一時停止されているエージェントのリスト
  • 待機中エージェントのリスト
  • 実行中のエージェント(現在エントリを処理中)のリスト

色の意味:

  • 赤色のタグはブロックされているエージェントまたは設定エラー
  • オレンジ色のタグは一時停止中のエージェント
  • 灰色のタグは一時停止中、待機中または実行中のエージェント
配布版ページ
レプリケーションエージェント
  • キューがブロックされているエージェントのリスト
  • 待機中エージェントのリスト
  • 実行中のエージェント(現在エントリを処理中)のリスト

色の意味:

  • 赤色のタグはブロックされているエージェント
  • 灰色のタグは一時停止中のエージェント
レプリケーションページ
ワークフロー
  • ワークフロージョブ:

    • 失敗したワークフロージョブの数(ある場合)
    • キャンセルされたワークフロージョブの数(ある場合)
  • ワークフロー数 - 特定のステータスのワークフローの数(ある場合):

    • 実行中
    • 失敗
    • 保留中
    • 中止

前述のステータスごとにクエリが実行されます(400 ミリ秒以内)。400 ミリ秒の時点で、その時点までに取得されたエントリ数が表示されます。

判断なし:

  • 予期しないステータスのワークフローとジョブがある場合は、調査する必要があります。
ワークフローエラーページ
Sling ジョブ

Sling ジョブ数 - 特定のステータスのジョブの数(ある場合):

  • 失敗
  • 待機中
  • キャンセル済み
  • アクティブ

判断なし:

  • 予期しないステータスまたは数が大きいジョブがある場合は、調査する必要があります。
該当なし
予測ノード数

予測数:

  • ページ
  • アセット
  • タグ
  • 許可可能
  • ノードの合計数

ノードの合計数は nodeCounterMBean から取得しますが、残りの統計は IndexInfoService から取得します。

該当なし
該当なし
バックアップ
この場合は、「オンラインバックアップを処理中」と表示されます。
該当なし
該当なし
インデックス作成

表示:

  • 「インデックスを処理中」
  • 「クエリを処理中」

インデックスまたはクエリスレッドがスレッドダンプに存在する場合。

該当なし
該当なし
recommendation-more-help
19ffd973-7af2-44d0-84b5-d547b0dffee2