Mit dem Vorgangs-Dashboard in AEM 6 können Systemoperatoren auf einen Blick die AEM-Systemkonsistenz berwachen. Es bietet außerdem automatisch generierte Diagnoseinformationen zu relevanten Aspekten der AEM und ermöglicht die Konfiguration und Ausführung der selbstständigen Wartungsautomatisierung, um den Projektbetrieb und die Unterstützungsfälle erheblich zu reduzieren. Sie können das Vorgangs-Dashboard durch benutzerdefinierte Konsistenzprüfungen und Wartungsaufgaben erweitern. Und über JMX können Sie von externen Überwachungstools auf die Daten des Vorgangs-Dashboards zugreifen.
Das Vorgangs-Dashboard:
Sie können auf das Tool zugreifen, indem Sie im AEM Begrüßungsbildschirm zu Tools - Vorgänge wechseln.
Um auf das Vorgangs-Dashboard zugreifen zu können, muss der angemeldete Benutzer zur Benutzergruppe „Operatoren“ gehören. Weitere Informationen finden Sie in der Dokumentation zu Verwaltung von Benutzern, Gruppen und Zugriffsrechten.
Das Konsistenzberichtssystem stellt Informationen zum Zustand einer AEM-Instanz durch Sling-Konsistenzprüfungen bereit. Dies erfolgt entweder über OSGi-, JMX- oder HTTP-Abfragen (über JSON) oder über die Touch-optimierte Benutzeroberfläche. Das System bietet Messungen und Schwellenwerte bestimmter konfigurierbarer Zähler und stellt in einigen Fällen Informationen zur Fehlerbehebung bereit.
Es umfasst mehrere Funktionen, die unten beschrieben werden.
Die Konsistenzberichte sind ein System von Karten, die einen guten oder einen schlechten Zustand im Hinblick auf einen bestimmten Produktbereich anzeigen. Diese Karten sind Visualisierungen der Sling-Konsistenzprüfung, die Daten von JMX und anderen Quellen aggregiert und verarbeitete Daten wieder als MBeans freigibt. Diese MBeans können Sie auch in der JMX-Web-Konsole unter der Domäne org.apache.sling.healthcheck überprüfen.
Auf die Benutzeroberfläche der Gesundheitsberichte können Sie über das Menü Tools - Vorgänge - Gesundheitsberichte auf dem AEM Begrüßungsbildschirm oder direkt über die folgende URL zugreifen:
https://<serveraddress>:port/libs/granite/operations/content/healthreports/healthreportlist.html
Das Kartensystem umfasst drei mögliche Status: OK, WARNUNG und KRITISCH. Diese Statusanzeigen sind das Ergebnis von Regeln und Schwellenwerten. Um diese zu konfigurieren, bewegen Sie den Mauszeiger über die Karte und klicken Sie auf das Zahnradsymbol in der Aktionsleiste:
Es gibt zwei Arten von Konsistenzprüfungen in AEMٔ 6:
Eine individuelle Konsistenzprüfung ist eine einzelne Konsistenzprüfung, die einer Statuskarte entspricht. Individuelle Konsistenzprüfungen können mit Regeln oder Schwellenwerten konfiguriert werden und einen oder mehrere Hinweise und Links zum Beheben erkannter Konsistenzprobleme bereitstellen. Nehmen wir die Prüfung „Fehlerprotokoll“ als Beispiel: Wenn in den Instanzenprotokollen FEHLER-Einträge vorliegen, werden sie auf der Detailseite der Konsistenzprüfung angezeigt. Oben auf der Seite finden Sie einen Link zum Protokollmeldungs-Analyzer im Diagnosetools-Bereich. Damit können Sie diese Fehler detailliert analysieren und die Logger neu konfigurieren.
Eine Verbund-Konsistenzprüfung ist eine Prüfung, die Daten von mehreren individuellen Prüfungen zusammenführt.
Verbund-Konsistenzprüfungen können Sie mit Hilfe von Filter-Tags konfigurieren. Im Wesentlichen werden alle einzelnen Prüfungen, die dasselbe Filter-Tag aufweisen, als Verbund-Konsistenzprüfung gruppiert. Eine Verbund-Konsistenzprüfung weist nur dann den Status „OK“ auf, wenn alle individuellen Prüfungen, von denen sie Daten bezieht, ebenfalls diesen Status aufweisen.
Im Vorgangs-Dashboard können Sie die Ergebnisse von individuellen wie Verbund-Konsistenzprüfung visuell darstellen.
Zum Erstellen einer individuellen Konsistenzprüfung sind zwei Schritte nötig: das Implementieren einer Sling-Konsistenzprüfung und das Hinzufügen eines Eintrags für die Konsistenzprüfung in den Konfigurationsknoten des Dashboards.
Um eine Sling-Konsistenzprüfung zu erstellen, müssen Sie eine OSGi-Komponente erstellen, die die Sling-Konsistenzprüfungs-Schnittstelle implementiert. Sie fügen diese Komponente innerhalb eines Bundles hinzu. Die Eigenschaften der Komponente identifizieren die Konsistenzprüfung vollständig. Nach der Installation der Komponente wird automatisch ein JMX-MBean für die Konsistenzprüfung erstellt. Weitere Informationen finden Sie in der Dokumentation zu Sling-Konsistenzprüfungen.
Beispiels einer Sling-Konsistenzprüfungs-Komponente, mit OSGi-Dienstkomponenten-Anmerkungen geschrieben:
@Component(service = HealthCheck.class,
property = {
HealthCheck.NAME + "=Example Check",
HealthCheck.TAGS + "=example",
HealthCheck.TAGS + "=test",
HealthCheck.MBEAN_NAME + "=exampleHealthCheckMBean"
})
public class ExampleHealthCheck implements HealthCheck {
@Override
public Result execute() {
// health check code
}
}
Die Eigenschaft MBEAN_NAME
definiert den Namen des MBean, die für diese Konsistenzprüfung erstellt wird.
Nach dem Erstellen der Konsistenzprüfung müssen Sie einen neuen Konfigurationsknoten erstellen, damit die Konsistenzprüfung in der Oberfläche des Vorgangs-Dashboards verfügbar ist. Für diesen Schritt müssen Sie den JMX-MBean-Namen der Konsistenzprüfung kennen (die Eigenschaft MBEAN_NAME
). Um eine Konfiguration für die Konsistenzprüfung zu erstellen, öffnen Sie CRXDE und fügen Sie einen neuen Knoten (des Typs nt:unstructured) unter dem folgenden Pfad hinzu: /apps/settings/granite/operations/hc
Legen Sie die folgenden Eigenschaften für den neuen Knoten fest:
Name: sling:resourceType
String
granite/operations/components/mbean
Name: resource
String
/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/exampleHealthCheck
Der Ressourcenpfad oben wird wie folgt erstellt: Wenn der mbean-Name Ihres Health Check "test"lautet, fügen Sie am Ende des Pfads /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck
"test"hinzu
Der endgültige Pfad lautet also:
/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/test
Stellen Sie sicher, dass für den Pfad /apps/settings/granite/operations/hc
die folgenden Eigenschaften auf "true"festgelegt sind:
sling:configCollectionInherit
sling:configPropertyInherit
Dadurch wird der Configuration Manager angewiesen, die neuen Konfigurationen mit den vorhandenen von /libs
zusammenzuführen.
Die Aufgabe einer Verbund-Konsistenzprüfung besteht darin, mehrere individuelle Konsistenzprüfung zu aggregieren, die einige Funktionen gemeinsam nutzen. So gruppiert beispielsweise die Sicherheits-Verbund-Konsistenzprüfung alle individuellen Konsistenzprüfung, die sicherheitsbezogene Prüfungen durchführen. Um eine Verbund-Zustandsprüfung zu erstellen, müssen Sie zunächst eine neue OSGi-Konfiguration hinzufügen. Für die Anzeige im Vorgangs-Dashboard müssen Sie einen neuen Konfigurationsknoten hinzufügen, wie für die einfache Prüfung beschrieben.
Wechseln Sie zum Web-Konfigurationsmanager in der OSGi-Konsole. Sie können dazu auf https://serveraddress:port/system/console/configMgr
zugreifen
Suchen Sie den Eintrag namens Apache Sling Composite Health Check. Unter diesem Eintrag sind bereits zwei Konfigurationen vorhanden: eine für die Systemprüfungen, eine andere für die Sicherheitsprüfungen.
Um eine neue Konfiguration zu erstellen, klicken Sie auf das Pluszeichen (+) rechts neben der Konfiguration. Ein neues Fenster wird geöffnet, wie unten abgebildet:
Erstellen Sie eine Konfiguration und speichern Sie sie. Ein MBean wird mit der neuen Konfiguration erstellt.
Der Zweck jeder Konfigurationseigenschaft ist wie folgt:
hc.tags
).Ein neues JMX-MBean wird für jede neue Konfiguration des Apache Sling Composite Health Checks erstellt.**
Zuletzt müssen Sie den Eintrag der gerade erstellten Verbund-Konsistenzprüfung in den Konfigurationsknoten des Vorgangs-Dashboards hinzufügen. Das Verfahren hierfür ist dasselbe wie bei den einzelnen Gesundheitskontrollen: Eine Node des Typs nt:unstructured muss unter /apps/settings/granite/operations/hc
erstellt werden. Die Ressourceneigenschaft des Knotens wird durch den Wert hc.mean.name in der OSGi-Konfiguration definiert.
Wenn Sie beispielsweise eine Konfiguration erstellt und den Wert hc.mbean.name auf diskusage festgelegt haben, sehen die Konfigurationsknoten wie folgt aus:
Name: Composite Health Check
nt:unstructured
Mit den folgenden Eigenschaften:
Name: sling:resourceType
String
granite/operations/components/mbean
Name: resource
String
/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/diskusage
Wenn Sie individuelle Konsistenzprüfungen erstellen, die logisch zu einer Verbund-Konsistenzprüfung gehören, die bereits standardmäßig im Dashboard vorhanden ist, werden sie automatisch erfasst und unter der entsprechenden Verbund-Konsistenzprüfung gruppiert. Daher müssen Sie keinen neuen Konfigurationsknoten für diese Prüfungen erstellen.
Wenn Sie beispielsweise eine individuelle Sicherheits-Konsistenzprüfung erstellen, müssen Sie ihr lediglich das Tag Sicherheit zuweisen. Nach der Installation wird sie automatisch unter der Verbund-Konsistenzprüfung im Vorgangs-Dashboard angezeigt.
Name der Konsistenzprüfung | Beschreibung |
Abfrageleistung | Dieser Gesundheitscheck wurde in AEM 6.4 vereinfacht und überprüft nun das kürzlich umgestaltete Die MBean für diese Gesundheitsprüfung ist org.apache.sling.healthcheck:name=queryStatus,type=HealthCheck. |
Länge der Überwachungswarteschlange | Die Länge der Beobachtungswarteschlange iteriert alle Listener und Hintergrundbeobachter, vergleicht ihre
Die Höchstlänge jeder Warteschlange wird in separaten Konfigurationen (Oak und AEM) festgelegt und kann nicht über diese Konsistenzprüfung konfiguriert werden. Die MBean für diese Gesundheitsprüfung ist org.apache.sling.healthcheck:name=ObservationQueueLengthHealthCheck,type=HealthCheck. |
Abfrage-Ausnahmelimits | Abfrage Traversal Limits prüft die
Die Mbean für diese Gesundheitsprüfung ist org.apache.sling.healthcheck:name=queryTraversalLimitsBundle,type=HealthCheck. |
Synchronisierte Uhren | Diese Prüfung ist nur für Dokument nodestore-Cluster relevant. Sie gibt den folgenden Status zurück:
Die Mbean für diese Gesundheitsprüfung ist org.apache.sling.healthcheck:name=slingDiscoveryOakSynchronizedClocks,type=HealthCheck. |
Asynchrone Indexizes | Die Prüfung auf asynchrone Indizes
Die Schwellenwerte für „Kritisch“ und „Warnung“ sind konfigurierbar. Die Mbean für diese Gesundheitsprüfung ist org.apache.sling.healthcheck:name=asyncIndexHealthCheck,type=HealthCheck. Hinweis: Dieser Health Check ist ab AEM 6.4 verfügbar und wurde auf AEM 6.3.0.1 zurückportiert. |
Große Lucene-Indizes | Diese Prüfung verwendet die von der MBean offen gelegten Daten, um große Indizes und Rückgaben zu identifizieren:
Die Schwellenwerte sind konfigurierbar und die MBean für die Gesundheitsprüfung ist org.apache.sling.healthcheck:name=largeIndexHealthCheck,type=HealthCheck. Hinweis: Diese Prüfung ist in AEM 6.4 und als Backport in AEM 6.3.2.0 verfügbar. |
Systemwartung | Die Systemwartung ist eine Verbund-Zustandsprüfung, die den Status „OK“ zurückgibt, wenn alle Wartungsaufgaben wie konfiguriert ausgeführt werden. Bedenken Sie Folgendes:
Die MBean für diese Gesundheitsprüfung ist org.apache.sling.healthcheck:name=systemcheck,type=HealthCheck. |
Replikations-Warteschlange | Diese Prüfung wird bei den Replikationsagenten durchgeführt und prüft deren Warteschlangen. Beim vordersten Element in der Warteschlange ermittelt die Prüfung, wie häufig der Agent die Replikation versucht hat. Wenn diese Anzahl größer ist als der Wert des Parameters Die MBean für diese Gesundheitsprüfung ist org.apache.sling.healthcheck:name=ReplicationQueue,type=HealthCheck. |
Sling-Aufträge |
Sling-Aufträge prüfen die Anzahl der in die Warteschlange im JobManager gestellten Aufträge im Vergleich mit der
maxNumQueueJobs -Schwellenwert und:
Nur der Parameter für die Höchstzahl an Aufträgen in der Warteschlange ist konfigurierbar. Sein Standardwert ist 1.000. Die MBean für diese Gesundheitsprüfung ist org.apache.sling.healthcheck:name=slingJobs,type=HealthCheck. |
Anforderungsleistung | Diese Prüfung untersucht die
Die MBean für diese Gesundheitsprüfung lautet org.apache.sling.healthcheck:name=requestStatus,type=HealthCheck. |
Fehlerprotokoll | Diese Prüfung gibt eine Warnung zurück, wenn Fehler im Protokoll vorliegen. Die MBean für diese Gesundheitsprüfung ist org.apache.sling.healthcheck:name=logErrorHealthCheck,type=HealthCheck. |
Festplattenspeicher | Bei der Überprüfung des Festplattenspeicherplatzes werden die MBean, die Größe des Node Store und der auf der Node Store-Partition verfügbare Speicherplatz abgerufen und:
Beide Werte sind konfigurierbar. Die Prüfung funktioniert nur auf Instanzen mit einem Segmentspeicher. Die MBean für diese Gesundheitsprüfung ist org.apache.sling.healthcheck:name=DiskSpaceHealthCheck,type=HealthCheck. |
Scheduler-Konsistenzprüfung | Diese Prüfung gibt eine Warnung zurück, wenn auf der Instanz länger als 60 Sekunden ein Quartz-Auftrag ausgeführt wird. Der Schwellenwert für die zulässige Dauer ist konfigurierbar. Die MBean für diese Gesundheitsprüfung ist org.apache.sling.healthcheck:name=slingCommonsSchedulerHealthCheck,type=HealthCheck. |
Sicherheitsprüfungen | Die Sicherheitsprüfung ist eine Verbundprüfung, die die Ergebnisse mehrerer sicherheitsbezogener Prüfungen aggregiert. Diese individuellen Gesundheitsüberprüfungen behandeln verschiedene Bedenken aus der Sicherheitsprüfliste auf der Seite Sicherheitscheckliste. Die Prüfung ist als Feuerprobe beim Start der Instanz nützlich. Die MBean für diese Gesundheitsprüfung ist org.apache.sling.healthcheck:name=securityChecks,type=HealthCheck |
Aktive Bundles | Diese Prüfung untersucht den Status aller Bundles und:
Der Parameter der Ignorieren-Liste ist konfigurierbar. Die MBean für diese Gesundheitsprüfung ist org.apache.sling.healthcheck:name=inactiveBundles,type=HealthCheck. |
Code-Cache-Prüfung | Diese Konsistenzprüfung überprüft mehrere JVM-Bedingungen, die einen Code-Cache-Bug in Java 7 auslösen können, und:
Der Schwellenwert Das MBean für diese Konsistenzprüfung ist org.apache.sling.healthcheck:name=codeCacheHealthCheck,type=HealthCheck. |
Ressourcen-Suchpfad-Fehler | Prüft, ob Ressourcen im Pfad
Das MBean für diese Konsistenzprüfung ist org.apache.sling.healthcheck:name=resourceSearchPathErrorHealthCheck,type=HealthCheck. |
Das Konsistenzprüfungs-Dashboard ist über die Granite JMX-MBeans mit Nagios integrierbar. Das nachfolgende Beispiel zeigt, wie Sie eine Prüfung hinzufügen, die verwendeten Speicher auf dem Server anzeigt, auf dem AEM ausgeführt wird.
Installieren und konfigurieren Sie Nagios auf dem Überwachungsserver.
Installieren Sie anschließend den Nagios Remote Plugin Executor (NRPE).
Informationen zur Installation von Nagios und NRPE auf Ihrem System finden Sie in der Nagios-Dokumentation.
Fügen Sie eine Hostdefinition hinzu. Dies ist mit dem Konfigurationsmanager der Nagios XI-Weboberfläche möglich:
Nachfolgend finden Sie ein Beispiel einer Host-Konfigurationsdatei unter Verwendung von Nagios Core:
define host {
address 192.168.0.5
max_check_attempts 3
check_period 24x7
check-command check-host-alive
contacts admin
notification_interval 60
notification_period 24x7
}
Installieren Sie Nagios und NRPE auf dem AEM-Server.
Installieren Sie das Plug-in check_http_json auf beiden Servern.
Definieren Sie einen generischen JSON-Prüfbefehl auf beiden Servern:
define command{
command_name check_http_json-int
command_line /usr/lib/nagios/plugins/check_http_json --user "$ARG1$" --pass "$ARG2$" -u 'https://$HOSTNAME$:$ARG3$/$ARG4$' -e '$ARG5$' -w '$ARG6$' -c '$ARG7$'
}
Fügen Sie einen Dienst für verwendeten Speicher auf dem AEM-Server hinzu:
define service {
use generic-service
host_name my.remote.host
service_description AEM Author Used Memory
check_command check_http_json-int!<cq-user>!<cq-password>!<cq-port>!system/sling/monitoring/mbeans/java/lang/Memory.infinity.json!{noname}.mbean:attributes.HeapMemoryUsage.mbean:attributes.used.mbean:value!<warn-threshold-in-bytes>!<critical-threshold-in-bytes>
}
Überprüfen Sie, ob das Nagios-Dashboard den neu erstellten Dienst anzeigt:
Das Vorgangs-Dashboard bietet auch Zugriff auf Diagnosetools, mit denen Sie die Ursachen der Warnmeldungen vom Konsistenzprüfungs-Dashboard ermitteln und beheben können. Systemoperatoren finden hier außerdem wichtige Debugging-Informationen.
Zu den wichtigsten Funktionen gehören:
Auf den Bildschirm „Diagnose-Tools“ können Sie über den AEM-Begrüßungsbildschirm über Tools > Vorgänge > Diagnose zugreifen. Sie können auch direkt auf den Bildschirm zugreifen, indem Sie auf die folgende URL zugreifen: https://serveraddress:port/libs/granite/operations/content/diagnosis.html
Die Protokollmeldungs-Benutzeroberfläche zeigt standardmäßig alle FEHLER-Meldungen an. Wenn Sie mehr Protokollmeldungen anzeigen möchten, müssen Sie einen Logger mit der entsprechenden Protokollebene konfigurieren.
Die Protokollmeldungen nutzen einen In-Memory-Protokoll-Appender und hängen daher nicht mit den Protokolldateien zusammen. Eine weitere Konsequenz ist, dass Änderungen an den Protokollebenen in dieser Benutzeroberfläche die Informationen, die in den klassischen Protokolldateien aufgezeichnet werden, nicht ändern. Das Hinzufügen und Entfernen von Loggern wirkt sich nur auf den In-Memory-Logger aus. Beachten Sie außerdem, dass Änderungen der Logger-Konfigurationen in der Zukunft in den In-Memory-Loggern widergespiegelt werden. Die Einträge, die bereits protokolliert und nicht mehr relevant sind, werden nicht gelöscht, aber ähnliche Einträge werden zukünftig nicht protokolliert.
Was protokolliert wird, können Sie konfigurieren, indem Sie über die Zahnrad-Schaltfläche oben links in der Benutzeroberfläche Logger-Konfigurationen angeben. Hier können Sie Logger-Konfigurationen hinzufügen, entfernen oder aktualisieren. Eine Logger-Konfiguration besteht aus einer Protokollebene (WARNUNG/INFO/DEBUGGING) und einem Filternamen. Der Filtername filtert die Quelle der protokollierten Protokollmeldungen. Wenn ein Logger alle Protokollmeldungen für eine festgelegte Ebene erfassen soll, wählen Sie alternativ als Filtername root aus. Das Festlegen der Ebene eines Loggers löst die Erfassung aller Meldungen der festgelegten Ebene oder höher aus.
Beispiele:
Wenn Sie alle FEHLER-Meldungen erfassen möchten, ist keine Konfiguration erforderlich. Alle FEHLER-Meldungen werden standardmäßig erfasst.
Wenn Sie alle FEHLER-, WARNUNG- und INFO-Meldungen erfassen möchten, legen Sie den Logger-Namen auf root und die Loggerebene auf INFO fest.
Wenn Sie alle Meldungen von einem bestimmten Paket (z. B. com.adobe.granite) erfassen möchten, legen Sie den Logger-Namen auf „com.adobe.granite“ fest und die Logger-Ebene auf DEBUGGING (dadurch werden alle FEHLER-, WARNUNG-, INFO- und DEBUGGING-Meldungen erfasst), wie in nachfolgender Grafik abgebildet.
Sie können einen Logger-Namen nicht so festlegen, dass er nur FEHLER-Meldungen über einen festgelegten Filter erfasst. Standardmäßig werden alle FEHLER-Meldungen erfasst.
Die Protokollmeldungs-Benutzeroberfläche spiegelt nicht das tatsächliche Fehlerprotokoll wider. Sofern Sie keinen anderen Typen an Protokollmeldungen in der Benutzeroberfläche konfigurieren, werden nur FEHLER-Meldungen angezeigt. Anleitungen zum Anzeigen bestimmter Protokollmeldungen finden Sie oben.
Die Einstellungen auf der Diagnoseseite wirken sich nicht darauf aus, was in den Protokolldateien protokolliert wird, und umgekehrt. Wenn das Fehlerprotokoll also INFO-Meldungen erfasst, werden sie möglicherweise nicht in der Protokollmeldungs-Benutzeroberfläche angezeigt. Über die Benutzeroberfläche ist es auch möglich, DEBUGGING-Meldungen von bestimmten Paketen zu erfassen, ohne das Fehlerprotokoll zu beeinflussen. Weitere Informationen zum Konfigurieren der Protokolldateien finden Sie unter Protokollierung.
Mit AEM 6.4 werden Aufgaben für die Wartung auf INFO-Ebene in einem detaillierteren Format abgemeldet. Dieser Ansatz ermöglicht bessere Einblicke in den Status der Wartungsaufgaben.
Wenn Sie Drittanbietertools (wie Splunk) verwenden, um die Wartungsaufgaben-Aktivität zu überwachen und darauf zu reagieren, können Sie die folgenden Protokollanweisungen nutzen:
Log level: INFO
DATE+TIME [MaintanceLogger] Name=<MT_NAME>, Status=<MT_STATUS>, Time=<MT_TIME>, Error=<MT_ERROR>, Details=<MT_DETAILS>
Die Anforderungsleistungsseite ermöglicht die Analyse der langsamsten verarbeiteten Seitenabfragen. Nur Inhaltsabfragen werden auf dieser Seite registriert. Genauer gesagt, werden die folgenden Abfragen erfasst:
/content
/etc/design
".html"
Die Seite zeigt Folgendes an:
Standardmäßig werden die langsamsten 20 Seitenabfragen erfasst. Diesen Wert können Sie aber im Konfigurationsmanager ändern.
Die Abfrageleistungsseite ermöglicht die Analyse der langsamsten vom System durchgeführten Abfragen. Diese Informationen werden vom Repository in einem JMX-MBean bereitgestellt. In Jackrabbit stellt das JMX-MBean com.adobe.granite.QueryStat
diese Daten bereit, im Oak-Repository werden sie von org.apache.jackrabbit.oak.QueryStats.
geliefert.
Die Seite zeigt Folgendes an:
Bei jeder Abfrage versucht Oak, die beste Ausführungsmethode zu ermitteln, basierend auf den Oak-Indizes, die im Repository unter dem Knoten oak-index definiert sind. Je nach Abfrage kann Oak verschiedene Indizes auswählen. Der erste Schritt für die Abfrageoptimierung besteht darin, zu verstehen, wie Oak eine Abfrage ausführt.
„Abfrage erläutern“ ist ein Tool, das erklärt, wie Oak eine Abfrage ausführt. Um auf das Tool zuzugreifen, klicken Sie auf dem AEM-Begrüßungsbildschirm unter Tools > Vorgänge > Diagnose auf Abfrageleistung. Wechseln Sie dann zur Registerkarte Abfrage erläutern.
Funktionen
In der Benutzeroberfläche von „Abfrage erläutern“ müssen Sie einfach nur die Abfrage eingeben und auf die Schaltfläche Erläutern klicken:
Der erste Eintrag im Bereich „Abfrage-Erläuterung“ ist die eigentliche Erklärung. Diese Erklärung gibt den Indextyp an, der zur Ausführung der Abfrage genutzt wurde.
Der zweite Eintrag ist der Ausführungsplan.
Wenn Sie vor dem Ausführen der Abfrage das Kontrollkästchen Ausführungsdauer einschließen aktivieren, wird auch die Zeitdauer angezeigt, in der die Abfrage ausgeführt wurde. So erhalten Sie mehr Informationen, die Sie zur Optimierung der Indizes für Ihre Anwendung oder Bereitstellung nutzen können.
Der Index-Manager soll die Indexverwaltung vereinfachen, beispielsweise die Pflege der Indizes oder die Statusanzeige.
Sie können auf die Datei zugreifen, indem Sie im Begrüßungsbildschirm auf Tools - Vorgänge - Diagnose klicken und dann auf die Schaltfläche Index-Manager klicken.
Sie kann auch direkt unter folgender URL aufgerufen werden: https://serveraddress:port/libs/granite/operations/content/diagnosistools/indexManager.html
Über die Benutzeroberfläche können Sie Indizes filtern. Geben Sie dazu die Filterkriterien in das Suchfeld in der linken oberen Ecke des Bildschirms ein.
Dies löst den Download einer ZIP-Datei aus, die nützliche Informationen zum Systemstatus und zur Systemkonfiguration enthält. Das Archiv enthält Instanzkonfigurationen, eine Liste von Bundles, OSGI, Sling-Metriken und Statistiken, was zu einer großen Datei führen kann. Sie können den Einfluss großer Statusdateien verringern, indem Sie das Fenster Download-Status-ZIP verwenden. Das Fenster kann von folgenden Adressen aufgerufen werden: AEM > Werkzeuge > Vorgänge > Diagnose > ZIP-Download-Status.
In diesem Fenster können Sie auswählen, was exportiert werden soll (Protokolldateien oder andere Thread-Sicherheitskopien) und wie viele Tage von Protokollen im Download im Verhältnis zum aktuellen Datum enthalten sein sollen.
Dies löst den Download einer ZIP-Datei aus, die Informationen zu den Threads enthält, die im System vorhanden sind. Es werden Daten zu jedem Thread bereitgestellt, z. B. zum Status, Classloader und Stacktrace.
Sie können auch eine Momentaufnahme des Heaps herunterladen, um ihn zu einem späteren Zeitpunkt besser analysieren zu können. Beachten Sie, dass dadurch der Download einer großen Datei ausgelöst wird, die mehrere hundert MB umfassen kann.
Auf der Seite „Automatisierte Wartungsaufgaben“ können Sie empfohlene Wartungsaufgaben, für die die regelmäßige Ausführung geplant ist, anzeigen und nachverfolgen. Die Aufgaben sind im Konsistenzprüfungssystem integriert. Sie können die Aufgaben auch manuell über die Benutzeroberfläche ausführen.
Um die Wartungsseite im Vorgangs-Dashboard aufzurufen, gehen Sie auf dem AEM-Begrüßungsbildschirm zu Tools > Vorgänge > Dashboard > Wartung oder nutzen Sie den folgenden Link:
https://serveraddress:port/libs/granite/operations/content/maintenance.html
Die folgenden Aufgaben sind im Vorgangs-Dashboard verfügbar:
Die Aufgabe Überarbeitungsbereinigung unter dem Menü Tägliches Wartungsfenster.
Die Aufgabe Lucene Binaries Cleanup unter dem Menü Daily Maintenance Window.
Die Aufgabe Workflow bereinigen unter dem Menü Wöchentliches Wartungsfenster.
Die Aufgabe Datenerfassungs-Garbage Collection befindet sich im Menü Wöchentliches Wartungsfenster.
Die Aufgabe Audit Log Maintenance befindet sich im Menü Weekly Maintenance Window.
Die Aufgabe Versionsbereinigung befindet sich im Menü Wöchentliches Wartungsfenster.
Die Standardzeit für das tägliche Wartungsfenster ist 02:00 bis 05:00 Uhr. Die Aufgaben, die für das Zeitfenster der wöchentlichen Wartung konfiguriert sind, werden an Samstagen zwischen 01:00 und 02:00 Uhr ausgeführt.
Sie können diese Zeiten auch konfigurieren. Klicken Sie dazu auf das Zahnradsymbol auf einer der beiden Wartungskarten:
Seit AEM 6.1 können Sie die vorhandenen Wartungsfenster auch für die monatliche Ausführung konfigurieren.
Weitere Informationen zur Durchführung der Revisionsbereinigung in AEM 6.4 finden Sie in diesem speziellen Artikel.
Mit dieser Aufgabe können Sie Lucene-Binärdateien bereinigen und die Anforderungen an die Größe des ausgeführten Datenspeichers verringern. Der Grund dafür ist, dass der binäre Wurf des Lucens täglich anstelle der früheren Abhängigkeit von einer erfolgreichen Ausführung von Datenspeicher-Garbage Collection erneut angefordert wird.
Zwar wurde die Wartungsaufgabe entwickelt, um Lucene-Revisions-Garbage zu verringern, aber ihre Ausführung verbessert auch allgemein die Effizienz:
Sie können auf die Aufgabe "Bereinigung der Lucene-Binärdateien"zugreifen: AEM > Extras > Vorgänge > Wartung > Tägliches Wartungsfenster > Aufräumen von Lucene-Binärdateien.
Detaillierte Informationen zur Datenspeicherbereinigung finden Sie auf der entsprechenden Dokumentationsseite.
Sie können Workflows auch über das Wartungs-Dashboard bereinigen. Führen Sie dazu folgende Schritte durch:
Weitere Informationen zur Workflow-Wartung finden Sie auf dieser Seite.
Informationen zur Auditprotokoll-Wartung finden Sie auf der entsprechenden Dokumentationsseite.
Sie können die Wartungsaufgabe zur Versionsbereinigung planen, um alte Versionen automatisch zu löschen. Dadurch wird die manuelle Verwendung der Werkzeuge zur Versionsbereinigung minimiert. Sie können die Aufgabe zur Versionsbereinigung planen und konfigurieren, indem Sie auf Tools > Vorgänge > Wartung > Wöchentliches Wartungsfenster zugreifen und folgende Schritte ausführen:
Klicken Sie auf die Schaltfläche Hinzufügen.
Wählen Sie Version Purge aus dem Dropdown-Menü.
Klicken Sie zum Konfigurieren der Aufgabe zur Versionsbereinigung auf das Symbol Getriebe auf der neu erstellten Versionsbereinigungskarte.
In AEM 6.4 können Sie die Versionsbereinigung wie folgt anhalten:
Das Anhalten der Wartungsaufgabe bedeutet, dass ihre Ausführung verschoben wird, ohne den Überblick über den aktuell bereits ausgeführten Auftrag zu verlieren.
Um die Größe des Repositorys zu optimieren, sollten Sie die Aufgabe zur Versionsbereinigung regelmäßig ausführen. Die Aufgabe sollte außerhalb der Geschäftszeiten geplant werden, wenn der Netzwerkverkehr begrenzt ist.
Sie können benutzerdefinierte Wartungsaufgaben als OSGi-Dienste implementieren. Da die Infrastruktur der Wartungsaufgaben auf der Auftragsverarbeitung von Apache Sling basiert, muss eine Wartungsaufgabe die Java-Schnittstelle [org.apache.sling.event.jobs.consumer.JobExecutor](https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/consumer/JobExecutor.html)
implementieren. Um als Wartungsaufgabe erkannt zu werden, muss sie zusätzlich mehrere Dienstregistrierungseigenschaften festlegen, wie nachfolgend aufgeführt:
Diensteigenschaftsname |
Beschreibung | Beispiel |
Typ |
granite.maintenance.isStoppable | Boolesches Attribut, das definiert, ob die Aufgabe vom Benutzer gestoppt werden kann. Wenn eine Aufgabe festlegt, dass sie angehalten werden kann, muss sie während ihrer Ausführung prüfen, ob sie angehalten wurde, und dann entsprechend agieren. Der Standard lautet „false“. | true | Optional |
granite.maintenance.mandatory | Boolesches Attribut, das definiert, ob eine Aufgabe obligatorisch ist und regelmäßig ausgeführt werden muss. Wenn eine Aufgabe verpflichtend ist, sich aber aktuell in keinem aktiven Planungsfenster befindet, meldet eine Konsistenzprüfung dies als Fehler. Der Standard lautet „false“. | true | optional |
granite.maintenance.name | Ein eindeutiger Name für die Aufgabe - dieser wird verwendet, um auf die Aufgabe zu verweisen. Dabei handelt es sich in der Regel um einen einfachen Namen. | MyMaintenanceTask | Erforderlich |
granite.maintenance.title | Ein Titel, der für diese Aufgabe angezeigt wird | Meine besondere Aufgabe für die Wartung | Erforderlich |
job.topics | Dies ist ein einzigartiges Thema der Wartungs-Aufgabe. Die Apache Sling-Auftragsverarbeitung startet einen Auftrag mit genau diesem Thema, um die Wartungsaufgabe auszuführen, und wenn die Aufgabe für dieses Thema registriert wird, wird sie ausgeführt. Das Thema muss mit com/adobe/granite/maintenance/job/ Beginn werden |
com/adobe/granite/maintenance/job/MyMaintenanceTask | Erforderlich |
Neben den oben genannten Diensteigenschaften muss die process()
-Methode der JobConsumer
-Schnittstelle implementiert werden, indem der Code hinzugefügt wird, der für die Maintenance-Aufgabe ausgeführt werden soll. Mit dem bereitgestellten JobExecutionContext
können Sie Statusinformationen ausgeben, prüfen, ob der Auftrag vom Benutzer angehalten wurde, und ein Ergebnis erstellen (Erfolg oder Fehler).
In Fällen, in denen eine Maintenance-Aufgabe nicht auf allen Installationen ausgeführt werden sollte (z. B. nur auf der Veröffentlichungsinstanz), können Sie festlegen, dass der Dienst konfiguriert werden muss, damit er aktiv ist, indem Sie @Component(policy=ConfigurationPolicy.REQUIRE)
hinzufügen. Anschließend können Sie die entsprechende Konfiguration im Repository als abhängig vom Ausführungsmodus markieren. Weitere Informationen finden Sie unter Konfigurieren von OSGi.
Unten sehen Sie ein Beispiel einer benutzerdefinierten Wartungsaufgabe, die Dateien aus einem konfigurierbaren temporären Verzeichnis löscht, die in den letzten 24 Stunden bearbeitet wurden:
src/main/java/com/adobe/granite/samples/maintenance/impl/DeleteTempFilesTask.java
|
experiencemanager-java-maintenanceTask-sample- src/main/java/com/adobe/granite/samples/maintenance/impl/DeleteTempFilesTask.java
Wenn der Dienst bereitgestellt wurde, wird er an die Benutzeroberfläche des Vorgangs-Dashboards übergeben und kann zu einem der verfügbaren Wartungszeitpläne hinzugefügt werden:
Dadurch wird eine entsprechende Ressource unter /apps/granite/operations/config/maintenance/schedule
/taskname
hinzugefügt. Wenn die Aufgabe vom Ausführungsmodus abhängig ist, müssen Sie die Eigenschaft granite.operations.conditions.runmode auf diesem Knoten auf die Werte der Ausführungsmodi festlegen, die für diese Wartungsaufgabe aktiv sein müssen.
Das Dashboard Systemübersicht zeigt einen Überblick über die Konfiguration, Hardware und den Zustand der AEM Instanz auf hoher Ebene. Der Status der Systemkonsistenz ist also transparent und alle entsprechenden Daten werden auf einem zentralen Dashboard zusammengeführt.
Sehen Sie sich dieses Video für eine Einführung in das Dashboard "Systemübersicht"an.
Um auf das Dashboard Systemübersicht zuzugreifen, navigieren Sie zu Tools > Vorgänge > Systemübersicht.
In der nachfolgenden Tabelle werden alle Informationen beschrieben, die im Systemübersicht-Dashboard angezeigt werden. Beachten Sie dabei: Wenn es keine relevanten anzuzeigenden Informationen gibt (wenn z. B. kein Backup durchgeführt wird, gibt es keine kritischen Konsistenzprüfungen), wird im entsprechenden Bereich die Meldung „Keine Einträge“ angezeigt.
Sie können auch eine JSON
-Datei herunterladen, die die Informationen zum Dashboard zusammenfasst, indem Sie auf die Schaltfläche Herunterladen in der oberen rechten Ecke des Dashboards klicken. Der JSON
-Endpunkt ist /libs/granite/operations/content/systemoverview/export.json
und kann in einem curl
-Skript zur externen Überwachung verwendet werden.
Abschnitt | Angezeigte Informationen | Wann liegt ein kritischer Status vor | Ist verknüpft mit |
Konsistenzprüfungen |
|
Visueller Hinweis:
|
|
Wartungsaufgaben |
|
Visueller Hinweis:
|
|
System |
|
Nicht zutreffend | Nicht zutreffend |
Instanz |
|
Nicht zutreffend | Nicht zutreffend |
Repository |
|
Nicht zutreffend | Nicht zutreffend |
Verteilungsagenten |
|
Visueller Hinweis:
|
Seite „Verteilung“ |
Replikationsagenten |
|
Visueller Hinweis:
|
Seite „Replikation“ |
Workflows |
Für jeden der o. g. Status wird eine Abfrage durchgeführt, mit einem Limit von 400 Millisekunden. Bei 400 Millisekunden wird die Anzahl der bis dahin erfassten Einträge angezeigt. |
Nicht interpretiert:
|
Seite „Workflow-Fehler“ |
Sling-Aufträge | Anzahl an Sling-Aufträgen – Anzahl an Aufträgen in einem bestimmten Status (falls vorhanden):
|
Nicht interpretiert:
|
Nicht zutreffend |
Voraussichtliche Knotenanzahl | Voraussichtliche Anzahl an:
Die Gesamtanzahl der Knoten wird vom Knoten nodeCounterMBean bezogen, während der Rest der Statistik von IndexInfoService abgerufen wird. |
Nicht zutreffend | Nicht zutreffend |
Sicherung | Zeigt ggf. „Online-Sicherung wird ausgeführt“ an. | Nicht zutreffend | Nicht zutreffend |
Indizierung | Displays:
Wenn ein Indizierungs- oder Abfrage-Thread in der Thread-Sicherheitskopie vorhanden ist |
Nicht zutreffend | Nicht zutreffend |