操作ダッシュボード

概要

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

chlimage_1-116

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

chlimage_1-117

ヘルスチェックの種類

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 Configuration Managerに移動します。これは、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 というフィルタータグを持つ複合ヘルスチェックは、タグプロパティ（）に test タグと checkhc.tags タグのいずれかが含まれているすべての個別および複合ヘルスチェックを集約します。
    メモ

    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 で提供されているヘルスチェック

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

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

このヘルスチェックのMBeanはorg.apache.sling.healthcheck:name=querysStatus,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 Jobsは、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です。
ディスク容量

Disk Spaceチェックでは、FileStoreStats MBeanを調べ、Node StoreのサイズとNode Storeパーティションの使用可能なディスク領域の量を取得し、次の操作を行います。

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

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

このヘルスチェックのMBeanはorg.apache.sling.healthcheck:name=DiskSpaceHealthCheck,type=HealthCheckです。
スケジューラーヘルスチェック

このチェックは、インスタンスが 60 秒を超えて実行している Quartz ジョブを持つ場合、警告を返します。許容される期間のしきい値は、設定可能です。

このヘルスチェックのMBeanはorg.apache.sling.healthcheck:name=slingCommonsSchedulerHealthCheck,type=HealthCheckです。
セキュリティチェック

セキュリティチェックは、複数のセキュリティ関連チェックを集計する複合チェックです。これらの個々の正常性チェックは、セキュリティチェックリストのドキュメントページにあるセキュリティチェックリストとは異なる懸念事項に対処します。 このチェックは、インスタンスの起動時のセキュリティ煙テストとして役立ちます。

このヘルスチェックのMBeanはorg.apache.sling.healthcheck:name=securitychecks,type=HealthCheckです。
アクティブなバンドル

アクティブなバンドルは、すべてのバンドルの状態をチェックします。

  • いずれかのバンドルがアクティブでないか（レイジーアクティベーションで始まる）場合、警告ステータスを返します
  • 無視リストのバンドルの状態を無視します

無視リストパラメーターは設定可能です。

このヘルスチェックのMBeanはorg.apache.sling.healthcheck:name=inactiveBundles,type=HealthCheckです。
コードキャッシュのチェック

これは、Java 7 に存在する CodeCache バグをトリガーできるいくつかの JVM 条件を検証するヘルスチェックです。

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

minimum.code.cache.sizeしきい値は設定可能です。 バグの詳細については、checkこのページを参照してください。

このヘルスチェックの 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 です。

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. 「監視」セクションの下の「ホスト」リンクを押します。
    5. ホスト定義を追加します。

    chlimage_1-118

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

    chlimage_1-119

診断ツール

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

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

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

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

chlimage_1-120

ログメッセージ

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

ログメッセージはメモリ内ログアペンダーを使用するので、ログファイルとは関係しません。もう1つの結果として、このUIでログレベルを変更しても、従来のログファイルに記録される情報は変更されません。このUIでロガーを追加および削除すると、メモリ内ロガーにのみ影響します。また、ロガー設定の変更はメモリ内ロガーの将来に反映されます。既にログに記録され、関連しなくなったエントリは削除されませんが、今後同様のエントリはログに記録されません。

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

例：

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

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

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

chlimage_1-121

メモ

指定したフィルター経由でエラーメッセージのみを取り込むロガー名は設定できません。デフォルトで、すべてのエラーメッセージが取り込まれます。

メモ

ログメッセージユーザーインターフェイスには、実際のエラーログは反映されません。UI で他のタイプのログメッセージを設定しない限り、エラーメッセージのみが表示されます。特定のログメッセージを表示する方法については、上記の説明を参照してください。

メモ

診断ページの設定はログファイルへの記録内容には影響せず、その逆も同様です。したがって、エラーログで情報メッセージが見つかったとしても、ログメッセージの UI には表示されない場合があります。また、エラーログに影響を与えずに、特定のパッケージからのデバッグメッセージを UI を通して見つけることもできます。ログファイルの設定方法について詳しくは、ログを参照してください。

メモ

AEM 6.4​では、メンテナンスタスクはINFOレベルでより詳細な情報を豊富な形式で初期状態でログアウトされます。これにより、メンテナンスタスクの状態がよりわかりやすくなっています。

メンテナンスタスクのアクティビティを監視し、対処するためにサードパーティツール（Splunk など）を使用している場合、次のログステートメントを使用できます。

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"拡張子を持つ要求

chlimage_1-122

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

  • 要求がおこなわれた時刻
  • URL と要求のメソッド
  • 所要時間（ミリ秒単位）

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

クエリパフォーマンス

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

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

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

chlimage_1-123

クエリの説明を実行

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

クエリの説明を実行は、Oak によるクエリの実行方法を説明するツールです。これには、AEM のようこそ画面から​ツール／操作／診断​を選択し、「クエリパフォーマンス」をクリックして「クエリの説明を実行」タブに切り替えることでアクセスできます。

特長

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

クエリの説明を実行の UI では、クエリを入力して「説明」ボタンを押すだけで使用できます。

chlimage_1-124

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

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

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

chlimage_1-125

インデックスマネージャ

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

スタートアップスクリーンから​ツール→操作→診断→​に移動し、インデックスマネージャ​ボタンをクリックするとアクセスできます。

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

screen-shot_2019-06-18at154754

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

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

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

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

download_status_zip

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

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

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

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

自動メンテナンスタスク

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

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

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

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

  1. 日別メンテナンスウィンドウ​メニューの下の​リビジョンのクリーンアップ​タスク。
  2. Lucene Binarys Cleanup​タスクは、日別メンテナンスウィンドウ​メニューの下にあります。
  3. 週別メンテナンスウィンドウ​メニューの下の​ワークフローのパージ​タスク。
  4. Data Store Garbage Collection​タスクは、週別メンテナンスウィンドウ​メニューの下にあります。
  5. 監査ログのメンテナンス​タスクは、週別メンテナンスウィンドウ​メニューの下にあります。
  6. Version Purge Maintenance​タスク。週別メンテナンスウィンドウ​メニューの下にあります。

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

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

chlimage_1-126

メモ

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

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

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

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

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

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

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

Lucene Binarys Cleanupタスクには、次の場所からアクセスできます。AEM > Tools > Operations > Maintenance > Daily Maintenance Window > Lucene Binarys Cleanup。

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

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

ワークフローのパージ

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

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

ワークフローメンテナンスの詳細については、このページを参照してください。

監査ログのメンテナンス

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

バージョンのパージ

バージョンのパージメンテナンスタスクをスケジュールして、古いバージョンを自動的に削除できます。その結果、バージョン削除ツールを手動で使用する必要が最小限に抑えられます。ツール/操作/メンテナンス/週別メンテナンスウィンドウ​にアクセスし、次の手順に従って、バージョンの削除タスクをスケジュールおよび設定できます。

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

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

    version_purge_maintenancetask

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

    version_purge_taskconfiguration

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

サービスプロパティ名
 説明 例
 型
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に表示されます。 このファイルは、次のいずれかの使用可能なメンテナンススケジュールに追加できます。

chlimage_1-127

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

システム概要

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

メモ

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

アクセス方法

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

system_overview_ダッシュボード

システム概要ダッシュボードの説明

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

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

セクション 表示される情報 これが重要になる状況 リンク先
ヘルスチェック
  • 重要ステータスのチェックのリスト
  • 警告ステータスのチェックのリスト
 色の意味：
  • 赤色のタグは重要なチェック
  • オレンジ色のタグは警告のチェック
  • ヘルスレポートページ
メンテナンスタスク
  • 失敗したタスクのリスト
  • 現在実行中のタスクのリスト
  • 前回の実行で成功したタスクのリスト
  • 実行しなかったタスクのリスト
  • スケジュールが未設定のタスクのリスト

色の意味：

  • 赤色のタグは失敗したタスク
  • オレンジ色のタグは実行中のタスク（これらはパフォーマンスに影響する可能性があります）
  • 灰色のタグはその他のすべてのステータス
  • メンテナンスタスクページ
システム
  • オペレーティングシステム（OS）および OS バージョン（Mac OS X など）
  • システム負荷平均（OperatingSystemMXBeanusable から取得されます）
  • ディスク領域（ホームディレクトリがあるパーティション）
  • MemoryMXBeanから返される最大ヒープ
 該当なし 該当なし
インスタンス
  • AEM のバージョン
  • 実行モードのリスト
  • インスタンスが開始された日付
 該当なし 該当なし
リポジトリ
  • Oak のバージョン
  • ノードストアのタイプ（セグメント Tar またはドキュメント）
    • タイプがドキュメントの場合は、ドキュメントストアのタイプが表示されます（RDB または Mongo）。
  • カスタムデータストアがある場合：
    • ファイルデータストアの場合は、パスが表示されます。
    • S3 データストアの場合は、S3 バケットの名前が表示されます。
    • 共有 S3 データストアの場合は、S3 バケットの名前が表示されます。
    • Azure データストアの場合は、コンテナが表示されます。
  • カスタムの外部データストアがない場合は、このことを示すメッセージが表示されます。
 該当なし 該当なし
配布エージェント
  • キューがブロックされているエージェントのリスト
  • 設定が正しくないエージェントのリスト（「設定エラー」）
  • キューの処理が一時停止されているエージェントのリスト
  • 待機中エージェントのリスト
  • 実行中エージェントのリスト（現在エントリを処理中）

色の意味：

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

色の意味：

  • 赤色のタグはブロックされているエージェント
  • 灰色のタグは一時停止中のエージェント
 レプリケーションページ
ワークフロー
  • ワークフロージョブ：
    • 失敗したワークフロージョブの数（ある場合）
    • 取り消されたワークフロージョブの数（存在する場合）
  • ワークフロー数 — 特定のステータスのワークフロー数（存在する場合）:
    • 実行中
    • 失敗
    • 保留中
    • 中止

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

判断なし：

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

Sling ジョブ数 - 特定のステータスのジョブの数（ある場合）：

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

判断なし：

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

予測数：

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

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

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

ディスプレイ:

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

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

 該当なし 該当なし

このページ