Åtgärda segmentets lagertillväxt som orsakats av granskningsspår i Groovy Console i AEM 6.5 (Forms och andra lösningar)

Om AEM 6.5 på plats eller i AMS-miljö uppvisar plötsliga disktoppar och en snabbt växande TargetMK-segmentbutik kan ett högfrekvent Groovy Console-jobb skapa stora granskningsspår under /var/groovyconsole/audit. Detta scenario har observerats i en AEM Forms-miljö, men kan inträffa i alla AEM 6.5 TjäraMK-inställningar som använder Groovy Console.
I den här artikeln beskrivs hur du identifierar det felaktiga jobbet, tar bort granskningsnoderna på ett säkert sätt och frigör diskutrymme genom att köra offlinekomprimering på segmentlagret.

Obs! Det här scenariot omfattar anpassade Groovy Console-skript och granskningsspår. Groovy Console är en tredjeparts-/community-verktygslåda och ingår inte i AEM standardprodukt.

Beskrivning description

Miljö

Anteckningar:

Problem/symtom

I en Adobe Experience Manager (AEM) 6.5 Forms-produktionsmiljö på plats eller Adobe Managed Services (AMS) ökar diskanvändningen plötsligt. Katalogen crx-quickstart/repository/segmentstore växer snabbt över flera dagar och når hundratals gigabyte. Rensning av onlineändringar körs men tar inte bort utrymme. Inga tidigare distributioner eller konfigurationsändringar förklarar tillväxten.

Under analysen observeras följande symtom:

Undersökningen visar att ett anpassat Groovy Console-jobb, som schemalagts att köras var fåtal minut, skriver stora poster för granskningsspår under en användar- och årsanpassad sökväg som /var/groovyconsole/audit/user/<year>. Dessa granskningsnoder orsakar databasbloatt och ökar segmentlagertillväxten.

Upplösning resolution

Steg 1: Identifiera det Groovy-konsoljobb som genererar granskningsspår

Anvisningar finns i Använda CRXDE Lite i AEM as a Cloud Service användarhandbok. En vanlig jobbnod innehåller egenskaper som liknar följande:

Om dessa jobb bara genererar granskningsloggar och inte affärskritiskt innehåll, kan du rensa upp deras granskningsnoder och justera eller ta bort schemat för att förhindra ytterligare snabb tillväxt. Anvisningar om hur du gör detta finns i Underhåll av granskningslogg i AEM 6.

Steg 2: Rensa granskningsnoder för Groovy-konsolen

Om du vill minska databasstorleken tar du bort de ackumulerade granskningsnoderna under /var/groovyconsole/audit/user/<year>. Använd ett Groovy Console-skript på begäran i stället för ett nytt schemalagt jobb för att undvika ytterligare tillväxt.

Viktigt! Använd Groovy Console med försiktighet i produktionssystem. Testa alltid skript i en lägre miljö först, verifiera målsökvägen och kör dem under lämpliga procedurer för ändringshantering. Anvisningar om hur du gör detta finns i Granskningsloggsunderhåll i AEM 6 i användarhandboken för AEM 6.5.

I det här scenariot kommer tillväxten från noder i Groovy Console-granskningsspår på en användar- och årsanpassad väg, till exempel:

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

Den här sökvägen innehåller endast granskningsdata för Groovy Console-jobb och kan tas bort utan problem. Justera årssegmentet i sökvägen så att det passar din miljö.

Exempel: Groovy Console-skript:

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
}

Kör skriptet en gång i produktionen under ett användarkonto som har behörighet att ta bort noder under /var/groovyconsole/audit/user/<year>. I många miljöer är detta en administrativ användare eller en tjänstanvändare, men de exakta behörigheterna beror på den interna säkerhetsmodellen.

När skriptet har slutförts kontrollerar du i CRXDE Lite att granskningsnoderna har tagits bort och att Groovy Console-jobbet inte längre körs eller körs med ett mindre aggressivt schema och minimalt med loggning.

Steg 3: Schemalägg driftstopp och säkerhetskopiering för offlinekomprimering

Steg 4: Kör offlinerevisionskomprimering på segmentbutiken

Anvisningar om hur du gör detta finns i Revision Cleanup i användarhandboken för AEM 6.5. Använd en oak-run-version som är kompatibel med din servicepaketnivå i AEM 6.5. Se till att det finns minst två gånger så mycket segmentlagringsutrymme tillgängligt som ledigt diskutrymme. Kör följande kommando från AEM installationskatalog på den server där instansen finns:

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

Övervaka processen tills den har slutförts. Avbryt inte komprimeringen. Om du gör det kan databasen skadas.

Steg 5: Starta om AEM och validera

Förebyggande och bästa metoder

Anteckningar