在AEM 6.5(Forms和其他解决方案)中解决Groovy Console审核跟踪导致的区段存储增长问题
如果您的AEM 6.5内部部署或AMS环境显示突然的磁盘尖峰和快速增长的TarMK区段存储,则高频Groovy控制台作业可能会在/var/groovyconsole/audit下创建大型审核跟踪节点。 虽然在AEM Forms环境中观察到这种情况,但这种情况可能在使用Groovy Console的任何AEM 6.5 TarMK设置中出现。
本文介绍了如何识别违规作业、安全删除其审核节点,以及通过运行区段存储上的离线压缩来回收磁盘空间。
注意:此方案涉及自定义Groovy控制台脚本和审核跟踪。 Groovy Console是第三方/社区工具,不是标准AEM产品的一部分。
描述 description
环境
- 产品: Adobe Experience Manager (AEM) 6.5(包括AEM Forms)
- 版本:6.5部署:内部部署或Adobe Managed Services (AMS)持久性:带有segmentstore的TarMK
- 操作系统:Linux或Windows
注意:
- 所描述的问题在AEM Forms环境中观察到,但可能在使用Groovy Console的任何AEM 6.5 TarMK设置中发生。
- 此过程不适用于AEM as a Cloud Service,因为用户没有对区段存储的文件系统级访问权限。
问题/症状
在Adobe Experience Manager (AEM) 6.5 Forms内部部署或Adobe Managed Services (AMS)生产环境中,磁盘使用量会急剧增加。 crx-quickstart/repository/segmentstore目录在数天内增长迅速,达到数百GB。 联机修订清理运行,但无法回收空间。 近期没有部署或配置更改可以解释这种增长。
在分析过程中,发现以下症状:
crx-quickstart/repository/segmentstore迅速增长到数十或数百GB。- 磁盘使用率在短时间内达到峰值,通常在周末或下班时。
- 在线修订清理运行,但不会显着减少区段存储大小。
- 在增长期间,没有应用程序部署或配置更改。
- 在
/var/groovyconsole/audit/user/<year>下存在许多审核节点,这些节点由Groovy Console计划作业创建,每两分钟运行一次。
调查显示,计划每隔几分钟运行的自定义Groovy Console作业会在特定于用户和年份的路径(如/var/groovyconsole/audit/user/<year>)下写入大型审核跟踪条目。 这些审核节点会导致存储库膨胀,并会推动区段存储增长。
解决方法 resolution
步骤1:识别生成审核跟踪的Groovy Console作业
- 在受影响的AEM Forms实例上打开CRXDE Lite。
- 浏览到存储现有Groovy Console作业的节点,例如
/var/groovyconsole下的节点。 - 使用短时间间隔cron表达式查找现有作业,例如
0 0/2 * * * ?,该表达式每两分钟运行一次。
有关步骤,请参阅《CRXDE Lite用户指南》中的使用AEM as a Cloud Service。 典型作业节点包含与以下内容类似的属性:
jobTitle = Remove Old File AttachmentscronExpression = 0 0/2 * * * ?(每2分钟运行一次)scheduledJobId = <job-id>script = <groovy-script-body>output = <summary-of-job-output>
如果这些作业只生成审核日志,而没有业务关键型内容,您可以安全地清理其审核节点,并调整或移除时间表以防止进一步快速增长。 有关步骤,请参阅AEM 6中的审核日志维护。
步骤2:清理Groovy控制台审核节点
要减小存储库大小,请删除/var/groovyconsole/audit/user/<year>下的累积审核节点。 使用按需提供的Groovy控制台脚本(而不是新的计划作业)来避免进一步增长。
重要提示:在生产系统上使用Groovy Console时请务必谨慎。 始终首先在较低级别的环境中测试脚本,验证目标路径,然后按照适当的更改管理过程运行它们。 有关步骤,请参阅《AEM 6.5用户指南》中的AEM 6中的审核日志维护。
在此方案中,增长来自特定于用户和年份的路径下的Groovy Console审核跟踪节点,例如:
/var/groovyconsole/audit/user/<year>
此路径仅包含Groovy Console作业的审核数据,可以安全删除。 调整路径中的年段以匹配您的环境。
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>下的节点的用户帐户运行一次脚本。 在许多环境中,这是管理员或服务用户,但确切的权限取决于您的内部安全模型。
脚本完成后,在CRXDE Lite中验证是否已删除审核节点,并确认Groovy控制台作业不再运行或以更少的时间表和最小日志记录时间运行。
步骤3:安排离线压缩的停机时间和备份
- 在非上班时间计划一个维护时段。
- 如果需要,可显示维护页面或使用现有操作过程阻止用户访问。
- 继续之前,请创建实例的完整备份(包括AEM安装目录和数据存储)。脱机压缩更改了磁盘上的存储库,因此不能轻易还原。 有关步骤,请参阅监视和维护Adobe Experience Manager实例中的备份。
- 彻底停止AEM Forms实例。
步骤4:对区段存储区运行脱机修订压缩
有关步骤,请参阅《AEM 6.5用户指南》中的修订清理。 使用与您的AEM 6.5 Service Pack级别兼容的oak-run版本。 确保可用磁盘空间至少为当前段存储大小的两倍。 从托管实例的服务器上的AEM安装目录运行以下命令:
java -Xmx16g -jar oak-run-1.22.21.jar compact ./crx-quickstart/repository/segmentstore
监控该进程,直到它成功完成。 请勿中断压缩。 这样做可能会损坏存储库。
步骤5:重新启动AEM并验证
- 压缩完成后启动AEM Forms实例。
- 删除在停机期间使用的任何维护页面或负载平衡器规则。
- 验证所有Forms功能是否均可按预期工作(创作、提交、处理、集成)。
- 检查
crx-quickstart/repository/segmentstore的大小和磁盘使用情况,以确认该大小已降至预期级别。
预防和最佳做法
- 避免在生产环境中执行高频Groovy Console作业。 谨慎使用计划的作业,并且仅在必要时使用。
- 将Groovy Console和其他工具的审核日志记录保留在适当的级别,并定期清除审核数据。
- 监视
segmentstore的大小和磁盘使用情况。 在使用接近定义的阈值时配置警报。 - 根据Adobe建议运行在线修订清理,并根据需要执行定期离线压缩,尤其是在进行大规模清理之后。
- 请尽可能使用内置的维护任务和支持的API,而不是生成大量审核数据的自定义脚本。
注释
- 不要从
crx-quickstart/repository/segmentstore中手动删除文件。 直接删除文件可能会损坏存储库并导致数据丢失。 - 如果在线修订清理没有减小区段存储大小并且区段存储继续增长,请查看最近的自定义作业、脚本和批量操作以确定写入活动的来源。
- 如果对存储库运行状况存有疑问,请首先在克隆环境中使用已记录的Oak一致性和
check工具,然后才将相同的步骤应用于生产环境。