Vorgangs-Dashboard operations-dashboard
Einführung introduction
Das Vorgangs-Dashboard in AEM 6 hilft Systembetreiberinnen und -betreibern, den AEM-Systemzustand auf einen Blick zu überwachen. Außerdem bietet das Dashboard automatisch erstellte Diagnosedaten zu relevanten Aspekten von AEM und ermöglicht die Konfiguration und Ausführung einer eigenständigen Wartungsautomatisierung, um Projektvorgänge und Support-Fälle deutlich zu reduzieren. Das Vorgangs-Dashboard kann mit benutzerdefinierten Konsistenzprüfungen und Wartungsaufgaben erweitert werden. Darüber hinaus ist der Zugriff auf die Daten des Vorgangs-Dashboards durch externe Überwachungs-Tools über JMX möglich.
Das Vorgangs-Dashboard:
- ist ein Systemstatus mit einem Klick, der Betriebsabteilungen effizienter macht
- stellt einen zentralen Überblick über die Systemkonsistenz bereit
- verringert den Zeitaufwand für das Erkennen, Analysieren und Beheben von Fehlern
- bietet eine eigenständige Wartungsautomatisierung, mit der die Kosten für den Projektbetrieb erheblich gesenkt werden können
Sie können auf dem AEM-Begrüßungsbildschirm über Tools > Vorgänge auf das Dashboard zugreifen.
Konsistenzberichte health-reports
Das Konsistenzberichtssystem stellt Informationen zum Zustand einer AEM-Instanz durch Sling-Konsistenzprüfungen bereit. Sie können diesen Vorgang entweder über OSGi, JMX, HTTP-Anfragen (über JSON) oder über die Touch-Benutzeroberfläche durchführen. Es bietet Messungen und Schwellenwerte für bestimmte konfigurierbare Zähler und liefert manchmal Informationen zur Lösung des Problems.
Es umfasst mehrere Funktionen, die unten beschrieben werden.
Konsistenzprüfungen health-checks
Die Konsistenzberichte sind ein System von Karten, die einen guten oder schlechten Status in einem bestimmten Produktbereich anzeigen. Diese Karten sind Visualisierungen der Sling-Konsistenzprüfungen, die Daten aus JMX und anderen Quellen aggregieren und verarbeitete Informationen als MBeans erneut verfügbar machen. Diese MBeans können auch in der JMX-Web-Konsole unter der Domain org.apache.sling.healthcheck inspiziert werden.
Sie können auf dem AEM-Willkommensbildschirm über das Menü Tools > Vorgänge > Konsistenzberichte oder über die folgende URL auf die Konsistenzberichte 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:
Arten von Konsistenzprüfungen health-check-types
Es gibt zwei Arten von Konsistenzprüfungen in AEMٔ 6:
- Individuelle Konsistenzprüfungen
- Verbund-Konsistenzprüfungen
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 können einen oder mehrere Hinweise und Links zur Lösung identifizierter Statusprobleme bereitstellen. Nehmen wir als Beispiel die Prüfung „Fehler protokollieren“: Wenn die Instanzprotokolle FEHLER-Einträge enthalten, finden Sie diese auf der Detailseite der Konsistenzprüfung. Oben auf der Seite sehen Sie einen Link zum Analyzer „Protokollmeldung“ im Abschnitt „Diagnose-Tools“, mit dem Sie diese Fehler detaillierter analysieren und die Logger neu konfigurieren können.
Eine Verbund-Konsistenzprüfung ist eine Prüfung, die Informationen aus mehreren individuellen Prüfungen aggregiert.
Verbund-Konsistenzprüfungen werden mithilfe von Filter-Tags konfiguriert. Im Wesentlichen werden alle einzelnen Prüfungen mit demselben Filter-Tag als Verbund-Konsistenzprüfung gruppiert. Eine Verbund-Konsistenzprüfung weist nur dann den Status „OK“ auf, wenn alle individuellen Prüfungen, die sie umfasst, ebenfalls diesen Status aufweisen.
Erstellen von Konsistenzprüfungen how-to-create-health-checks
Im Vorgangs-Dashboard können Sie die Ergebnisse von individuellen sowie von Verbund-Konsistenzprüfungen visuell darstellen.
Erstellen einer individuellen Konsistenzprüfung creating-an-individual-health-check
Die Erstellung einer individuellen Konsistenzprüfung umfasst zwei Schritte: Implementieren einer Sling-Konsistenzprüfung und Hinzufügen eines Eintrags für die Konsistenzprüfung in den Konfigurationsknoten des Dashboards.
-
Um eine Sling-Konsistenzprüfung zu erstellen, erstellen Sie eine OSGi-Komponente, die die Sling HealthCheck-Schnittstelle implementiert. Fügen Sie diese Komponente in einem Bundle hinzu. Die Eigenschaften der Komponente identifizieren die Konsistenzprüfung vollständig. Nachdem die Komponente installiert wurde, wird automatisch ein JMX-MBean für die Konsistenzprüfung erstellt. In der Dokumentation zur Sling-Konsistenzprüfung finden Sie weitere Informationen.
Beispiels einer Sling-Konsistenzprüfungs-Komponente, mit OSGi-Dienstkomponenten-Anmerkungen geschrieben:
code language-java @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 } }note note NOTE Die Eigenschaft MBEAN_NAMEdefiniert 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 Knoten (des Typs nt:unstructured) unter dem folgenden Pfad hinzu:/apps/settings/granite/operations/hcLegen Sie die folgenden Eigenschaften für den neuen Knoten fest:
-
Name:
sling:resourceType- Typ:
String - Wert:
granite/operations/components/mbean
- Typ:
-
Name:
resource- Typ:
String - Wert:
/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/exampleHealthCheck
- Typ:
note note NOTE Der o. g. Ressourcenpfad wird wie folgt erstellt: Wenn der MBean-Name der Konsistenzprüfung „test“ ist, 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/testnote note NOTE Stellen Sie sicher, dass beim Pfad /apps/settings/granite/operations/hcfür die folgenden Eigenschaften „true“ festgelegt ist:sling:configCollectionInheritsling:configPropertyInheritDadurch weiß der Konfigurations-Manager, dass die neuen Konfigurationen mit den vorhandenen aus /libszusammengeführt werden sollen. -
Erstellen einer Verbund-Konsistenzprüfung creating-a-composite-health-check
Die Rolle einer Verbund-Konsistenzprüfung besteht darin, mehrere individuelle Konsistenzprüfungen mit einer Reihe gemeinsamer Funktionen zu aggregieren. Beispielsweise gruppiert die Sicherheits-Verbund-Konsistenzprüfung alle individuellen Konsistenzprüfungen, die sicherheitsbezogene Überprüfungen durchführen. Der erste Schritt zum Erstellen einer Verbund-Konsistenzprüfung besteht darin, eine OSGi-Konfiguration hinzuzufügen. Damit er im Vorgangs-Dashboard angezeigt wird, muss ein neuer Konfigurationsknoten auf die gleiche Weise hinzugefügt werden wie für eine einfache Prüfung.
-
Wechseln Sie zum Web-Konfigurations-Manager in der OSGi-Konsole. Greifen Sie auf
https://serveraddress:port/system/console/configMgrzu. -
Suchen Sie nach dem Eintrag namens Apache Sling Verbund-Konsistenzprüfung. Nachdem Sie ihn gefunden haben, beachten Sie, dass bereits zwei Konfigurationen verfügbar sind: eine für die Systemprüfungen und eine andere für die Sicherheitsprüfungen.
-
Erstellen Sie eine Konfiguration, indem Sie auf die Schaltfläche „+“ rechts von der Konfiguration klicken. 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:
- Name (hc.name): Der Name der Verbund-Konsistenzprüfung. Es wird ein aussagekräftiger Name empfohlen.
- Tags (hc.tags): Die Tags für diese Konsistenzprüfung. Wenn diese Verbund-Konsistenzprüfung Teil einer anderen Verbund-Konsistenzprüfung sein soll (z. B. in einer Hierarchie der Konsistenzprüfungen), fügen Sie die Tags hinzu, mit denen dieser Verbund verknüpft ist.
- MBean-Name (hc.mbean.name): Der Name des MBean, der dem JMX-MBean dieser Verbund-Konsistenzprüfung übergeben wird.
- Filter-Tags (filter.tags): Die Eigenschaft, die für Verbund-Konsistenzprüfungen spezifisch ist. Diese Tags werden durch den Verbund aggregiert. Die Verbund-Konsistenzprüfung aggregiert unter ihrer Gruppe alle Konsistenzprüfungen mit Tags, die einem der Filter-Tags dieser Verbund-Konsistenzprüfung entsprechen. Eine Verbund-Konsistenzprüfung mit den Filter-Tags test und check fasst beispielsweise alle individuellen und Verbund-Konsistenzprüfungen zusammen, die eines der Tags test und check in ihrer Tags-Eigenschaft (
hc.tags) aufweisen.
note note NOTE Ein neues JMX-MBean wird für jede neue Konfiguration des Apache Sling Composite Health Checks erstellt.** -
Schließlich muss der Eintrag der erstellten Verbund-Konsistenzprüfung im Konfigurationsknoten des Vorgangs-Dashboards hinzugefügt werden. Die Vorgehensweise ist dieselbe wie bei individuellen Konsistenzprüfungen: es muss ein Knoten vom Typ nt:unstructured unter
/apps/settings/granite/operations/hcangelegt werden. Die Ressourceneigenschaft des Knotens wird durch den Wert von hc.mean.name in der OSGi-Konfiguration definiert.Wenn Sie beispielsweise eine Konfiguration erstellt und den Wert hc.mbean.name auf diskusage gesetzt haben, sehen die Konfigurationsknoten wie folgt aus:
-
Name:
Composite Health Check- Typ:
nt:unstructured
- Typ:
Mit den folgenden Eigenschaften:
-
Name:
sling:resourceType- Typ:
String - Wert:
granite/operations/components/mbean
- Typ:
-
Name:
resource- Typ:
String - Wert:
/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/diskusage
- Typ:
note note NOTE Wenn Sie individuelle Konsistenzprüfungen erstellen, die logisch zu einer Verbund-Konsistenzprüfung gehören, welche standardmäßig bereits im Dashboard vorhanden ist, werden diese automatisch erfasst und unter der entsprechenden Verbund-Konsistenzprüfung gruppiert. Daher ist es nicht erforderlich, einen Konfigurationsknoten für diese Prüfungen zu erstellen. Wenn Sie beispielsweise eine individuelle Sicherheitskonsistenzprüfung erstellen, weisen Sie ihr das Tag „Sicherheit“ zu, und sie wird installiert. Sie wird automatisch unter den Verbund-Sicherheitsprüfungen im Vorgangs-Dashboard angezeigt. -
Im Lieferumfang von AEM enthaltene Konsistenzprüfungen health-checks-provided-with-aem
Konfiguration der Konsistenzprüfung health-check-configuration
Standardmäßig werden bei einer vordefinierten AEM-Instanz alle 60 Sekunden Konsistenzprüfungen ausgeführt.
Sie können den Zeitraum in der OSGi-Konfiguration mit der Konfiguration der Konsistenzprüfung von Anfragen (com.adobe.granite.queries.impl.hc.QueryHealthCheckMetrics) festlegen.
Überwachung mit Nagios monitoring-with-nagios
Das Konsistenzprüfungs-Dashboard kann über die Granite JMX Mbeans in Nagios integriert werden. 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 Überwachungs-Server.
-
Installieren Sie anschließend den Nagios Remote Plugin Executor (NRPE).
note note NOTE Weitere Informationen zur Installation von Nagios und NRPE auf Ihrem System finden Sie in der Nagios-Dokumentation. -
Fügen Sie eine Host-Definition für den AEM-Server hinzu. Sie können diese Aufgabe über die Nagios XI-Web-Schnittstelle mithilfe von Configuration Manager durchführen:
- Öffnen Sie einen Browser und zeigen Sie auf den Nagios-Server.
- Klicken Sie im oberen Menü auf die Schaltfläche Konfigurieren.
- Klicken Sie in der linken Spur unter Erweiterte Konfiguration auf Core-Konfigurations-Manager.
- Klicken Sie unter dem Abschnitt Überwachung auf den Link Hosts.
- Fügen Sie die Hostdefinition hinzu:
Nachfolgend finden Sie ein Beispiel einer Host-Konfigurationsdatei unter Verwendung von Nagios Core:
code language-xml 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:
code language-xml 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:
code language-xml 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:
Diagnose-Tools diagnosis-tools
Das Vorgangs-Dashboard bietet außerdem Zugriff auf Diagnose-Tools, die Ihnen helfen, die Hauptursachen der Warnungen aus dem Konsistenzprüfungs-Dashboard zu finden und zu beheben, und die wichtige Debugging-Informationen für Systembetreiber bereitstellen.
Zu den wichtigsten Funktionen gehören:
- Ein Protokollmeldungs-Analyzer
- Zugriff auf Heap- und Thread-Dumps
- Leistungs-Analyse für Anfragen und Abfragen
Auf den Bildschirm „Diagnose-Tools“ können Sie über den AEM-Begrüßungsbildschirm über Tools > Vorgänge > Diagnose zugreifen. Über die folgende URL können Sie auch direkt auf die Diagnose-Tools zugreifen: https://serveraddress:port/libs/granite/operations/content/diagnosis.html
Protokollmeldungen log-messages
Die Benutzeroberfläche der Protokollmeldungen zeigen standardmäßig alle Meldungen des Typs FEHLER an. Wenn Sie mehr Protokollmeldungen anzeigen möchten, konfigurieren Sie einen Logger mit der entsprechenden Protokollebene.
Die Protokollmeldungen nutzen einen speicherinternen Protokoll-Appender und hängen daher nicht mit den Protokolldateien zusammen. Eine weitere Konsequenz ist, dass sich bei Ä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 in dieser Benutzeroberfläche wirkt sich nur auf die Speicherprotokollierung aus. Außerdem spiegelt sich das Ändern der Logger-Konfigurationen in der Zukunft des speicherinternen Loggers wider. Die Einträge, die bereits protokolliert sind und nicht mehr relevant sind, werden nicht gelöscht, aber ähnliche Einträge werden in Zukunft nicht protokolliert.
Sie können konfigurieren, was protokolliert wird, indem Sie Logger-Konfigurationen über die Zahnradschaltfläche oben links in der Benutzeroberfläche festlegen. Dort können Sie Logger-Konfigurationen hinzufügen, entfernen oder aktualisieren. Eine Logger-Konfiguration besteht aus einer Protokollebene (WARNUNG/INFO/DEBUG) und einem Filternamen. Der Filtername hat die Aufgabe, die Quelle der protokollierten Protokollmeldungen zu filtern. Andernfalls sollte, wenn ein Logger alle Protokollmeldungen für die angegebene Ebene erfassen soll, der Filtername „Stamm“ sein. Das Festlegen eines Loggers löst die Erfassung aller Meldungen mit einer Stufe aus, die höher als oder gleich der angegebenen Stufe ist.
Beispiele:
-
Wenn Sie alle Meldungen des Typs FEHLER erfassen möchten, ist keine Konfiguration erforderlich. Alle FEHLER-Meldungen werden standardmäßig erfasst.
-
Wenn alle Meldungen des Typs FEHLER, WARNUNG und INFO erfasst werden sollen, sollte der Logger-Name auf „Stamm“ und die Protokollierungsstufe auf INFO festgelegt werden.
-
Wenn Sie alle Meldungen aus einem bestimmten Paket erfassen möchten (z. B. com.adobe.granite), sollte der Logger-Name auf „com.adobe.granite“ festgelegt werden. Darüber hinaus sollte die Protokollierungsebene auf DEBUG festgelegt werden (dadurch werden alle Meldungen des Typs FEHLER, WARNUNG, INFO und DEBUG erfasst), wie in der Abbildung unten dargestellt.
Log level: INFO
DATE+TIME [MaintanceLogger] Name=<MT_NAME>, Status=<MT_STATUS>, Time=<MT_TIME>, Error=<MT_ERROR>, Details=<MT_DETAILS>
Anfrageleistung request-performance
Die Anfrageleistungsseite ermöglicht die Analyse der langsamsten verarbeiteten Seitenanfragen. Nur Inhaltsanfragen werden auf dieser Seite registriert. Genauer gesagt werden die folgenden Anfragen erfasst:
- Anfragen, die auf Ressourcen unter
/contentzugreifen - Anfragen, die auf Ressourcen unter
/etc/designzugreifen - Anfragen mit der Erweiterung
".html"
Die Seite zeigt Folgendes an:
- die Zeit, zu der die Anfrage erfolgt ist
- die URL und die Methode der Anfrage
- Die Dauer in Millisekunden
Standardmäßig werden die langsamsten 20 Seitenanfragen erfasst. Diesen Wert können Sie aber im Konfigurations-Manager ändern.
Abfrageleistung query-performance
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:
- Der Zeitpunkt der Abfrage
- Die Sprache der Abfrage
- Die Zahl, wie oft die Abfrage durchgeführt wurde
- Die Aussage der Abfrage
- Die Dauer in Millisekunden
Abfrage erläutern explain-query
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. Sie können auf dem AEM-Willkommensbildschirm über Tools – Vorgänge – Diagnose darauf zugreifen. Klicken Sie anschließend auf Abfrageleistung und wechseln Sie zur Registerkarte Abfrage erläutern.
Funktionen
- Unterstützung der Abfragesprachen Xpath, JCR-SQL und JCR-SQL2
- Meldung der tatsächlichen Ausführungszeit der genannten Abfrage
- Erkennung langsamer Abfragen und Warnungen zu Abfragen, die möglicherweise langsam ausfallen könnten
- Gibt den Oak-Index an, der zum Ausführen der Abfrage verwendet wird
- Zeigt die tatsächliche Erläuterung der Oak-Abfrage-Engine an
- Stellt eine anklickbare Liste von langsamen und beliebten Abfragen zur Verfügung
Wenn Sie sich in der Benutzeroberfläche „Abfrage erläutern“ befinden, geben Sie die Abfrage ein und drücken Sie die Schaltfläche Erläutern:
Der erste Eintrag im Bereich „Abfrage-Erläuterung“ ist die eigentliche Erklärung. Die Erklärung zeigt den Indextyp an, der für die Ausführung der Abfrage verwendet wurde.
Der zweite Eintrag ist der Ausführungsplan.
Wenn Sie das Kästchen Ausführungszeit einbeziehen ankreuzen, bevor Sie die Abfrage ausführen, wird auch die Zeit angezeigt, in der die Abfrage ausgeführt wurde. Mit der Option Knotenanzahl einbeziehen wird die Knotenanzahl angezeigt. Der Bericht liefert weitere Informationen, die zur Optimierung der Indizes für Ihre Anwendung oder Bereitstellung verwendet werden können.
Der Index-Manager the-index-manager
Der Index-Manager soll die Indexverwaltung erleichtern, z. B. die Pflege von Indizes oder deren Statusanzeige.
Um auf ihn zuzugreifen, klicken Sie auf dem Begrüßungsbildschirm unter Tools > Vorgänge > Diagnose auf die Schaltfläche Index-Manager.
Darüber hinaus kann auf ihn direkt über diese URL zugegriffen werden: https://serveraddress:port/libs/granite/operations/content/diagnosistools/indexManager.html
Die Benutzeroberfläche kann verwendet werden, um Indizes in der Tabelle zu filtern, indem die Filterkriterien in das Suchfeld in der linken oberen Ecke des Bildschirms eingegeben werden.
Status-ZIP herunterladen download-status-zip
Diese Aktion 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. Um die Auswirkung großer Statusdateien zu minimieren, können Sie das Fenster Status-ZIP herunterladen nutzen. Das Fenster finden Sie unter AEM > Tools > Vorgänge > Diagnose > Status-ZIP herunterladen.
In diesem Fenster können Sie auswählen, was exportiert werden soll (Protokolldateien und/oder Thread-Speicherauszüge) und wie viele Tage die Protokolle im Verhältnis zum aktuellen Datum heruntergeladen werden sollen.
Thread-Sicherheitskopie herunterladen download-thread-dump
Diese Aktion löst den Download einer ZIP-Datei aus, die Informationen zu den Threads enthält, die im System vorhanden sind. Es werden Informationen zu jedem Thread bereitgestellt, z. B. zum Status, Classloader und Stacktrace.
Heap-Sicherheitskopie herunterladen download-heap-dump
Sie können einen Snapshot des Heaps herunterladen, um ihn später zu analysieren. Diese Aktion löst den Download einer großen Datei (Hunderte von Megabytes) aus.
Automatisierte Wartungsaufgaben automated-maintenance-tasks
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 in das Konsistenzprüfungssystem integriert. Die Aufgaben können auch manuell über die Benutzeroberfläche ausgeführt werden.
Um zur Wartungsseite im Vorgangs-Dashboard zu gelangen, gehen Sie vom AEM-Willkommensbildschirm aus zu Tools – Vorgänge – Dashboard – Wartung oder folgen Sie direkt diesem Link:
https://serveraddress:port/libs/granite/operations/content/maintenance.html
Die folgenden Aufgaben sind im Vorgangs-Dashboard verfügbar:
- die Aufgabe Revisionsbereinigung, zu finden im Menü Tägliches Wartungsfenster
- die Aufgabe Lucene-Binärdateien-Bereinigung, zu finden im Menü Tägliches Wartungsfenster
- die Aufgabe Workflow-Bereinigung, zu finden im Menü Wöchentliches Wartungsfenster
- die Aufgabe Datenspeicherbereinigung, zu finden im Menü Wöchentliches Wartungsfenster
- die Wartungsaufgabe Auditprotokoll, zu finden im Menü Wöchentliches Wartungsfenster
- die Wartungsaufgabe Versionsbereinigung, zu finden im Menü Wöchentliches Wartungsfenster
Der Standardzeitrahmen für das tägliche Wartungsfenster beträgt 2:00 Uhr bis 5:00 Uhr morgens. Die Aufgaben, die für das wöchentliche Wartungsfenster konfiguriert sind, werden samstags zwischen 1:00 und 2:00 Uhr morgens ausgeführt.
Sie können diese Zeiten auch konfigurieren. Klicken Sie dazu auf das Zahnradsymbol auf einer der beiden Wartungskarten:
Revisionsbereinigung revision-clean-up
Weitere Informationen zur Durchführung der Revisionsbereinigung in AEM finden Sie in diesem speziellen Artikel.
Lucene-Binärdateien-Bereinigung lucene-binaries-cleanup
Mit dieser Aufgabe können Sie Lucene-Binärdateien bereinigen und die Anforderungen an die Größe des laufenden Datenspeichers verringern. Die Fluktuation der Lucene-Binärdateien wird täglich zurückgewonnen, statt wie bisher von einer erfolgreichen Speicherbereinigung abhängig zu sein.
Zwar wurde die Wartungsaufgabe speziell entwickelt, um den mit Lucene verbundenen Revisions-Müll zu reduzieren, aber es gibt auch allgemeine Effizienzgewinne, wenn die Aufgabe ausgeführt wird:
- Die wöchentliche Ausführung der automatischen Datenspeicherbereinigung kann schneller abgeschlossen werden.
- Auch die Gesamtleistung von AEM kann sich leicht verbessern.
Die Aufgabe „Lucene-Binärdateien-Bereinigung“ finden Sie unter AEM > Tools > Vorgänge > Wartung > Tägliches Wartungsfenster > Lucene-Binärdateien-Bereinigung.
Datenspeicherbereinigung data-store-garbage-collection
Weitere Informationen zur automatischen Datenspeicherbereinigung finden Sie in der entsprechenden Dokumentationsseite.
Workflow-Bereinigung workflow-purge
Workflows können auch über das Wartungs-Dashboard bereinigt werden. Gehen Sie wie folgt vor, um die Aufgabe „Workflow-Bereinigung“ auszuführen:
- Klicken Sie auf die Seite Wöchentliches Wartungsfenster.
- Klicken Sie auf der folgenden Seite auf Wiedergabe in der Karte Workflow-Bereinigung.
Auditprotokoll-Wartung audit-log-maintenance
Informationen zur Auditprotokoll-Wartung finden Sie auf der entsprechenden Dokumentationsseite.
Versionsbereinigung version-purge
Sie können die Wartungsaufgabe zur Versionsbereinigung planen, um alte Versionen automatisch zu löschen. Diese Aktion minimiert die Notwendigkeit, die Tools zur Versionsbereinigung manuell zu verwenden. Um die Versionsbereinigung zu planen und zu konfigurieren, führen Sie unter Tools > Vorgänge > Wartung > Wöchentliches Wartungsfenster die folgenden Schritte durch:
-
Klicken Sie auf Hinzufügen.
-
Wählen Sie aus dem Dropdown-Menü Versionsbereinigung aus.
-
Um die Versionsbereinigungsaufgabe zu konfigurieren, klicken Sie auf das Zahnradsymbol auf der neu erstellten Wartungskarte „Versionsbereinigung“.
Mit AEM 6.4 können Sie die Wartungsaufgabe „Versionsbereinigung“ wie folgt stoppen:
- Automatisch – Wenn das geplante Wartungsfenster abläuft, bevor die Aufgabe abgeschlossen ist, wird die Aufgabe automatisch gestoppt. Sie wird fortgesetzt, wenn das nächste Wartungsfenster beginnt.
- Manuell – Um die Aufgabe manuell anzuhalten, klicken Sie auf der Versionsbereinigungs-Wartungskarte auf das Stopp-Symbol. Bei der nächsten Ausführung wird die Aufgabe sicher fortgesetzt.
Benutzerdefinierte Wartungsaufgaben custom-maintenance-tasks
Sie können benutzerdefinierte Wartungsaufgaben als OSGi-Dienste implementieren. Da die Infrastruktur für Wartungsaufgaben auf der Auftragsverarbeitung von Apache Sling basiert, muss eine Wartungsaufgabe über die Java™-Schnittstelle [org.apache.sling.event.jobs.consumer.JobExecutor](https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/consumer/JobExecutor.html) implementiert werden. Um als Wartungsaufgabe erkannt zu werden, muss sie zusätzlich mehrere Dienstregistrierungseigenschaften festlegen, wie nachfolgend aufgeführt:
Neben den o. g. Diensteigenschaften müssen Sie auch die process()-Methode der Schnittstelle JobConsumer implementieren. Fügen Sie dazu den Code hinzu, der für die Wartungsaufgabe ausgeführt werden soll. Mit dem bereitgestellten JobExecutionContext können Sie Statusinformationen ausgeben, prüfen, ob der Auftrag von der Benutzerin bzw. dem Benutzer angehalten wurde, und ein Ergebnis erstellen (Erfolg oder Fehlgeschlagen).
Für Situationen, in denen eine Wartungsaufgabe nicht auf allen Installationen ausgeführt werden soll (z. B. nur auf der Publishing-Instanz), können Sie durch Hinzufügen von @Component(policy=ConfigurationPolicy.REQUIRE) festlegen, dass der Dienst eine Konfiguration benötigt, um aktiv zu sein. 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.
Nachfolgend finden Sie ein Beispiel für eine benutzerdefinierte Wartungsaufgabe, die Dateien, die in den letzten 24 Stunden geändert wurden, aus einem konfigurierbaren temporären Ordner löscht:
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
Nachdem der Dienst bereitgestellt wurde, wird er der Benutzeroberfläche des Vorgangs-Dashboards angezeigt. Sie können ihn zu einem der verfügbaren Wartungszeitpläne hinzufügen:
Daraufhin wird eine entsprechende Ressource unter „/apps/granite/operations/config/maintenance/schedule/taskname“ hinzugefügt. Wenn die Aufgabe vom Ausführungsmodus abhängig ist, muss die Eigenschaft „granite.operations.conditions.runmode“ auf diesem Knoten festgelegt werden, wobei die Werte der Ausführungsmodi, die für diese Wartungsaufgabe aktiv sein müssen, anzugeben sind.
Systemübersicht system-overview
Das Systemübersicht-Dashboard bietet einen allgemeinen Überblick über die Konfiguration, die Hardware und die Konsistenz der AEM-Instanz. Der Status der Systemkonsistenz ist also transparent, und alle entsprechenden Daten werden in einem zentralen Dashboard zusammengeführt.
Zugriff how-to-access
Um auf das Systemübersicht-Dashboard zuzugreifen, gehen Sie zu Tools > Vorgänge > Systemübersicht.
Erläuterung zum Systemübersichts-Dashboard system-overview-dashboard-explained
In der nachfolgenden Tabelle werden alle Informationen beschrieben, die im Systemübersichts-Dashboard angezeigt werden. Wenn es keine relevanten anzuzeigenden Informationen gibt (z. B. es wird nicht gerade ein Backup durchgeführt, es gibt keine kritischen Konsistenzprüfungen), wird im entsprechenden Bereich die Meldung „Keine Einträge“ angezeigt.
Sie können auch eine JSON-Datei mit einer Zusammenfassung der Dashboard-Informationen herunterladen, indem Sie auf die Schaltfläche Herunterladen in der rechten oberen 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.