Vorgangs-Dashboard

Einführung

Mit dem Vorgangs-Dashboard in AEM 6 können Systemoperatoren auf einen Blick die AEM-Systemkonsistenz 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. 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:

• bietet mit einem Mausklick Informationen zum Systemstatus, um die Effizienz der Betriebsabteilung zu erhöhen
• stellt einen zentralen Überblick über die Systemkonsistenz bereit
• verringert den Zeitaufwand für das Erkennen, Analysieren und Beheben von Fehlern
• bietet eigenständige Wartungsautomatisierung, die die Projektbetriebskosten deutlich senkt

Sie können auf dem AEM-Begrüßungsbildschirm über Tools > Vorgänge auf das Dashboard zugreifen.

Konsistenzberichte

Das Konsistenzberichtssystem stellt Informationen zum Zustand einer AEM-Instanz durch Sling-Konsistenzprüfungen bereit. Dies erfolgt entweder über OSGi-, JMX- oder HTTP-Anfragen (ü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.

Konsistenzprüfungen

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.

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üfungsarten

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

1. Individuelle Konsistenzprüfungen
2. 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 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.

Erstellen von Konsistenzprüfungen

Im Vorgangs-Dashboard können Sie die Ergebnisse von individuellen wie Verbund-Konsistenzprüfung visuell darstellen.

Erstellen einer individuellen Konsistenzprüfung

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.

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

   HINWEIS

   Die Eigenschaft MBEAN_NAME definiert den Namen des MBean, die für diese Konsistenzprüfung erstellt wird.

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

     • 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

   Dadurch weiß der Konfigurations-Manager, dass die neuen Konfigurationen mit den vorhandenen aus /libs zusammengeführt werden sollen.

Erstellen einer Verbund-Konsistenzprüfung

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.

1. Wechseln Sie zum Web-Konfigurations-Manager in der OSGi-Konsole. Sie können dies tun, indem Sie https://serveraddress:port/system/console/configMgr aufrufen.

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

3. Um eine neue Konfiguration zu erstellen, klicken Sie auf das Pluszeichen (+) rechts neben der Konfiguration. Ein neues Fenster wird geöffnet, wie unten abgebildet:

   

4. 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. Ein aussagekräftiger Name ist empfehlenswert.
   • Tags (hc.tags): Die Tags für diese Konsistenzprüfung. Wenn diese Verbund-Konsistenzprüfung Teil einer weiteren Verbund-Konsistenzprüfung sein soll (z. B. in einer Hierarchie an Konsistenzprüfungen), fügen Sie die Tags hinzu, zu denen diese Prüfung gehört.
   • MBean-Name (hc.mbean.name): Der Name des MBeans, das an das JMX-MBean dieser Verbund-Konsistenzprüfung übergeben wird.
   • Filter-Tags (filter.tags): Diese Eigenschaft ist speziell für Verbund-Konsistenzprüfung. Dies sind die Tags, die die Verbund-Zustandsprüfung aggregieren soll. Die Verbund-Konsistenzprüfung aggregiert unter ihrer Gruppe alle Konsistenzprüfungen mit Tags, die einem der Filter-Tags dieser Verbund-Konsistenzprüfung entsprechen. 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).
   HINWEIS

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

5. 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/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

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

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

1. Installieren und konfigurieren Sie Nagios auf dem Überwachungs-Server.

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

   HINWEIS

   Informationen zur Installation von Nagios und NRPE auf Ihrem System finden Sie in der Nagios-Dokumentation.

3. Fügen Sie eine Hostdefinition hinzu. Dies ist mit dem Konfigurationsmanager der Nagios XI-Weboberfläche möglich:

   1. Öffnen Sie einen Browser und rufen Sie den Nagios-Server auf.
   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 das Plug-in check_http_json 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 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:

• ein Protokollmeldungs-Analyzer
• Zugriff auf Stapel- 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 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.

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. Nur Inhaltsanfragen werden auf dieser Seite registriert. Genauer gesagt, 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 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

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:

• die Zeit, zu der die Abfrage erfolgt ist
• die Sprache der Abfrage
• die Anzahl, wie häufig die Abfrage herausgegeben 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 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

• 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
• Meldung des Oak-Index, der zur Ausführung der Abfrage genutzt wird
• Anzeige der Erklärung der tatsächlichen Oak-Abfrage-Engine
• Bereitstellung einer Liste der langsamen und häufigen Abfragen, die auf Mausklick geladen wird

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 der Ausführung der Abfrage das Kästchen Ausführungszeit einbeziehen markieren, wird auch die Zeit angezeigt, in der die Abfrage ausgeführt wurde. Mit der Option Knotenanzahl einbeziehen wird die Knotenanzahl angezeigt. Diese ermöglichen weitere Informationen, die zur Optimierung der Indizes für Ihre Anwendung oder Implementierung verwendet werden können.

Der Index-Manager

Der Index-Manager soll die Indexverwaltung vereinfachen, beispielsweise die Pflege der Indizes oder die 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

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

Status-ZIP herunterladen

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 Paketen, OSGi, Sling-Metriken und Statistiken. Es kann sich daher um eine große Datei handeln. 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 oder andere Thread-Sicherheitskopien) und wie viele Tage von Protokollen im Download im Verhältnis zum aktuellen Datum enthalten sein sollen.

Thread-Sicherheitskopie herunterladen

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.

Heap-Sicherheitskopie herunterladen

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.

Automatisierte Wartungsaufgaben

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:

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

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:

Revisionsbereinigung

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

Lucene-Binärdateien-Bereinigung

Mit dieser Aufgabe können Sie Lucene-Binärdateien bereinigen und die Anforderungen an die Größe des ausgeführten Datenspeichers verringern. 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.

Zwar wurde die Wartungsaufgabe entwickelt, um Lucene-Revisions-Garbage zu verringern, aber ihre Ausführung verbessert auch allgemein die Effizienz:

• Die wöchentliche Ausführung der Datenspeicherbereinigung 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

Detaillierte Informationen zur Datenspeicherbereinigung finden Sie auf der entsprechenden Dokumentationsseite.

Workflow-Bereinigung

Sie können Workflows auch über das Wartungs-Dashboard bereinigen. Führen Sie dazu folgende Schritte durch:

1. Klicken Sie auf die Seite Wöchentliches Wartungsfenster.
2. Klicken Sie auf der folgenden Seite auf die Schaltfläche Wiedergabe auf der Karte Workflow-Bereinigung.

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

1. Klicken Sie auf die Schaltfläche Hinzufügen.

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

   

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

   

In AEM 6.4 können Sie die Versionsbereinigung wie folgt anhalten:

• Automatisch – Wenn das geplante Wartungsfenster abläuft, bevor die Aufgabe abgeschlossen ist, 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 [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.

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

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

Systemübersicht

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

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

Erläuterung zum Systemübersicht-Dashboard

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

Ressourcen für Business.Adobe.com

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