AEM 6.5 における Groovy コンソールの監査証跡によるセグメントストアの増加の修正（Formsおよびその他のソリューション）

AEM 6.5 オンプレミス環境または AMS 環境で突然のディスクスパイクが発生し、TarMK セグメントストアが急速に増加している場合、高頻度の Groovy コンソールジョブにより /var/groovyconsole/audit 下に大きな監査証跡ノードが作成されている可能性があります。 このシナリオはAEM Forms環境で発生しましたが、Groovy コンソールを使用するAEM 6.5 TarMK の設定で発生する可能性があります。
この記事では、問題のあるジョブを特定し、監査ノードを安全に削除し、セグメントストアでオフライン圧縮を実行してディスク領域を再利用する方法について説明します。

メモ： このシナリオには、カスタムの Groovy コンソールスクリプトと監査証跡が含まれます。 Groovy コンソールは、サードパーティまたはコミュニティのツールであり、標準のAEM製品には含まれていません。

説明 description

環境

注意：

問題/症状

Adobe Experience Manager（AEM） 6.5 Forms オンプレミスまたはAdobe Managed Services（AMS）の実稼動環境では、ディスク使用量が突然、急速に増加しています。 crx-quickstart/repository/segmentstore ディレクトリは数日で急速に拡張し、数百ギガバイトに達します。 オンラインでのリビジョンクリーンアップは実行されますが、領域の再利用に失敗します。 最近のデプロイメントや設定の変更が、データの増加を説明するものではありません。

分析中に、以下の症状が観察されます。

調査によると、カスタム Groovy コンソールジョブが数分ごとに実行されるようにスケジュールされており、/var/groovyconsole/audit/user/<year> などのユーザー固有および年固有のパスで大きな監査証跡エントリを書き込むことが示されています。 これらの監査ノードは、リポジトリの増加を引き起こし、セグメントストアの増加を促進します。

解決策 resolution

手順 1：監査証跡を生成する Groovy コンソールジョブを特定する

手順については、AEM as a Cloud Service ユーザーガイドの CRXDE Liteの使用 ​ を参照してください。 一般的なジョブノードには、次のようなプロパティが含まれています。

これらのジョブで監査ログが生成されるだけで、ビジネスに不可欠なコンテンツが生成されない場合は、監査ノードを安全にクリーンアップし、スケジュールを調整または削除して、急激な増加を防ぐことができます。 手順については、AEM 6 の監査ログのメンテナンス ​ を参照してください。

手順 2:Groovy コンソール監査ノードのクリーンアップ

リポジトリサイズを小さくするには、/var/groovyconsole/audit/user/<year> の下に蓄積された監査ノードを削除します。 それ以上の増加を避けるために、新規のスケジュールされたジョブではなく、オンデマンドの Groovy コンソールスクリプトを使用します。

重要： 実稼動システムでは注意して Groovy コンソールを使用してください。 必ず、最初に下位の環境でスクリプトをテストし、ターゲット・パスを検証して、適切な変更管理の手順に従ってスクリプトを実行します。 手順については、『AEM 6.5 ユーザガイド』の AEM 6 の監査ログのメンテナンス ​ を参照してください。

このシナリオでは、ユーザーおよび年に固有のパスの下にある Groovy コンソール監査記録ノードから増加が見られます。次に例を示します。

/var/groovyconsole/audit/user/<year>

このパスには、Groovy コンソールジョブの監査データのみが含まれており、安全に削除できます。 環境に合わせて、パスの年セグメントを調整します。

Groovy コンソールスクリプトの例：

import javax.jcr.Session

// Adjust this path to the correct audit root for your environment.
// Example: "/var/groovyconsole/audit/user/<year>"
def path = "/var/groovyconsole/audit/user/<year>"

Session s = session  // Groovy Console injects a live JCR session

if (s.nodeExists(path)) {
    s.getNode(path).remove()
    s.save()
    println "Removed audit nodes under " + path
} else {
    println "No audit nodes to remove at " + path
}

/var/groovyconsole/audit/user/<year> のノードを削除するのに十分な権限を持つユーザーアカウントの下で、実稼動環境でスクリプトを 1 回実行します。 多くの環境では、これは管理ユーザーまたはサービスユーザーですが、正確な権限は内部セキュリティモデルによって異なります。

スクリプトが完了したら、CRXDE Liteで監査ノードが削除されていることを確認し、Groovy コンソールジョブが実行されなくなったか、それほど積極的でないスケジュールと最小限のログで実行されていることを確認します。

手順 3：オフライン圧縮のためのダウンタイムとバックアップのスケジュール設定

手順 4：セグメントストアに対してオフラインでのリビジョン圧縮を実行する

手順については、『AEM 6.5 ユーザガイド ​ リビジョンクリーンアップ ​ 』を参照してください。 AEM 6.5 サービスパックレベルと互換性のある oak-run バージョンを使用します。 空きディスク容量として、現在のセグメントストアのサイズの少なくとも 2 倍が使用できることを確認します。 インスタンスをホストするサーバー上のAEM インストールディレクトリから次のコマンドを実行します。

java -Xmx16g -jar oak-run-1.22.21.jar compact ./crx-quickstart/repository/segmentstore

プロセスが正常に完了するまで監視します。 コンパクションを中断しないでください。 これにより、リポジトリが破損する可能性があります。

手順 5:AEMを再起動して検証する

予防とベストプラクティス

メモ