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

CAUTION
AEM 6.4 の拡張サポートは終了し、このドキュメントは更新されなくなりました。 詳細は、 技術サポート期間. サポートされているバージョンを見つける ここ.

はじめに introduction

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

操作ダッシュボード:

  • ワンクリックでのシステムステータスで、運用部門の効率化を支援
  • システムヘルスの概要を、1 つの場所で一元的に提供します。
  • 問題の検出、分析、修正に要する時間を短縮
  • 自己完結型のメンテナンスを自動化し、プロジェクト運用コストを大幅に削減

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

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

ヘルスレポート health-reports

ヘルスレポートシステムは、Sling ヘルスチェックを通じてAEMインスタンスのヘルスに関する情報を提供します。 これは、OSGI、JMX、HTTP リクエスト(JSON 経由)またはタッチ UI を介して実行できます。 設定可能な特定のカウンターの測定値としきい値を提供し、場合によっては、問題の解決方法に関する情報を提供します。

以下で説明するような、様々な機能があります。

ヘルスチェック health-checks

この ヘルスレポート は、特定の製品領域に関して、健康状態が良いか悪いかを示すカードのシステムです。 これらのカードは、Sling ヘルスチェックのビジュアライゼーションで、JMX や他のソースからのデータを集計し、処理された情報を MBean として再び公開します。 これらの MBean は、 JMX Web コンソールorg.apache.sling.healthcheck ドメイン。

ヘルスレポートインターフェイスには、AEM のようこそ画面の​ ツール運用ヘルスレポート ​メニューからアクセスするか、次の URL から直接アクセスできます。

https://<serveraddress>:port/libs/granite/operations/content/healthreports/healthreportlist.html

chlimage_1-414

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

chlimage_1-415

ヘルスチェックのタイプ health-check-types

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

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

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

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

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

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

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

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

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

  1. Sling ヘルスチェックを作成するには、Sling HealthCheck インターフェイスを実装する 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-63

  4. 設定を作成して保存します。 新しい設定で Mbean が作成されます。

    各設定プロパティの目的は次のとおりです。

    • 名前 (hc.name): 複合ヘルスチェックの名前。 意味のある名前を付けることをお勧めします。
    • タグ (hc.tags): このヘルスチェックのタグ。 この複合ヘルスチェックが別の複合ヘルスチェックの一部を目的とする場合(ヘルスチェックの階層など)、この複合が関連するタグを追加します。
    • MBean 名 (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
    デフォルトでダッシュボードに既に存在する複合チェックの下に論理的に属する個々のヘルスチェックを作成すると、自動的にキャプチャされ、それぞれの複合チェックの下にグループ化されます。 このため、これらのチェック用に新しい設定ノードを作成する必要はありません。
    例えば、個別セキュリティヘルスチェックを作成する場合は、「security」タグを割り当ててインストールするだけで、操作ダッシュボードのセキュリティチェック複合チェックの下にヘルスチェックが自動的に表示されます。

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 です。

同期済みのクロック

このチェックは、 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 上で実行され、予約済みコードキャッシュのサイズが最小しきい値未満の場合(デフォルト値は 90MB)、警告を返します

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

このヘルスチェックの 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 での監視 monitoring-with-nagios

ヘルスチェックダッシュボードは、Granite JMX Mbean 経由で Nagios と統合できます。以下の例では、AEM を実行しているサーバー上で使用されているメモリを表示するチェックの追加方法を説明します。

  1. 監視サーバーで Nagios を設定してインストールします。

  2. 次に、Nagios Remote Plugin Executor(NRPE)をインストールします。

    note note
    NOTE
    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-416

    以下は、Nagios Core を使用している場合のホスト設定ファイルの例です。

    code language-xml
    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 チェックコマンドを定義します。

    code language-xml
    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 サーバー上の使用メモリのためのサービスを追加します。

    code language-xml
    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-417

診断ツール diagnosis-tools

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

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

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

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

chlimage_1-418

ログメッセージ log-messages

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

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

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

例:

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

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

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

chlimage_1-419

NOTE
指定したフィルターを介して ERROR メッセージのみを取り込むようにロガー名を設定することはできません。 デフォルトでは、すべての ERROR メッセージが取り込まれます。
NOTE
ログメッセージのユーザーインターフェイスには、実際のエラーログは反映されていません。 UI で他のタイプのログメッセージを設定しない限り、ERROR メッセージのみが表示されます。 特定のログメッセージを表示する方法については、上記の手順を参照してください。
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-420

ページには次の情報が表示されます。

  • リクエストがおこなわれた時刻
  • リクエストの URL とメソッド
  • 時間(ミリ秒)

デフォルトでは、最も遅い 20 件のページリクエストが取り込まれますが、この制限は設定マネージャーで変更できます。

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

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

ページには次の情報が表示されます。

  • クエリが実行された時刻
  • クエリの言語
  • クエリが発行された回数
  • クエリの文
  • 時間(ミリ秒)

chlimage_1-421

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

Oak は、任意のクエリに対して、リポジトリ内の oak:index ノード。 クエリに応じて、Oak で異なるインデックスが選択される場合があります。 Oak がクエリを実行する方法を理解することは、クエリを最適化する最初の手順です。

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

機能

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

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

chlimage_1-422

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

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

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

chlimage_1-423

インデックスマネージャ the-index-manager

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

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

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

chlimage_1-424

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

ステータス ZIP をダウンロード download-status-zip

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

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

download_status_zip

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

これにより、トリガーに存在するスレッドに関する情報を含む zip のダウンロードがシステムに含まれます。 各スレッドに関する情報(ステータス、クラスローダ、スタックトレースなど)が提供されます。

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

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

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

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

操作ダッシュボードのメンテナンスページに移動するには、に移動する必要があります。 ツール/運営/ダッシュボード/メンテナンス AEMのようこそ画面から、または次のリンクに直接移動します。

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

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

  1. リビジョンのクリーンアップ」タスク ( 日別メンテナンスウィンドウ メニュー

  2. Lucene バイナリクリーンアップ ​タスクは、 日別メンテナンスウィンドウ メニュー

  3. ワークフローのパージ ​タスク ( 週別メンテナンスウィンドウ メニュー

  4. 週別メンテナンスウィンドウ ​メニューの下の​ データストアのガベージコレクション ​タスク。

  5. 週別メンテナンスウィンドウ ​メニューの下の​ 監査ログのメンテナンス ​タスク。

  6. 週別メンテナンスウィンドウ ​メニューの下の​ バージョンのパージのメンテナンス ​タスク。

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

また、2 つのメンテナンスカードのギアアイコンを押すことで、タイミングを設定することもできます。

chlimage_1-425

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

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

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

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
リポジトリサイズを最適化するには、バージョンパージタスクを頻繁に実行する必要があります。 トラフィック量が限られている場合、タスクは営業時間外にスケジュールする必要があります。

カスタムメンテナンスタスク 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
このタスクに表示されるタイトル
特別メンテナンスタスク
必須
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-426

これにより、対応するリソースが /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 またはドキュメント)

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

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

該当なし
該当なし
配布エージェント
  • ブロックされたキューを持つエージェントのリスト
  • 誤って設定されたエージェントのリスト(「設定エラー」)
  • キューの処理が一時停止されたエージェントのリスト
  • アイドルエージェントのリスト
  • 実行中のエージェント(現在エントリを処理中)のリスト

視覚的に示す:

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

視覚的に示す:

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

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

    • 実行中
    • 失敗
    • 停止中
    • 中止

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

未解釈:

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

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

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

未解釈:

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

推定数:

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

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

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

表示:

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

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

該当なし
該当なし
recommendation-more-help
5ce3024a-cbea-458b-8b2f-f9b8dda516e8