ASO

Letzte Aktualisierung: 12. Juli 2024

Erstellt für:

AEM-System-Überblick

Hintergrund

ASO identifiziert allgemeine Informationen über die AEM-Instanz. Jedes Ergebnis liefert einen Wert eines bestimmten Typs von Systeminformationen.

Um die verschiedenen Arten von Informationen zu erkennen, werden folgende Untertypen verwendet:

aem.version: Die AEM-Version.
aem.product: Erkennung der Verwendung eines AEM-Produkts (Commerce, Forms usw.).
node.count: Die ungefähre Knotenanzahl eines bestimmten Typs (Seite, Asset usw.) und die Gesamtanzahl der Knoten.
node.store: Der Implementierungstyp des Knotenspeichers (SegmentNodeStore, DocumentNodeStore) und seine Größe.
data.store: Der Speicherimplementierungstyp der Daten (FileDataStore, S3DataStore, AzureDataStore).
maintenance.task: Eine Wartungsaufgabe.
slow.query: Eine langsame Abfrage.
group.membership: Die Anzahl der Benutzenden und Untergruppen (nur direkte/deklarierte Mitglieder) in einer Gruppe.
cqtag.count: Die Anzahl der mit CQ-Tags versehenen Assets.
smarttag.count: Die Anzahl der mit Smart-Tags versehenen Assets.
ccom.version: Die Version des Kernkomponenten-Pakets.
instance.type: Der AEM-Instanztyp (author|publish).
unprocessed.asset.count: Die Anzahl der nicht verarbeiteten Assets.
vanity.url.count: Die Anzahl der Vanity-URLs.
index.size: Gesamtgröße des migrierbaren Lucene-Index.
workflow.count: Die Anzahl der laufenden und veralteten Author-Workflows.
jvm.arguments: Die JVM-Argumente, die beim Starten von AEM zur Befehlszeile hinzugefügt wurden.

Die AEM-Version, die Anzahl der Knoten, die Gruppenmitgliedschaft, der Knotenspeicher, die Implementierungstypen des Datenspeichers, die Anzahl der CQ-Tags, die Anzahl der Smart-Tags, die Kernkomponenten-Version, der AEM-Instanztyp und die Zahl der nicht verarbeiteten Assets werden zu Informationszwecken bereitgestellt.
Die höhere Anzahl von Vanity-URLs (>1000) kann den Dispatcher und die Veröffentlichungs-Server mit teuren Abfragen belasten.
Das benutzerdefinierte Programm kann auf Produkte oder Funktionen zurückgreifen, die nicht in AEM as a Cloud Service verfügbar sind.
Ein Upgrade mit nicht unterstützten Funktionen kann zu einem fehlgeschlagenen Upgrade und einem nicht funktionsfähigen Programm führen.
Eine hohe Anzahl von Autoren-Workflows im laufenden oder veralteten Zustand könnte die Leistung beeinträchtigen.
Langsame Abfragen können die Systemleistung beeinträchtigen.

AEM-Upgrades mit nicht unterstützten Produkten oder Funktionen werden nicht empfohlen und möglicherweise nicht unterstützt.
Die unverarbeiteten Assets müssen verarbeitet werden und die Eigenschaft dam:assetState auf dem Knoten jcr:content des Assets muss auf „verarbeitet“ festgelegt werden. Alternativ sollten Sie diese Assets aus dem Migrationssatz entfernen, bevor Sie zu AEMaaCS migrieren.
Vanity-URLs können durch Apache-Neuschreibungen ersetzt werden.
Siehe die Dokumentation zur Fehlerbehebung bei langsamen Abfragen.
Weitere Informationen finden Sie in den Versionshinweisen, wenn Sie mehr über die neuesten Änderungen in AEM as a Cloud Service erfahren möchten.
Wenden Sie sich an unser AEM-Supportteam, um weitere Informationen zu erhalten oder um Anliegen vorzubringen.