Resolver o crescimento do armazenamento de segmentos causado pelas trilhas de auditoria do console Groovy no AEM 6.5 (Forms e outras soluções)

Se o ambiente do AEM 6.5 no local ou do AMS mostrar picos repentinos de disco e um armazenamento de segmentos TarMK em rápido crescimento, um trabalho do Groovy Console de alta frequência poderá criar grandes nós de trilha de auditoria em /var/groovyconsole/audit. Esse cenário foi observado em um ambiente AEM Forms, mas pode ocorrer em qualquer configuração TarMK do AEM 6.5 usando o Groovy Console.
Este artigo explica como identificar o trabalho incorreto, remover com segurança seus nós de auditoria e recuperar espaço em disco executando a compactação offline no armazenamento de segmentos.

Observação: este cenário envolve scripts de Console do Groovy personalizados e trilhas de auditoria. O Groovy Console é uma ferramenta de terceiros/da comunidade e não faz parte do produto AEM padrão.

Descrição description

Ambiente

Notas:

Problema/Sintomas

Em um ambiente de produção Adobe Experience Manager (AEM) 6.5 Forms no local ou Adobe Managed Services (AMS), há um aumento súbito e rápido no uso do disco. O diretório crx-quickstart/repository/segmentstore cresce rapidamente ao longo de vários dias e atinge centenas de gigabytes. A limpeza de revisão online é executada, mas falha ao recuperar espaço. Nenhuma implantação ou alteração recente na configuração explica o crescimento.

Durante a análise, observam-se os seguintes sintomas:

A investigação mostra que um trabalho personalizado do Groovy Console, agendado para execução a cada poucos minutos, grava grandes entradas de trilha de auditoria em um caminho específico de usuário e ano, como /var/groovyconsole/audit/user/<year>. Esses nós de auditoria causam sobrecarga do repositório e impulsionam o crescimento do armazenamento de segmentos.

Resolução resolution

Etapa 1: identificar o trabalho do Console do Groovy que gera trilhas de auditoria

Para ver as etapas, consulte Uso do CRXDE Lite no Guia do Usuário do AEM as a Cloud Service. Um nó de trabalho típico contém propriedades semelhantes às seguintes:

Se essas tarefas gerarem apenas logs de auditoria e não conteúdo essencial aos negócios, você poderá limpar com segurança seus nós de auditoria e ajustar ou remover a programação para evitar um crescimento ainda mais rápido. Para obter etapas, consulte Manutenção do Log de Auditoria no AEM 6.

Etapa 2: Limpar nós de auditoria do Console Groovy

Para reduzir o tamanho do repositório, remova os nós de auditoria acumulados em /var/groovyconsole/audit/user/<year>. Use um script sob demanda do Groovy Console em vez de um novo trabalho agendado para evitar mais crescimento.

Importante: use o Console do Groovy com cuidado nos sistemas de produção. Sempre teste os scripts em um ambiente mais baixo primeiro, verifique o caminho de destino e execute-os nos procedimentos apropriados de gerenciamento de alterações. Para obter etapas, consulte Manutenção do Log de Auditoria no AEM 6 no Guia do Usuário do AEM 6.5.

Neste cenário, o crescimento vem dos nós de trilha de auditoria do console do Groovy em um caminho específico de usuário e ano, por exemplo:

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

Este caminho contém apenas dados de auditoria para os trabalhos do Console Groovy e pode ser removido com segurança. Ajuste o segmento de ano no caminho para corresponder ao seu ambiente.

Exemplo de script do 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
}

Execute o script uma vez em produção em uma conta de usuário que tenha permissões suficientes para remover nós em /var/groovyconsole/audit/user/<year>. Em muitos ambientes, esse é um usuário administrativo ou de serviço, mas as permissões exatas dependem do modelo de segurança interno.

Depois que o script for concluído, verifique no CRXDE Lite se os nós de auditoria foram removidos e confirme se o trabalho do Groovy Console não é mais executado ou executado com uma programação menos agressiva e registro mínimo.

Etapa 3: agendar tempo de inatividade e backup para compactação offline

Etapa 4: executar a compactação de revisão offline no segmentstore

Para ver as etapas, consulte Limpeza de revisão no Guia do usuário do AEM 6.5. Use uma versão do oak-run compatível com seu nível de service pack do AEM 6.5. Verifique se pelo menos o dobro do tamanho atual do armazenamento de segmentos está disponível como espaço livre em disco. Execute o seguinte comando do diretório de instalação do AEM no servidor que hospeda a instância:

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

Monitore o processo até que ele seja concluído com sucesso. Não interrompa a compactação. Isso pode corromper o repositório.

Etapa 5: reiniciar o AEM e validar

Prevenção e práticas recomendadas

Notas