Vorgangs-Dashboard operations-dashboard
Einführung introduction
Das Vorgangs-Dashboard in AEM 6 hilft Systembetreibern, den Systemzustand AEM Systems 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 über externe Überwachungstools über JMX möglich.
Das Vorgangs-Dashboard:
- Ist ein Systemstatus mit einem Klick, der Abteilungen bei der Effizienz unterstützt
- stellt einen zentralen Überblick über die Systemkonsistenz bereit
- Verringert die Zeit zum Suchen, Analysieren und Beheben von Problemen
- 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 Health Report System stellt über Sling-Konsistenzprüfungen Informationen zum Zustand einer AEM Instanz bereit. Dies erfolgt entweder über OSGi-, JMX- oder HTTP-Anfragen (über JSON) oder über die Touch-optimierte Benutzeroberfläche. Es bietet Messungen und Schwellenwerte für bestimmte konfigurierbare Zähler und bietet in einigen Fällen 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 auf eine gute oder schlechte Gesundheit in einem bestimmten Produktbereich hinweisen. Diese Karten sind Visualisierungen der Sling-Konsistenzprüfungen, die Daten aus JMX und anderen Quellen aggregieren und verarbeitete Informationen erneut als MBeans verfügbar machen. Diese MBeans können auch im JMX-Webkonsoleunter org.apache.sling.healthcheck Domäne.
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:
Konsistenzprüfungstypen health-check-types
Es gibt zwei Arten von Konsistenzprüfungen in AEM 6:
- Individuelle Konsistenzprüfungen
- Verbund-Konsistenzprüfungen
Ein 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 Gesundheitsprobleme bereitstellen. Nehmen wir als Beispiel die Prüfung "Fehler protokollieren": Wenn die Instanzprotokolle FEHLER enthalten, finden Sie diese auf der Detailseite der Konsistenzprüfung. Oben auf der Seite sehen Sie einen Link zum Analyzer "Logmeldung" im Abschnitt Diagnose-Tools , der es Ihnen ermöglicht, diese Fehler detaillierter zu analysieren und die Logger neu zu konfigurieren.
A Composite Health Check ist eine Prüfung, die Informationen aus mehreren individuellen Prüfungen aggregiert.
Verbund-Konsistenzprüfungen werden mithilfe von Filter-Tags. 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, von denen sie Daten bezieht, ebenfalls diesen Status aufweisen.
Erstellen von Konsistenzprüfungen how-to-create-health-checks
Im Vorgangs-Dashboard können Sie die Ergebnisse von individuellen wie Verbund-Konsistenzprüfung visuell darstellen.
Erstellen einer individuellen Konsistenzprüfung creating-an-individual-health-check
Die Erstellung einer individuellen Konsistenzprüfung umfasst zwei Schritte: Implementierung 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, müssen Sie eine OSGi-Komponente erstellen, die die Sling-Konsistenzprüfungs-Schnittstelle implementiert. Sie fügen diese Komponente in einem Bundle hinzu. Die Eigenschaften der Komponente identifizieren die Konsistenzprüfung vollständig. Sobald die Komponente installiert ist, wird automatisch ein JMX MBean für die Konsistenzprüfung erstellt. Siehe Dokumentation zur Sling-Konsistenzprüfung für 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 neuen 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, eine Reihe von individuellen Konsistenzprüfungen zu aggregieren, die eine Reihe gemeinsamer Funktionen gemeinsam nutzen. Beispielsweise gruppiert die Security Composite Health Check alle individuellen Konsistenzprüfungen, die sicherheitsbezogene Überprüfungen durchführen. Der erste Schritt zum Erstellen einer zusammengesetzten Prüfung besteht darin, eine neue OSGi-Konfiguration hinzuzufügen. Damit er im Vorgangs-Dashboard angezeigt werden kann, muss ein neuer Konfigurationsknoten hinzugefügt werden, wie dies bei einer einfachen Prüfung der Fall war.
-
Wechseln Sie zum Web-Konfigurations-Manager in der OSGi-Konsole. Sie können dies tun, indem Sie
https://serveraddress:port/system/console/configMgraufrufen. -
Suchen Sie nach dem Eintrag namens Apache Sling Composite Health Check. Beachten Sie nach der Suche, dass bereits zwei Konfigurationen verfügbar sind: eine für die Systemprüfungen und eine andere für die Sicherheitsprüfungen.
-
Erstellen Sie eine neue Konfiguration, indem Sie auf der rechten Seite der Konfiguration auf die Schaltfläche "+" klicken. Ein neues Fenster wird geöffnet, wie unten abgebildet:
-
Erstellen Sie eine Konfiguration und speichern Sie sie. Mit der neuen Konfiguration wird ein MBean erstellt.
Der Zweck jeder Konfigurationseigenschaft lautet 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 zusammengesetzte 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 verbunden ist.
- MBean-Name (hc.mbean.name): Der Name des MBean, das dem JMX MBean dieser zusammengesetzten Konsistenzprüfung übergeben wird.
- Filter-Tags (filter.tags): Dies ist eine Eigenschaft, die für Konsistenzprüfungen bei Composite-Tests spezifisch ist. Dies sind die Tags, die der Composite aggregieren soll. Die Verbund-Konsistenzprüfung aggregiert unter ihrer Gruppe alle Konsistenzprüfungen mit Tags, die mit einem der Filter-Tags dieses Verbund übereinstimmen. Beispielsweise aggregiert eine Verbund-Konsistenzprüfung mit den Filter-Tags test und check alle individuellen und Verbund-Konsistenzprüfungen, die einen der Tags test und check in ihrer tags-Eigenschaft aufweisen (
hc.tags).
note note NOTE 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 im Konfigurationsknoten des Vorgangs-Dashboards hinzufügen. Die Vorgehensweise ist dieselbe wie bei individuellen Konsistenzprüfungen: ein Knoten des Typs nt:unstructured muss unter
/apps/settings/granite/operations/hcerstellt werden. Die Ressourceneigenschaft des Knotens wird durch den Wert von hc.mean.name in der OSGi-Konfiguration.Wenn Sie beispielsweise eine Konfiguration erstellt haben und die Variable hc.mbean.name Wert zu diskusage, 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 Composite-Prüfung gehören, die standardmäßig bereits im Dashboard vorhanden ist, werden diese automatisch erfasst und unter der entsprechenden Composite-Prüfung gruppiert. Daher ist es nicht erforderlich, einen neuen Konfigurationsknoten für diese Prüfungen zu 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. -
Im Lieferumfang von AEM enthaltene Konsistenzprüfungen health-checks-provided-with-aem
Überwachung mit Nagios monitoring-with-nagios
Das Konsistenzprüfungs-Dashboard kann über die Granite JMX MB 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 unter Nagios-Dokumentation. -
Fügen Sie eine Hostdefinition für den AEM-Server hinzu. Dies kann über die Nagios XI-Webschnittstelle mithilfe von Configuration Manager erfolgen:
- Ö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 die check_http_json -Plug-in 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:
Diagnosetools diagnosis-tools
Das Vorgangs-Dashboard bietet außerdem Zugriff auf Diagnose-Tools, die Ihnen helfen, die Grundursachen der Warnungen aus dem Konsistenzprüfungs-Dashboard zu finden und zu beheben sowie wichtige Debugging-Informationen für Systembetreiber bereitzustellen.
Zu den wichtigsten Funktionen zählen:
- Protokollnachrichten-Analyse
- Zugriff auf Heap- und Thread-Sicherheitskopien
- 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
In der Benutzeroberfläche der Protokollmeldungen werden standardmäßig alle FEHLER-Meldungen angezeigt. Wenn Sie mehr Protokollmeldungen anzeigen möchten, müssen Sie eine Protokollfunktion 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 in dieser Benutzeroberfläche wirkt sich nur auf die In-Memory-Logger aus. Beachten Sie außerdem, dass sich das Ändern der Logger-Konfigurationen in der Zukunft des In-Memory-Loggers widerspiegeln wird. 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 bereitstellen. Dort können Sie Logger-Konfigurationen hinzufügen, entfernen oder aktualisieren. Eine Logger-Konfiguration besteht aus einer Protokollebene (WARN/INFO/DEBUG) und a Filtername. Die Filtername hat die Rolle, die Quelle der protokollierten Protokollmeldungen zu filtern. Wenn eine Protokollfunktion alle Protokollmeldungen für die angegebene Ebene erfassen soll, sollte der Filtername alternativ "root". Durch das Festlegen der Protokollierungsebene wird die Erfassung aller Nachrichten mit einer mindestens der angegebenen Ebene Trigger.
Beispiele:
-
Wenn Sie alle FEHLER messages - keine Konfiguration erforderlich. Alle FEHLER-Meldungen werden standardmäßig erfasst.
-
Wenn Sie alle FEHLER, WARN und INFO messages - der Logger-Name sollte auf Folgendes festgelegt werden: "root" und der Protokollierungsstufe auf: INFO.
-
Wenn Sie alle Nachrichten aus einem bestimmten Paket erfassen möchten (z. B. com.adobe.granite), sollte der Logger-Name auf Folgendes festgelegt werden: "com.adobe.granite"und die Protokollebene auf: DEBUG (Dadurch werden alle FEHLER, WARN, INFO und DEBUG Meldungen), 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 wird angezeigt:
- 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
Auf der Seite "Abfrageleistung"können die langsamsten vom System durchgeführten Abfragen analysiert werden. 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 wird angezeigt:
- Der Zeitpunkt, zu dem die Abfrage durchgeführt wurde
- Die Sprache der Abfrage
- Die Häufigkeit, mit der die Abfrage ausgegeben wurde
- Die Anweisung 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 oak:index Knoten. Je nach Abfrage können Oak verschiedene Indizes auswählen. Die Ausführung einer Abfrage durch Oak zu verstehen ist der erste Schritt zur Optimierung der Abfrage.
Die Abfrage erläutern ist ein Tool, das erklärt, wie Oak eine Abfrage ausführt. Sie können darauf zugreifen, indem Sie Tools - Vorgänge - Diagnose Klicken Sie auf dem AEM Begrüßungsbildschirm auf Abfrageleistung und der Wechsel zum Abfrage erläutern Registerkarte.
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
- Bietet eine Liste der langsamen und beliebten Abfragen mit Klicks zum Laden
Sobald Sie sich in der Benutzeroberfläche "Abfrage erläutern"befinden, müssen Sie lediglich die Abfrage eingeben und die Erklären Schaltfläche:
Der erste Eintrag im Abschnitt 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.
Tippen Sie auf Ausführungszeit einschließen -Feld vor Ausführung der Abfrage zeigt auch die Zeit an, in der die Abfrage ausgeführt wurde. So erhalten Sie 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 die Anzeige ihres Status.
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 oberen linken Ecke des Bildschirms eingegeben werden.
Status-ZIP herunterladen download-status-zip
Dadurch wird der Download einer ZIP-Datei mit nützlichen Informationen zum Systemstatus und zur Systemkonfiguration Trigger. Das Archiv enthält Instanzkonfigurationen, eine Liste von Paketen, OSGi, Sling-Metriken und Statistiken. Es kann sich daher um eine große Datei handeln. Sie können die Auswirkungen großer Statusdateien reduzieren, indem Sie das Fenster "Download Status ZIP"verwenden. 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 oder andere Thread-Sicherheitskopien) und wie viele Tage von Protokollen im Download im Verhältnis zum aktuellen Datum enthalten sein sollen.
Thread-Sicherheitskopie herunterladen download-thread-dump
Dadurch wird der Download einer ZIP-Datei Trigger, die Informationen zu den im System vorhandenen Threads enthält. Es werden Informationen zu jedem Thread bereitgestellt, wie z. B. sein Status, der Klassenlader und der Stacktrace.
Stapel-Sicherheitskopie herunterladen download-heap-dump
Sie können auch eine Momentaufnahme des Heap herunterladen, um ihn zu einem späteren Zeitpunkt zu analysieren. Beachten Sie, dass dies den Download einer großen Datei in der Größenordnung von Hunderten von Megabyte Trigger.
Automatisierte Wartungsaufgaben automated-maintenance-tasks
Auf der Seite "Automatisierte Wartungsaufgaben"können Sie empfohlene Wartungsaufgaben, die für die regelmäßige Ausführung geplant sind, anzeigen und verfolgen. 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, müssen Sie Tools - Vorgänge - Dashboard - Wartung über den AEM Willkommensbildschirm oder folgen Sie diesem Link:
https://serveraddress:port/libs/granite/operations/content/maintenance.html
Die folgenden Aufgaben sind im Vorgangs-Dashboard verfügbar:
-
Die Revisionsbereinigung Aufgabe, die sich unter der Tägliches Wartungsfenster Menü.
-
Die Aufgabe Lucene-Binärdateien-Bereinigung befindet sich unter der Tägliches Wartungsfenster Menü.
-
Die Aufgabe "Workflow-Bereinigung", die sich unter der Wöchentliches Wartungsfenster Menü.
-
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 Standardzeitplan für das tägliche Wartungsfenster beträgt 2-5 Uhr. Die für die Ausführung im wöchentlichen Wartungsfenster konfigurierten Aufgaben werden samstags zwischen 1 und 2 Uhr ausgeführt.
Sie können die Timings auch konfigurieren, indem Sie auf einer der beiden Wartungskarten auf das Zahnradsymbol klicken:
Revisionsbereinigung revision-clean-up
Weitere Informationen zur Durchführung der Revisionsbereinigung für AEM 6.4 finden Sie unter finden Sie in diesem speziellen Artikel.
Lucene-Binärdateien-Bereinigung lucene-binaries-cleanup
Mithilfe der Aufgabe Lucene-Binärdateien-Bereinigung können Sie Lucene-Binärdateien bereinigen und die Anforderungen an die Größe des laufenden Datenspeichers reduzieren. Grund dafür ist, dass der Churn der Lucene-Binärdateien täglich neu angefordert wird, statt wie zuvor von einer erfolgreichen Ausführung der Datenspeicherbereinigung abhängig zu sein.
Obwohl die Wartungsaufgabe entwickelt wurde, um Lucene-bezogenen Überarbeitungsfehler zu reduzieren, gibt es allgemeine Effizienzsteigerungen bei der Ausführung der Aufgabe:
- Die wöchentliche Ausführung der Speicherbereinigung wird schneller abgeschlossen
- 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. Um die Aufgabe "Workflow-Bereinigung"ausführen zu können, müssen Sie:
- Klicken Sie auf Wöchentliches Wartungsfenster Seite.
- Klicken Sie auf der folgenden Seite auf die Play im Workflow-Bereinigung Karte.
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. Das verringert die Notwendigkeit, manuell die Tools zur Versionsbereinigung 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 die Schaltfläche Hinzufügen.
-
Wählen Sie aus dem Dropdown-Menü Versionsbereinigung aus.
-
Um die Versionsbereinigung zu konfigurieren, klicken Sie auf der neu erstellten Versionsbereinigungs-Wartungskarte auf das Zahnradsymbol.
Mit AEM 6.4 können Sie die Wartungsaufgabe Versionsbereinigung wie folgt beenden:
- Automatisch - Wenn das geplante Wartungsfenster geschlossen wird, bevor die Aufgabe abgeschlossen werden kann, wird die Aufgabe automatisch beendet. 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 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:
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 vom Benutzer angehalten wurde, und ein Ergebnis erstellen (Erfolg oder Fehler).
Wenn eine Wartungsaufgabe nicht auf allen Installationen ausgeführt werden soll (z. B. nur auf der Veröffentlichungsinstanz), können Sie den Dienst so konfigurieren, dass er eine Konfiguration benötigt, um aktiv zu sein. Fügen Sie dazu @Component(policy=ConfigurationPolicy.REQUIRE) hinzu. 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 aus einem konfigurierbaren temporären Ordner löscht, die in den letzten 24 Stunden geändert 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
Sobald der Dienst bereitgestellt wurde, wird er der UI des Vorgangs-Dashboards angezeigt und kann zu einem der verfügbaren Wartungszeitpläne hinzugefügt werden:
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 mit den Werten der Ausführungsmodi festgelegt werden, die für diese Wartungsaufgabe aktiv sein müssen.
Systemübersicht system-overview
Das Systemübersicht-Dashboard bietet einen großflächigen Überblick über die Konfiguration, die Hardware und den Konsistenz der AEM-Instanz. Der Status der Systemkonsistenz ist also transparent und alle entsprechenden Daten werden auf einem zentralen Dashboard zusammengeführt.
Zugriff how-to-access
Um auf das Systemübersicht-Dashboard zuzugreifen, gehen Sie zu Tools > Vorgänge > Systemübersicht.
Dashboard "Systemübersicht" - Erklärung system-overview-dashboard-explained
In der folgenden Tabelle werden alle im Dashboard "Systemübersicht"angezeigten Informationen beschrieben. Beachten Sie, dass der entsprechende Abschnitt die Meldung "Keine Einträge"anzeigt, wenn keine relevanten Informationen angezeigt werden (z. B. wenn keine Sicherung durchgeführt wird, keine kritischen Konsistenzprüfungen vorliegen).
Sie können auch eine JSON-Datei herunterladen, in der alle Dashboard-Informationen zusammengefasst sind. Klicken Sie dazu in der oberen rechten Ecke des Dashboards auf die Schaltfläche Herunterladen. Der JSON-Endpunkt ist /libs/granite/operations/content/systemoverview/export.json und er kann in einem curl-Skript für die externe Überwachung genutzt werden.