Beheben des Segmentspeicherwachstums aufgrund von Groovy Console-Audit-Protokollen in AEM 6.5 (Forms und andere Lösungen)

Wenn Ihre AEM 6.5 On-Premise- oder AMS-Umgebung plötzliche Festplattenspitzen und einen schnell wachsenden TarMK-Segmentspeicher aufweist, kann ein Hochfrequenz-Vorgang mit Groovy Console zur Erstellung großer Audit-Protokoll-Knoten unter /var/groovyconsole/audit führen. Dieses Szenario trat in einer AEM Forms-Umgebung auf, kann jedoch in jedem TarMK-Setup in AEM 6.5 mit Groovy Console auftreten.
In diesem Artikel wird erläutert, wie Sie den fehlerhaften Auftrag identifizieren, seine Überwachungsknoten sicher entfernen und Speicherplatz zurückgewinnen, indem Sie die Offline-Komprimierung auf dem Segmentspeicher ausführen.

Hinweis: Dieses Szenario umfasst benutzerdefinierte Groovy-Konsolenskripte und Audit-Trails. Die Groovy-Konsole ist ein Drittanbieter-/Community-Tool und nicht Teil des standardmäßigen AEM-Produkts.

Beschreibung description

Umgebung

Hinweise:

Problem/Symptome

In einer Adobe Experience Manager (AEM) 6.5 Forms On-Premise- oder Adobe Managed Services (AMS)-Produktionsumgebung steigt die Festplattenauslastung plötzlich und schnell an. Das crx-quickstart/repository/segmentstore-Verzeichnis wächst schnell über mehrere Tage und erreicht Hunderte von Gigabyte. Die Online-Revisionsbereinigung wird ausgeführt, kann jedoch keinen Speicherplatz zurückgewinnen. Keine aktuellen Bereitstellungen oder Konfigurationsänderungen erklären das Wachstum.

Während der Analyse werden die folgenden Symptome beobachtet:

Die Untersuchung zeigt, dass ein benutzerdefinierter Groovy-Konsolenauftrag, der alle paar Minuten ausgeführt werden soll, große Audit-Protokoll-Einträge unter einem benutzer- und jahresspezifischen Pfad wie /var/groovyconsole/audit/user/<year> schreibt. Diese Audit-Knoten verursachen eine Aufblähung des Repositorys und fördern das Wachstum des Segmentspeichers.

Lösung resolution

Schritt 1: Identifizieren Sie den Groovy-Konsolenauftrag, der Audit-Protokolle generiert

Anweisungen hierzu finden Sie Verwenden von CRXDE Lite im AEM as a Cloud Service-Benutzerhandbuch. Ein typischer Auftragsknoten enthält Eigenschaften, die den folgenden ähnlich sind:

Wenn diese Aufträge nur Audit-Protokolle und nicht geschäftskritische Inhalte generieren, können Sie deren Audit-Knoten sicher bereinigen und den Zeitplan anpassen oder entfernen, um ein weiteres schnelles Wachstum zu verhindern. Anweisungen hierzu finden Sie unter Auditprotokollwartung in AEM 6.

Schritt 2: Groovy Console-Überwachungsknoten bereinigen

Um die Größe des Repositorys zu reduzieren, entfernen Sie die kumulierten Auditknoten unter /var/groovyconsole/audit/user/<year>. Verwenden Sie ein On-Demand-Skript für Groovy-Konsole anstelle eines neuen geplanten Auftrags, um weiteres Wachstum zu vermeiden.

Wichtig: Groovy-Konsole mit Vorsicht auf Produktionssystemen verwenden. Testen Sie Skripte immer zuerst in einer niedrigeren Umgebung, überprüfen Sie den Zielpfad und führen Sie sie unter den entsprechenden Änderungsverwaltungsverfahren aus. Anweisungen hierzu finden Sie unter Auditprotokollwartung in AEM 6 im Benutzerhandbuch zu AEM 6.5.

In diesem Szenario stammt das Wachstum von Audit-Protokoll-Knoten in Groovy Console unter einem benutzer- und jahresspezifischen Pfad, z. B.:

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

Dieser Pfad enthält nur Auditdaten für die Groovy-Konsolenaufträge und kann problemlos entfernt werden. Passen Sie das Jahressegment im Pfad an Ihre Umgebung an.

Beispiel für Groovy-Konsolenskript:

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
}

Führen Sie das Skript einmal in der Produktion unter einem Benutzerkonto aus, das über ausreichende Berechtigungen zum Entfernen von Knoten unter /var/groovyconsole/audit/user/<year> verfügt. In vielen Umgebungen handelt es sich um einen administrativen oder Service-Benutzer. Die genauen Berechtigungen hängen jedoch von Ihrem internen Sicherheitsmodell ab.

Überprüfen Sie nach Abschluss des Skripts in CRXDE Lite, ob die Überwachungsknoten entfernt wurden, und vergewissern Sie sich, dass der Vorgang „Groovy Console“ nicht mehr ausgeführt wird oder mit einem weniger aggressiven Zeitplan und minimaler Protokollierung ausgeführt wird.

Schritt 3: Planen Sie Ausfallzeiten und Backups für die Offline-Komprimierung

Schritt 4: Führen Sie die Offline-Revisionskomprimierung auf dem Segmentspeicher aus

Anweisungen hierzu finden Sie unter Revisionsbereinigung im Benutzerhandbuch zu AEM 6.5. Verwenden Sie eine oak-run Version, die mit Ihrem AEM 6.5 Service Pack kompatibel ist. Stellen Sie sicher, dass mindestens das Doppelte der aktuellen Segmentspeichergröße als freier Speicherplatz verfügbar ist. Führen Sie den folgenden Befehl aus dem AEM-Installationsverzeichnis auf dem Server aus, auf dem die Instanz gehostet wird:

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

Überwachen Sie den Prozess, bis er erfolgreich abgeschlossen wird. Komprimierung nicht unterbrechen. Dies kann das Repository beschädigen.

Schritt 5: AEM neu starten und validieren

Prävention und Best Practices

Anmerkungen