Vorgangs-Dashboard

Einführung

Das Vorgangs-Dashboard in AEM 6 hilft Systembetreibern, den Systemzustand AEM Systems auf einen Blick zu überwachen. Darüber hinaus stellt es automatisch generierte Diagnoseinformationen zu relevanten Aspekten der AEM bereit und ermöglicht Ihnen, eigenständige Wartungsautomatisierung zu konfigurieren und durchzuführen, um Projektvorgänge und Supportfälle erheblich 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

Das Health Report System stellt über Sling-Konsistenzprüfungen Informationen zum Zustand einer AEM Instanz bereit. Sie erreichen diesen Vorgang entweder über OSGi-, JMX-, HTTP-Anfragen (über JSON) oder über die Touch-Benutzeroberfläche. Es bietet Messungen und Schwellenwerte für bestimmte konfigurierbare Zähler und bietet manchmal Informationen zur Lösung des Problems.

Es umfasst mehrere Funktionen, die unten beschrieben werden.

Konsistenzprüfungen

Die Konsistenzberichte sind ein System von Karten, die einen guten oder schlechten Gesundheitszustand in einem bestimmten Produktbereich anzeigen. 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

Es gibt zwei Arten von Konsistenzprüfungen in AEM 6:

1. Individuelle Konsistenzprüfungen
2. 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 "Log Message" im Abschnitt Diagnose-Tools , mit dem Sie diese Fehler detaillierter analysieren und die Logger neu konfigurieren können.

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 hat nur dann den Status "OK", wenn alle einzelnen Prüfungen, die sie aggregiert, auch OK-Status aufweisen.

Erstellen von Konsistenzprüfungen

Im Vorgangs-Dashboard können Sie das Ergebnis von individuellen und zusammengesetzten Konsistenzprüfungen visualisieren.

Erstellen einer individuellen Konsistenzprüfung

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.

1. 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. Siehe Dokumentation zur Sling-Konsistenzprüfung für weitere Informationen.

   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
       }
    }
   

   HINWEIS

   Die MBEAN_NAME -Eigenschaft definiert den Namen des MBean, das für diese Konsistenzprüfung generiert wird.

2. Nach der Erstellung einer Konsistenzprüfung muss ein neuer Konfigurationsknoten erstellt werden, damit er über die Oberfläche des Vorgangs-Dashboards zugänglich 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 (vom Typ nt:unstructured) unter dem folgenden Pfad: /apps/settings/granite/operations/hc

   Legen Sie die folgenden Eigenschaften für den neuen Knoten fest:

   • Name: sling:resourceType

     • Typ: String
     • Wert: granite/operations/components/mbean

   • Name: resource

     • Typ: String
     • Wert: /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/exampleHealthCheck
   HINWEIS

   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/test

   HINWEIS

   Stellen Sie sicher, dass beim Pfad /apps/settings/granite/operations/hc für die folgenden Eigenschaften „true“ festgelegt ist:

   sling:configCollectionInherit

   sling:configPropertyInherit

   Dieser Prozess weist den Konfigurationsmanager an, die neuen Konfigurationen mit den vorhandenen aus zusammenzuführen /libs.

Erstellen einer Verbund-Konsistenzprüfung

Die Rolle einer Verbund-Konsistenzprüfung besteht darin, mehrere individuelle Konsistenzprüfungen mit einer Reihe gemeinsamer Funktionen zu aggregieren. 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 OSGi-Konfiguration hinzuzufügen. Damit er im Vorgangs-Dashboard angezeigt wird, muss ein neuer Konfigurationsknoten auf die gleiche Weise hinzugefügt werden wie eine einfache Prüfung.

1. Wechseln Sie zum Web-Konfigurations-Manager in der OSGi-Konsole. Zugriff https://serveraddress:port/system/console/configMgr

2. 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.

3. Erstellen Sie eine Konfiguration, indem Sie auf die Schaltfläche "+" rechts in der Konfiguration klicken. Ein neues Fenster wird wie unten gezeigt angezeigt:

   

4. Erstellen Sie eine Konfiguration und speichern Sie sie. Ein MBean wird mit der neuen Konfiguration 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): Die -Eigenschaft, die für Konsistenzprüfungen für Composite spezifisch ist. Diese Tags werden durch den Verbund aggregiert. Die zusammengesetzte Konsistenzprüfung aggregiert unter ihrer Gruppe alle Konsistenzprüfungen mit Tags, die mit einem der Filter-Tags dieses Verbundes übereinstimmen. Beispiel: eine zusammengesetzte Konsistenzprüfung mit den Filter-Tags test und check, aggregiert alle individuellen und zusammengesetzten Konsistenzprüfungen mit einer der test und check Tags in ihrer Tags-Eigenschaft ( hc.tags).
   HINWEIS

   Ein neues JMX-MBean wird für jede neue Konfiguration des Apache Sling Composite Health Checks erstellt.**

5. Schließlich muss der Eintrag der erstellten Verbund-Konsistenzprüfung in den Konfigurationsknoten des Vorgangs-Dashboards hinzugefügt werden. Das Verfahren entspricht dem der individuellen Konsistenzprüfungen: Knoten des Typs nt:unstructured muss unter /apps/settings/granite/operations/hc. 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

   Mit den folgenden Eigenschaften:

   • Name: sling:resourceType

     • Typ: String
     • Wert: granite/operations/components/mbean

   • Name: resource

     • Typ: String
     • Wert: /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/diskusage
   HINWEIS

   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 Konfigurationsknoten für diese Prüfungen zu erstellen.

   Wenn Sie beispielsweise eine individuelle Sicherheits-Konsistenzprüfung erstellen, weisen Sie ihr den security", und es wird installiert. Sie wird automatisch unter der zusammengesetzten Sicherheitsprüfungen im Vorgangs-Dashboard angezeigt.

Im Lieferumfang von AEM enthaltene Konsistenzprüfungen

Konfiguration der Konsistenzprüfung

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

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.

1. Richten Sie Nagios auf dem Überwachungsserver ein und installieren Sie es.

2. Installieren Sie anschließend den Nagios Remote Plugin Executor (NRPE).

   HINWEIS

   Weitere Informationen zur Installation von Nagios und NRPE auf Ihrem System finden Sie im Nagios-Dokumentation.

3. Fügen Sie eine Hostdefinition für den AEM-Server hinzu. Sie können diese Aufgabe über die Nagios XI-Webschnittstelle mithilfe von Configuration Manager durchführen:

   1. Öffnen Sie einen Browser und zeigen Sie auf den Nagios-Server.
   2. Klicken Sie im oberen Menü auf die Schaltfläche Konfigurieren.
   3. Klicken Sie in der linken Spur unter Erweiterte Konfiguration auf Core-Konfigurations-Manager.
   4. Klicken Sie unter dem Abschnitt Überwachung auf den Link Hosts.
   5. Fügen Sie die Hostdefinition hinzu:

   

   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
   }
   

4. Installieren Sie Nagios und NRPE auf dem AEM-Server.

5. Installieren Sie die check_http_json -Plug-in auf beiden Servern.

6. 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$'
   
   }
   

7. 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>
   
       }
   

8. Überprüfen Sie, ob das Nagios-Dashboard den neu erstellten Dienst anzeigt:

   

Diagnosetools

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, und wichtige Debugging-Informationen für Systembetreiber bereitstellen.

Zu den wichtigsten Funktionen gehören:

• 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

Die Protokollmeldungen Die Benutzeroberfläche zeigt standardmäßig alle FEHLER-Meldungen an. Wenn Sie mehr Protokollmeldungen anzeigen möchten, konfigurieren Sie eine Protokollfunktion mit der entsprechenden Protokollebene.

Die Protokollmeldungen nutzen einen In-Memory-Protokoll-Appender und hängen daher nicht mit den Protokolldateien zusammen. Eine weitere Folge ist, dass sich durch die Änderung der Protokollebenen in dieser Benutzeroberfläche die Informationen, die in den herkömmlichen Protokolldateien protokolliert 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 in-Memory-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 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 Festlegen der Protokollierungsstufe wird die Erfassung aller Nachrichten Trigger, deren Stufe mindestens der angegebenen entspricht.

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 Protokollierungsebene 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

Die Anfrageleistungsseite ermöglicht die Analyse der langsamsten verarbeiteten Seitenanfragen. Auf dieser Seite werden nur Inhaltsanforderungen registriert. Im Einzelnen werden die folgenden Anfragen erfasst:

1. Anfragen, die auf Ressourcen unter /content zugreifen
2. Anfragen, die auf Ressourcen unter /etc/design zugreifen
3. 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

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

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 über den AEM Begrüßungsbildschirm. Klicken Sie anschließend auf Abfrageleistung und wechseln Sie zur Abfrage erläutern Registerkarte.

Funktionen

• Unterstützt die 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

Wenn Sie sich in der Benutzeroberfläche "Abfrage erläutern"befinden, geben Sie die Abfrage ein und drücken Sie 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 vor der Ausführung der Abfrage zeigt auch die Dauer der Ausführung der Abfrage an. Die Anzahl der Include-Knoten -Option gibt die Anzahl der Knoten an. Der Bericht enthält weitere Informationen, die zur Optimierung der Indizes für Ihre Anwendung oder Bereitstellung verwendet werden können.

Der 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

Diese Aktion Trigger den Download einer ZIP-Datei mit nützlichen Informationen zum Systemstatus und zur Systemkonfiguration. 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-Sicherheitskopien) und wie viele Tage Protokolle im Download im Verhältnis zum aktuellen Datum enthalten sind.

Thread-Sicherheitskopie herunterladen

Diese Aktion Trigger den Download einer ZIP-Datei mit Informationen zu den im System vorhandenen Threads. Es werden Informationen zu jedem Thread bereitgestellt, wie z. B. sein Status, der Classloader und der Stacktrace.

Stapel-Sicherheitskopie herunterladen

Sie können einen Schnappschuss des Heap herunterladen, um ihn später zu analysieren. Diese Aktion Trigger den Download einer großen (Hunderte von Megabyte) Datei.

Automatisierte Wartungsaufgaben

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.

Rufen Sie die Seite "Wartung"im Vorgangs-Dashboard im Begrüßungsbildschirm des AEM auf: Tools - Vorgänge - Dashboard - Wartung oder direkt diesem Link folgen:

https://serveraddress:port/libs/granite/operations/content/maintenance.html

Die folgenden Aufgaben sind im Vorgangs-Dashboard verfügbar:

1. die Aufgabe Revisionsbereinigung, zu finden im Menü Tägliches Wartungsfenster
2. die Aufgabe Lucene-Binärdateien-Bereinigung, zu finden im Menü Tägliches Wartungsfenster
3. die Aufgabe Workflow-Bereinigung, zu finden im Menü Wöchentliches Wartungsfenster
4. die Aufgabe Datenspeicherbereinigung, zu finden im Menü Wöchentliches Wartungsfenster
5. die Wartungsaufgabe Auditprotokoll, zu finden im Menü Wöchentliches Wartungsfenster
6. 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. Die für die Ausführung im wöchentlichen Wartungsfenster konfigurierten Aufgaben laufen samstags zwischen 1:00 Uhr und 2:00 Uhr.

Sie können die Timings auch konfigurieren, indem Sie auf einer der beiden Wartungskarten auf das Zahnradsymbol klicken:

Revisionsbereinigung

Weitere Informationen zur Durchführung der Revisionsbereinigung finden Sie unter finden Sie in diesem speziellen Artikel.

Lucene-Binärdateien-Bereinigung

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. Die binäre Abwanderung von Lucene wird täglich anstelle der früheren Abhängigkeit von einer erfolgreichen Speicherbereinigung ausführen.

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 automatischen Datenspeicherbereinigung kann schneller abgeschlossen werden.
• Es kann auch die Gesamtleistung der AEM leicht verbessern.

Die Aufgabe „Lucene-Binärdateien-Bereinigung“ finden Sie unter AEM > Tools > Vorgänge > Wartung > Tägliches Wartungsfenster > Lucene-Binärdateien-Bereinigung.

Datenspeicherbereinigung

Weitere Informationen zur automatischen Datenspeicherbereinigung finden Sie in der entsprechenden Dokumentationsseite.

Workflow-Bereinigung

Workflows können auch über das Wartungs-Dashboard bereinigt werden. Gehen Sie wie folgt vor, um die Aufgabe "Workflow-Bereinigung"auszuführen:

1. Klicken Sie auf Wöchentliches Wartungsfenster Seite.
2. Klicken Sie auf der folgenden Seite auf Play im Workflow-Bereinigung Karte.

Auditprotokoll-Wartung

Informationen zur Auditprotokoll-Wartung finden Sie auf der entsprechenden Dokumentationsseite.

Versionsbereinigung

Sie können die Wartungsaufgabe zur Versionsbereinigung planen, um alte Versionen automatisch zu löschen. Diese Aktion minimiert die Notwendigkeit, die Tools zur Versionsbereinigung. Um die Versionsbereinigung zu planen und zu konfigurieren, führen Sie unter Tools > Vorgänge > Wartung > Wöchentliches Wartungsfenster die folgenden Schritte durch:

1. Klicken Sie auf Hinzufügen.

2. Wählen Sie aus dem Dropdown-Menü Versionsbereinigung aus.

   

3. Um die Versionsbereinigung zu konfigurieren, klicken Sie auf das Zahnräder auf der neu erstellten Versionsbereinigungs-Wartungskarte.

   

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

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 implementieren [org.apache.sling.event.jobs.consumer.JobExecutor](https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/consumer/JobExecutor.html). Um als Wartungsaufgabe erkannt zu werden, muss sie zusätzlich mehrere Dienstregistrierungseigenschaften festlegen, wie nachfolgend aufgeführt:

Neben den oben genannten Diensteigenschaften wird die process() -Methode JobConsumer -Schnittstelle implementiert werden, indem der Code hinzugefügt wird, 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).

In Situationen, in denen eine Wartungsaufgabe nicht auf allen Installationen ausgeführt werden sollte (z. B. nur auf der Veröffentlichungsinstanz), können Sie den Dienst so einrichten, dass eine Konfiguration aktiv sein muss, indem Sie @Component(policy=ConfigurationPolicy.REQUIRE). 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

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:

Durch diese Aktion wird die entsprechende Ressource unter /apps/granite/operations/config/maintenance/ hinzugefügt.schedule/taskname. 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

Die Dashboard "Systemübersicht" zeigt einen allgemeinen Überblick über die Konfiguration, Hardware und den Zustand der AEM Instanz. Der Systemzustand ist transparent und alle Informationen werden in einem Dashboard zusammengefasst.

Zugriff

Um auf das Systemübersicht-Dashboard zuzugreifen, gehen Sie zu Tools > Vorgänge > Systemübersicht.

Dashboard "Systemübersicht" - Erklärung

In der folgenden Tabelle werden alle im Dashboard "Systemübersicht"angezeigten Informationen beschrieben. Wenn keine relevanten Informationen angezeigt werden (z. B. wird keine Sicherung durchgeführt, es gibt keine kritischen Konsistenzprüfungen), zeigt der entsprechende Abschnitt die Meldung "Keine Einträge"an.

Sie können auch eine JSON Datei, in der die Dashboard-Informationen durch Klicken auf die Download in der oberen rechten Ecke des Dashboards. Die JSON Endpunkt ist /libs/granite/operations/content/systemoverview/export.json und kann in einer curl Skript für die externe Überwachung.

Ressourcen für Business.Adobe.com

Auto Form Fill Asset Collections Embedded Charts Mobile Forms Theme Editor Version History