操作ダッシュボード

はじめに

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

chlimage_1-116

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

chlimage_1-117

ヘルスチェックのタイプ

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. 設定の右側にある「+」ボタンを押して、設定を作成します。 次に示すように、新しいウィンドウが表示されます。

    chlimage_1-23

  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.namediskusage​設定ノードは次のようになります。

    • 名前: 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 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 です。

同期済みのクロック

このチェックは、 document nodestore クラスター. 次のステータスを返します。

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

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

非同期インデックス

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

  • 少なくとも 1 つのインデックス作成レーンが失敗した場合に、重要ステータスを返します。
  • すべてのインデックス作成レーンについて lastIndexedTime をチェックし、次のことを行います。
    • 2 時間以上前である場合は、重要ステータスを返します。
    • 2 時間~ 45 分前の場合は、警告ステータスを返します。
    • 45 分前以内の場合は、OK ステータスを返します。
  • これらの条件がいずれも満たされない場合は、OK ステータスを返します。

Critical ステータスと Warn ステータスの両方のしきい値を設定できます。 このヘルスチェックの 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 時間より古い場合は、重要を返します

設定できるのは、queued jobs パラメーターの最大数のみで、デフォルト値は 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 しきい値は設定可能です。バグについて詳しくは、 その後、バグ 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.

ヘルスチェック設定

デフォルトでは、標準の 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. ホスト定義を追加します。

    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

診断ツール

また、Operation Dashboard では、Health Check Dashboard からの警告の根本原因の特定とトラブルシューティングに役立つ診断ツールにアクセスし、システムオペレーターに重要なデバッグ情報を提供できます。

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

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

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

chlimage_1-120

ログメッセージ

ログメッセージユーザーインターフェイスには、デフォルトですべての ERROR メッセージが表示されます。 さらにログメッセージを表示する場合は、適切なログレベルでロガーを設定します。

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

UI の左上の歯車ボタンからロガー設定を指定することで、ログに記録する内容を設定できます。 ここで、ロガー設定を追加、削除または更新できます。 ロガー設定は、 ログレベル (WARN / INFO / DEBUG) と フィルター名. この フィルター名 には、ログに記録されるログメッセージのソースをフィルタリングする役割があります。 または、ロガーが指定されたレベルのすべてのログメッセージを取り込む場合、フィルター名は「root". ロガーのレベルを設定すると、指定したレベル以上のすべてのトリガーがキャプチャされます。

例:

  • すべての エラー messages — 設定は不要です。 デフォルトでは、すべての ERROR メッセージが取り込まれます。

  • すべての エラー, 警告 および 情報 messages — ロガー名は次のように設定する必要があります。"root」、およびロガーレベルは次の場所に設定します。 情報.

  • 特定のパッケージ(com.adobe.granite など)からのすべてのメッセージをキャプチャする予定がある場合は、ロガー名を次のように設定する必要があります。"com.adobe.granite"と入力します。 また、ロガーレベルは次のように設定されます。 デバッグ ( これにより、 エラー, 警告, 情報、および デバッグ メッセージ ) に含まれます。

chlimage_1-121

メモ

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

メモ

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

メモ

診断ページの設定は、ログファイルの記録内容に影響しません。逆に、ログファイルの記録内容にも影響しません。 したがって、エラーログが INFO メッセージを取得する場合がありますが、ログメッセージ UI に表示されないことがあります。 また、UI を使用すると、エラーログに影響を与えることなく、特定のパッケージから DEBUG メッセージを取得できます。 ログファイルの設定方法について詳しくは、 ログ.

メモ

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>

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

リクエストのパフォーマンスページを使用すると、処理されるページリクエストの処理速度が最も遅いものを分析できます。 このページに登録されるのはコンテンツリクエストのみです。 具体的には、次のリクエストが取り込まれます。

  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 がクエリを実行する方法を説明するツールです。 アクセスするには、 ツール/運営/診断 AEMのようこそ画面から 次に、「 クエリパフォーマンス そして、 クエリの説明を実行 タブをクリックします。

機能

  • Xpath、JCR-SQL、JCR-SQL2 クエリ言語をサポート
  • 指定したクエリの実際の実行時間をレポート
  • 時間のかかるクエリを検出し、潜在的に時間のかかる可能性のあるクエリに関する警告を表示
  • クエリの実行に使用された Oak インデックスをレポートします
  • 実際の Oak クエリエンジンの説明を表示
  • クリックして読み込むことができる、遅いクエリと人気の高いクエリのリストを提供します

「クエリの説明を実行」UI を表示したら、クエリを入力し、 説明 ボタン:

chlimage_1-124

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

2 つ目のエントリは実行プランです。

ティック 実行時間を含める ボックスを開いてからクエリを実行すると、そのクエリが実行された時間も表示されます。 この ノード数を含める オプションは、ノード数をレポートします。 レポートでは、アプリケーションやデプロイメントのインデックスの最適化に使用できる詳細情報を確認できます。

chlimage_1-125

インデックスマネージャ

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

これには、AEM のようこそ画面から​ツール/操作/診断を選択し、「​インデックスマネージャー**」ボタンをクリックしてアクセスできます。

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

インデックスマネージャー

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

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

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

このウィンドウから、エクスポートする対象(ログファイルおよびスレッドダンプ)と、現在の日付を基準にしたダウンロードに含まれるログの日数を選択できます。

download_status_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 つのメンテナンスカードのギアアイコンを押すことで、タイミングを設定することもできます。

chlimage_1-126

メモ

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

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

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

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

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

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

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

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

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

データストアのガベージコレクションについて詳しくは、 ドキュメントページ.

ワークフローのパージ

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

  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 このタスクに表示されるタイトル 特別メンテナンスタスク 必須
job.topics メンテナンスタスクの一意のトピックです。
Apache Sling ジョブ処理は、メンテナンスタスクを実行するためにこのトピックでジョブを開始します。タスクがこのトピックに登録されているので、実行されます。
トピックはで始める必要があります com/adobe/granite/maintenance/job/
com/adobe/granite/maintenance/job/MyMaintenanceTask 必須

上記のサービスプロパティとは別に、 process() メソッド JobConsumer インターフェイスは、メンテナンスタスクに実行する必要があるコードを追加して実装する必要があります。 指定された 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 を設定する必要があります。

システム概要

この システム概要ダッシュボード AEMインスタンスの設定、ハードウェア、ヘルスの概要を表示します。 システムのヘルスステータスは透過的で、すべての情報が単一のダッシュボードに集計されます。

メモ

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

アクセス方法

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

system_overview_dashboard

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

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

また、 JSON ファイルをクリックしてダッシュボード情報を要約する ダウンロード 」ボタンをクリックします。 この JSON endpoint is /libs/granite/operations/content/systemoverview/export.json また、 curl 外部監視用のスクリプト。

セクション 表示される情報 これが重要になる状況 リンク先
ヘルスチェック
  • 「重大」ステータスのチェックのリスト
  • 警告ステータスのチェックのリスト
視覚的に示す:
  • クリティカルチェックの赤いタグ
  • 警告チェック用のオレンジ色のタグ
  • ヘルスレポートページ
メンテナンスタスク
  • 失敗したタスクのリスト
  • 現在実行中のタスクのリスト
  • 前回の実行で成功したタスクのリスト
  • 一度も実行していないタスクのリスト
  • スケジュールされていないタスクのリスト

視覚的に示す:

  • 失敗したタスクの赤いタグ
  • タスクを実行するためのオレンジ色のタグ(パフォーマンスに影響を与える可能性があるため)
  • 他のすべてのステータスのグレータグ
  • メンテナンスタスクページ
システム
  • オペレーティングシステムと OS のバージョン ( 例:macOS X)
  • から取得したシステム負荷平均 OperatingSystemMXBeanusable
  • ディスク容量(ホームディレクトリがあるパーティション上)
  • 最大ヒープ(MemoryMXBean によって返されます)
該当なし 該当なし
インスタンス
  • AEM版
  • 実行モードのリスト
  • インスタンスが開始された日付
該当なし 該当なし
リポジトリ
  • Oak バージョン
  • ノードストアのタイプ(セグメント Tar またはドキュメント)
    • タイプが document の場合は、ドキュメントストアのタイプが表示されます(RDB または Mongo)
  • カスタムデータストアがある場合:
    • ファイルデータストアの場合、パスが表示されます
    • S3 データストアの場合は、S3 バケットの名前が表示されます
    • 共有 S3 データストアの場合は、S3 バケットの名前が表示されます
    • Azure データストアの場合は、コンテナが表示されます
  • カスタムの外部データストアがない場合は、この事実を示すメッセージが表示されます
該当なし 該当なし
配布エージェント
  • ブロックされたキューを持つエージェントのリスト
  • 誤って設定されたエージェントのリスト(「設定エラー」)
  • キューの処理が一時停止されたエージェントのリスト
  • アイドルエージェントのリスト
  • 実行中のエージェント(現在エントリを処理中)のリスト

視覚的に示す:

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

視覚的に示す:

  • ブロックされたエージェントの赤いタグ
  • 一時停止中のエージェント用の灰色のタグ
レプリケーションページ
ワークフロー
  • ワークフロージョブ:
    • 失敗したワークフロージョブの数(存在する場合)
    • キャンセルされたワークフロージョブの数(ある場合)
  • ワークフロー数 - 特定のステータスのワークフローの数(ある場合):
    • 実行中
    • 失敗
    • 停止中
    • 中止

上記に示した各ステータスに対して、クエリが実行されます(制限は 400 ミリ秒)。 400 ミリ秒で、その時点までに取得されたエントリ数が表示されます。

未解釈:

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

Sling ジョブ数 — 特定のステータスのジョブの数(存在する場合):

  • 失敗
  • キュー
  • キャンセル
  • アクティブ

未解釈:

  • 予期しないステータスのジョブや、カウントが高いジョブがある場合は、調査する必要があります。
該当なし
予測ノード数

推定数:

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

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

該当なし 該当なし
バックアップ [ オンラインバックアップ中 ] が表示された場合は、[ オンラインバックアップ中 ] と表示されます。 該当なし 該当なし
インデックス作成

表示:

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

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

該当なし 該当なし

このページ