現在表示中:

概要

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

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

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

操作ダッシュボードには、AEM のようこそ画面からツール運営ヘルスレポートを選択してアクセスできます。

注意:

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

ヘルスレポート

ヘルスレポートシステムは、Sling ヘルスチェックを使用して AEM インスタンスのヘルスに関する情報を提供します。これには、OSGI、JMX、HTTP のいずれかの要求(JSON 経由)を使用します。設定可能なカウンターの測定値やしきい値を提供し、場合によっては、問題の解決方法に関する情報も提供します。

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

ヘルスチェック

ヘルスレポートは、特定の製品領域に関してヘルスの良し悪しを示すカードのシステムです。これらのカードは、Sling ヘルスチェックを視覚化したものであり、JMX およびその他のソースからの情報を集約し、処理済みの情報を再度 MBean として公開します。MBean は、JMX Web コンソールorg.apache.sling.healthcheck ドメインの下でも検査できます。

ヘルスレポートインターフェイスには、AEM のようこそ画面からツール運営ヘルスレポートを選択してアクセスするか、次の URL を使用して直接アクセスできます。

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

ops1

カードシステムには、OK警告重要の 3 つのステータス状態があります。状態を決めるルールやしきい値は、ユーザーインターフェイスを使用して、カードの上にマウスポインターを置き、アクションバーのギアアイコンをクリックすることによって設定できます。

ops2

ヘルスチェックの種類

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

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

個別ヘルスチェックは、1 つのステータスカードに対応する単一のヘルスチェックです。個別ヘルスチェックは、ルールやしきい値を含めて設定でき、特定されたヘルス問題を解決するためのリンクを 1 つまたは複数提供できます。例えば、エラーエントリがシステムのログに記録されている場合、そのエントリは、「ログエラー」の詳細ページに、診断ツールの「ログメッセージ」分析へのリンクと共に表示され、実際にエラーを調べることができます。

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

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

ヘルスチェックを作成する方法

操作ダッシュボード用に作成できるヘルスチェックには、個別ヘルスチェックと複合ヘルスチェックの 2 種類があります。

個別ヘルスチェックの作成

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

  1. Sling ヘルスチェックを作成するには、Sling ヘルスチェックインターフェイスを実装する OSGI コンポーネントを作成する必要があります。このコンポーネントはバンドル内部に追加します。コンポーネントのプロパティによって、ヘルスチェックが完全に識別されます。コンポーネントがインストールされると、JMX Mbean がヘルスチェック用に自動的に作成されます。詳しくは、Sling ヘルスチェックのドキュメントを参照してください。
    Sling ヘルスチェックコンポーネントの例は次のとおりです。

    @Component(metatype=true, label="Example Health Check",
            description="This is an example Health Check.")
    @Properties({
            @Property(name=HealthCheck.NAME, value="Example",
                    label="Name", description="Name of the health check."),
            @Property(name=HealthCheck.TAGS, unbounded= PropertyUnbounded.ARRAY, value={"example", "test"},
                    label="Tags", description="Tags for the health check."),
            @Property(name=HealthCheck.MBEAN_NAME, value="exampleHealthCheck",
                    label="MBean Name", description="Name of the JMX mbean to register for this check.")
    })
    @Service(value=HealthCheck.class)
    public class ExampleHealthCheck implements HealthCheck {
     ...
    }

    注意:

    MBEAN_NAME プロパティは、このヘルスチェック用に生成される Mbean の名前を定義します。

  2. ヘルスチェックを作成したら、Web インターフェイスでアクセスできるようにするために、ダッシュボードの設定ノードにエントリを挿入する必要があります。この手順では、ヘルスチェックの JMX Mbean 名(MBEAN_NAME プロパティ)を知っている必要があります。ヘルスチェックの設定を作成するには、CRX を開いて新しいノード(タイプ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」である場合は、次のパスの末尾に「test」を追加します。

    /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck

    最終的なパスは次のようになります。

    /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/test

複合ヘルスチェックの作成

複合ヘルスチェックの役割は、共通の機能を共有している複数の個別ヘルスチェックを集約することです。例えば、セキュリティ複合ヘルスチェックは、セキュリティチェックをおこなうすべての個別ヘルスチェックをまとめてグループ化します。複合を作成するには、複合ヘルスチェックの OSGI 設定を作成する、複合ヘルスチェックのエントリをダッシュボードの設定ノードに追加するなど、複数の手順が必要です。

 

  1. OSGI コンソールで Web 設定マネージャーに移動します。これをおこなうには、http://serveraddress:port/system/console/configMgr にアクセスします。

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

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

    ops14
  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 タグのいずれかが含まれている個別のヘルスチェックと複合ヘルスチェックをすべて集約します。

     

    注意:

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

ヘルスチェック名 複合ヘルスチェックのフィルタータグ タグ 説明 デフォルトのしきい値(設定可能) 推奨されるアクション
システムチェック システム   このヘルスチェックは、すべてのメンテナンスタスクで自動的に生成されます。これは、タスクの最後の実行が失敗したかどうか、またはまったく実行されていないかどうかを示します。    
セキュリティチェック セキュリティ   複合セキュリティチェックは、セキュリティに関連する個別のヘルスチェックをグループ化します。個別のヘルスチェックは、セキュリティチェックリストのドキュメントページで入手できるセキュリティチェックリストに関連しています。    
CRXDE サポート  
  • バンドル
  • セキュリティ
  • 実稼働
CRXDE サポートバンドルがアクティブな場合、このヘルスチェックは失敗します。    
デフォルトのログインアカウント  
  • ログイン
  • セキュリティ
  • 実稼働
デフォルトのログインアカウントが無効にされていない場合、このヘルスチェックは失敗します。    
Sling Get Servlet  
  • dos
  • sling
  • セキュリティ
  • 実稼働
デフォルトの Sling Get Servlet 設定がセキュリティガイドラインに従っていない場合、このヘルスチェックは失敗します。    
CQ ディスパッチャー設定
 
  • ディスパッチャー
  • 実稼働
  • セキュリティ
ディスパッチャーコンポーネントの基本設定をチェックします。    
HTML ライブラリマネージャー  
  • cq
  • セキュリティ
  • 実稼働

 

デフォルトの HTML ライブラリマネージャー設定がセキュリティガイドラインに従っているかどうかをチェックします。    
レプリケーションとトランスポートユーザー  
  • セキュリティ
  • レプリケーション
  • cq
レプリケーションとトランスポートユーザーをチェックするヘルスチェック。    
Sling Java Script Handler  
  • sling
  • セキュリティ
  • 実稼働
Sling Java Script Handler 設定がセキュリティガイドラインに従っているかどうかをチェックします。    
Sling Jsp Script Handler  
  • sling
  • セキュリティ
  • 実稼働
Sling Jsp Script Handler 設定がセキュリティガイドラインに従っているかどうかをチェックします。    
Sling Referrer Filter  
  • sling
  • セキュリティ
  • 実稼働
  • csrf
CSRF 攻撃を防ぐために Sling Referrer Filter が設定されているかどうかをチェックします。    
ユーザープロファイルへのデフォルトアクセス  
  • acl
  • セキュリティ
このヘルスチェックは、すべてのユーザーにユーザープロファイルへの読み取り権限があるかどうかをチェックします。    
WCM フィルター設定  
  • cq
  • セキュリティ
  • 実稼働
デフォルトの WCM フィルター設定がセキュリティガイドラインに従っているかどうかをチェックします。    
WebDav アクセス  
  • バンドル
  • セキュリティ
  • 実稼働
このヘルスチェックは、CRXDE サポートバンドルがアクティブであるかどうかをチェックします。    
Web サーバー設定  
  • Web サーバー
  • 実稼働
  • セキュリティ
  • クリックジャッキング

Web サーバーが、SAMEORIGIN に設定された X-FRAME-OPTIONS HTTP ヘッダーを送信するかどうかをチェックします。

機能させるためには、ディスパッチャーの設定に使用した公開サーバーアドレスを使用して、このヘルスチェックを設定する必要があります。

   
レプリケーションキュー     レプリケーションが停止しているかどうかをチェックします。例えば、レプリケーションキューの最初の項目の再試行回数が、設定で許可されている回数より多い場合、レプリケーションは停止していると見なされます。 numberOfRetriesAllowed=3
  • キューを検査するためにレプリケーションエージェントにリンクします
  • 診断ツールセクションのログメッセージ分析にリンクします。
ログエラー     このヘルスチェックは、ログメッセージにエラーがあるかどうかを通知します。    
アクティブなバンドル     非アクティブなバンドルまたは解決されないバンドルがある場合に失敗するヘルスチェック。    
応答パフォーマンス    

リクエストパフォーマンスに対応するヘルスチェック。リクエストの割合が重要または警告しきい値を超えている場合、このヘルスチェックは重要または警告状態になります。それ以外の場合、このヘルスチェックは正常となります。

最後の期間(デフォルトでは 60 分間)におこなわれたリクエストが対象となります。

リクエストの割合、重要および警告しきい値を、要求ステータスヘルスチェックの設定で指定できます。

期間の設定は、Adobe Granite Timed Requests Logger で変更できます。

   
クエリーパフォーマンス    

クエリーパフォーマンスに対応するヘルスチェック。最後の 1 時間のクエリーの解決時間の平均が、重要または警告のしきい値を超えている場合、ヘルスチェックは重要/警告の状態となります。

重要および警告のしきい値は設定可能な値であり、クエリーヘルスチェックの設定で変更できます。

警告しきい値 = 10ms

重要しきい値 = 15ms

 
実稼動準備完了のヘルスチェック
    このヘルスチェックは、実稼動準備完了パッケージがインストールされているかどうかを検証します。このパッケージについて詳しくは、以下を参照してください。
   

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

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

    ops16

診断ツール

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

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

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

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

ops3

ログメッセージ

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

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

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

例:

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

注意:

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

注意:

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

注意:

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

要求パフォーマンス

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

  1. /content の下のリソースにアクセスする要求
  2. /etc/design の下のリソースにアクセスする要求
  3. .html」の拡張子が付いた要求
ops5

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

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

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

取り込む要求の数を変更するには、以下の手順を実行する必要があります。

  1. http://serveraddress:port/system/console/configMgr にアクセスして Web 設定マネージャーに移動します。

  2. Adobe Granite Timed Requests Logger というエントリを探します。

  3. 「Edit」ボタンをクリックして「Longest requests history size」プロパティを変更します。

  4. 変更内容を保存します。

クエリーパフォーマンス

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

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

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

クエリーの説明を実行

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

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

機能

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

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

ops9

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

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

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

ops10

インデックスマネージャ

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

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

また、この URL(http://サーバーアドレス:ポート /libs/granite/operations/content/diagnosis/tool.html/_granite_oakindexmanager)から直接アクセスできます。

ops13

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

各インデックスの「再インデックス」列のアイコンをクリックすることで、単独の再インデックスをトリガーできます。また、複数のインデックスを選択して「一括再インデックス」ボタンをクリックすることで、一括再インデックスをトリガーできます。

Status.zip のダウンロード

システムのステータスおよび設定に関する便利な情報を含む zip ファイルをダウンロードします。アーカイブには複数のテキストファイルが含まれ、アクティブなサービス、ログファイル、アクティブな設定などの情報が含まれています。これは、システムステータスのスナップショットを作成して分析のために送信する場合に特に便利です。

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

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

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

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

自動メンテナンスタスク

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

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

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

デフォルトで、操作ダッシュボードでは次の 2 つの自動メンテナンスタスクが使用可能です。

  1. 日別メンテナンスウィンドウメニューの下のリビジョンのクリーンアップ
  2. 週別メンテナンスウィンドウメニューの下のワークフローのパージ

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

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

ops12

注意:

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

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

警告:

AEM 6.2 では、オンラインリビジョンクリーンアップのサポートは制限されています。この機能の使用条件について詳しくは、アドビカスタマーケアにお問い合わせください。

推奨およびサポートされているリビジョンのクリーンアップ実行方法は、オフラインでのリビジョンクリーンアップです。詳しくは、オフラインリビジョンクリーンアップの実行を参照してください。

ワークフローのパージ

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

  1. 週別メンテナンスウィンドウページをクリックします。

  2. 次のページで、ワークフローのパージカードの再生ボタンをクリックします。

監査ログのメンテナンス

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

カスタムメンテナンスタスク

カスタムメンテナンスタスクは OSGi サービスとして実装できます。メンテナンスタスクのインフラストラクチャは Apache Sling のジョブ処理に基づいているので、メンテナンスタスクでは Java インターフェイス org.apache.sling.event.jobs.consumer.JobExecutor を実装する必要があります。さらに、以下に示すいくつかのサービス登録プロパティがメンテナンスタスクとして検出されることを宣言する必要があります。

サービスプロパティ名
説明
タイプ
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

GitHub で開く

/*
 * #%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
 * 
 *      http://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,>

デプロイされたサービスは、操作ダッシュボードの UI に表示され、いずれかのメンテナンススケジュールに追加できます。

ops7

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

AEM に付属のメンテナンスタスク

AEM 6 には、デフォルトの自動メンテナンスタスクセットが付属しています。以下の表では、各メンテナンスタスクが AEM 6 に含まれるストレージ要素で使用可能かどうかを説明します。

メンテナンスタスク 名前 CRX2 Tar MK
Mongo MK メンテナンスウィンドウ 備考
バージョンのパージ com.day.cq.wcm.core.impl.VersionPurgeTask 設定可能。 デフォルトでは有効になりません。操作ダッシュボードの「週別メンテナンスウィンドウ」セクションで「+」ボタンをクリックすると、手動で追加できます。
ワークフローのパージ WorkflowPurgeTask 週別 このタスクを正常に実行するには、パージ設定を最初に作成する必要があります。
データストアのガベージコレクション
DataStoreGarbageCollectionTask × 週別  
Tar の圧縮/最適化 TarOptimizeTask × × 日別  
リビジョンのクリーンアップ
RevisionCleanupTask × 日別  
Tar 索引統合
TarIndexMergeTask × × 日別  
監査ログのメンテナンスタスク com.day.cq.audit.impl.AuditLogMaintenanceTask 週別  

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー