Show Menu
THEMEN×

Vorgangs-Dashboard

Einführung

Mit dem Vorgangs-Dashboard in AEM 6 können Systemoperatoren auf einen Blick die AEM-Systemkonsistenz berwachen. Es bietet außerdem automatisch generierte Diagnoseinformationen zu relevanten Aspekten von AEM und ermöglicht die Konfiguration und Ausführung der selbstständigen Wartungsautomatisierung, um den Projektbetrieb und Unterstützungsfälle erheblich zu reduzieren. Sie können das Vorgangs-Dashboard durch benutzerdefinierte Konsistenzprüfungen und Wartungsaufgaben erweitern. Und über JMX können Sie von externen Überwachungstools auf die Daten des Vorgangs-Dashboards zugreifen.
Das Vorgangs-Dashboard:
  • 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
It can be accessed by going to Tools - Operations from the AEM Welcome screen.
Um auf das Vorgangs-Dashboard zugreifen zu können, muss der angemeldete Benutzer zur Benutzergruppe „Operatoren“ gehören. Weitere Informationen finden Sie in der Dokumentation zu Verwaltung von Benutzern, Gruppen und Zugriffsrechten .

Konsistenzberichte

Das Konsistenzberichtssystem stellt Informationen zum Zustand einer AEM-Instanz durch Sling-Konsistenzprüfungen bereit. Dies erfolgt entweder über OSGi-, JMX- oder HTTP-Abfragen (über JSON) oder über die Touch-optimierte Benutzeroberfläche. Das System bietet Messungen und Schwellenwerte bestimmter konfigurierbarer Zähler und stellt in einigen Fällen Informationen zur Fehlerbehebung bereit.
Es umfasst mehrere Funktionen, die unten beschrieben werden.

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.
The Health Reports interface can be accessed through the Tools - Operations - Health Reports menu on the AEM Welcome screen, or directly through the following URL:
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     
        }
     }
    
    
    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
    The resource path above is created as follows: if the mbean name of your Health Check is "test", add "test" to the end of the path /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck
    Der endgültige Pfad lautet also:
    /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/test
    Make sure that the /apps/settings/granite/operations/hc path has the following properties set to true:
    sling:configCollectionInherit
    sling:configPropertyInherit
    This will tell the configuration manager to merge the new configurations with the existing ones from /libs .

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-Konfigurationsmanager in der OSGi-Konsole. You can do this by accessing https://serveraddress:port/system/console/configMgr
  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 ).
    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 in den Konfigurationsknoten des Vorgangs-Dashboards hinzufügen. The procedure for this is the same as with individual health checks: a node of type nt:unstructured needs to be created under /apps/settings/granite/operations/hc . 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
    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

Name der Konsistenzprüfung Beschreibung
Abfrageleistung
This health check was simplified in AEM 6.4 , and now checks the recently-refactored Oak QueryStats MBean, more specifically the SlowQueries attribute. Wenn die Statistik eine langsame Abfrage enthält, gibt die Konsistenzprüfung eine Warnung zurück. Andernfalls meldet sie den Status „OK“.
Länge der Überwachungswarteschlange
Observation Queue Length iterates over all Event Listeners and Background Observers, compares their queueSize to their maxQueueSize and:
  • returns Critical status if the queueSize value exceeds the maxQueueSize value (that is when events would be dropped)
  • returns Warn if the queueSize value is over the maxQueueSize * WARN_THRESHOLD (the default value is 0.75)
Die Höchstlänge jeder Warteschlange wird in separaten Konfigurationen (Oak und AEM) festgelegt und kann nicht über diese Konsistenzprüfung konfiguriert werden. The MBean for this health check is org.apache.sling.healthcheck:name=ObservationQueueLengthHealthCheck,type=HealthCheck .
Abfrage-Ausnahmelimits
Query Traversal Limits checks the QueryEngineSettings MBean, more specifically the LimitInMemory and LimitReads attributes, and returns the following status:
  • gibt den Warn-Status zurück, wenn einer der Beschränkungen gleich oder höher als der Wert Integer.MAX_VALUE
  • den Warnungsstatus, wenn eines der Limits kleiner als 10.000 (die empfohlene Einstellung von Oak) ist
  • returns the Critical status if the QueryEngineSettings or any of the limits cannot be retrieved
Synchronisierte Uhren
This check is relevant only for document nodestore clusters . Sie gibt den folgenden Status zurück:
  • den Warnungsstatus, wenn die Instanzuhren nicht mehr synchronisiert sind und einen vorab definierten unteren Schwellenwert übersteigen
  • den Status „Kritisch“, wenn die Instanzuhren nicht mehr synchronisiert sind und einen vorab definierten oberen Schwellenwert übersteigen
Asynchrone Indexizes
Die Prüfung auf asynchrone Indizes
  • gibt den Status „Kritisch“ zurück, wenn mindestens eine Indizierungsspur fehlschlägt
  • checks the lastIndexedTime for all indexing lanes and:
    • gibt den Status „Kritisch“ zurück, wenn die Zeit mehr als 2 Stunden zurückliegt
    • gibt den Warnungsstatus zurück, wenn sie zwischen 2 Stunden und 45 Minuten zurückliegt
    • gibt den Status „OK“ zurück, wenn sie weniger als 45 Minuten zurückliegt
  • gibt den Status „OK“ zurück, wenn keine dieser Bedingungen zutrifft
Die Schwellenwerte für „Kritisch“ und „Warnung“ sind konfigurierbar. The Mbean for this health check is org.apache.sling.healthcheck:name=asyncIndexHealthCheck,type=HealthCheck .
Hinweis: Dieser Health Check ist mit AEM 6.4 verfügbar und wurde auf AEM 6.3.0.1 zurückportiert.
Große Lucene-Indizes
This check uses the data exposed by the Lucene Index Statistics MBean to identify large indexes and returns:
  • gibt einen Warnungsstatus zurück, wenn es einen Index mit mehr als 1 Mrd. Dokumenten gibt
  • gibt den Status „Kritisch“ zurück, wenn es einen Index mit mehr als 1,5 Mrd. Dokumenten gibt
The thresholds are configurable and the MBean for the health check is org.apache.sling.healthcheck:name=largeIndexHealthCheck,type=HealthCheck.
Hinweis: Diese Prüfung ist in AEM 6.4 und als Backport in AEM 6.3.2.0 verfügbar.
Systemwartung
Die Systemwartung ist eine Verbund-Zustandsprüfung, die den Status „OK“ zurückgibt, wenn alle Wartungsaufgaben wie konfiguriert ausgeführt werden. Bedenken Sie Folgendes:
  • jeder Instandhaltungsaufgabe eine damit verbundene Gesundheitskontrolle
  • Wenn eine Aufgabe nicht zu einem Wartungsfenster hinzugefügt wird, gibt ihre Konsistenzprüfung „Kritisch“ zurück.
  • Sie müssen die Wartungsaufgaben „Auditprotokoll“ und „Workflow-Bereinigung“ konfigurieren oder aus den Wartungsfenstern entfernen. Wenn diese Aufgaben nicht konfiguriert sind, schlagen sie beim Ausführungsversuch fehl, sodass die Systemwartungsprüfung den Status „Kritisch“ zurückgibt.
  • In AEM 6.4 gibt es auch eine Prüfung für die Aufgabe Lucene Binaries Maintenance .
  • In AEM 6.2 und früher gibt die Systemwartungsprüfung einen Warnungsstatus direkt nach dem Start aus, da die Aufgaben nie ausgeführt werden. Ab Version 6.3 wird der Status „OK“ zurückgegeben, wenn das erste Wartungsfenster noch nicht erreicht wurde.
Replikations-Warteschlange
Diese Prüfung wird bei den Replikationsagenten durchgeführt und prüft deren Warteschlangen. Beim vordersten Element in der Warteschlange ermittelt die Prüfung, wie häufig der Agent die Replikation versucht hat. Wenn diese Anzahl größer ist als der Wert des Parameters numberOfRetriesAllowed , wird eine Warnung zurückgegeben. The numberOfRetriesAllowed parameter is configurable.
Sling-Aufträge
Sling Jobs checks the number of jobs queued in the JobManager, compares it to the maxNumQueueJobs threshold, and:
  • returns Critical if more than the maxNumQueueJobs are in the queue
  • gibt den Status „Kritisch“ zurück, wenn es aktive Aufträge gibt, die seit mehr als einer Stunde ausgeführt werden
  • gibt den Status „Kritisch“ zurück, wenn es Aufträge in der Warteschlange gibt und der letzte abgeschlossene Auftrag länger als 1 Stunde zurückliegt
Nur der Parameter für die Höchstzahl an Aufträgen in der Warteschlange ist konfigurierbar. Sein Standardwert ist 1.000.
Anforderungsleistung
This check looks at the granite.request.metrics.timer Sling metric and:
  • gibt den Status „Kritisch“ zurück, wenn der 75. Perzentilwert über dem Schwellenwert für „Kritisch“ liegt (der Standardwert beträgt 500 Millisekunden)
  • gibt eine Warnung zurück, wenn der 75. Perzentilwert über dem Warnungs-Schwellenwert liegt (der Standardwert beträgt 200 Millisekunden)
Fehlerprotokoll
Diese Prüfung gibt eine Warnung zurück, wenn Fehler im Protokoll vorliegen.
Festplattenspeicher
The Disk Space check looks at the FileStoreStats MBean, retrieves the size of the Node Store and the amount of usable disk space on the Node Store partition, and:
  • gibt eine Warnung zurück, wenn das Verhältnis zwischen verfügbarem Festplatten-Speicherplatz und Repository-Größe unter dem Warnungs-Schwellenwert liegt (der Standardwert ist 10)
  • gibt den Status „Kritisch“ zurück, wenn das Verhältnis zwischen verfügbarem Festplatten-Speicherplatz und Repository-Größe unter dem Schwellenwert für „Kritisch“ liegt (der Standardwert ist 2)
Beide Werte sind konfigurierbar. Die Prüfung funktioniert nur auf Instanzen mit einem Segmentspeicher.
Scheduler-Konsistenzprüfung
Diese Prüfung gibt eine Warnung zurück, wenn auf der Instanz länger als 60 Sekunden ein Quartz-Auftrag ausgeführt wird. Der Schwellenwert für die zulässige Dauer ist konfigurierbar.
Sicherheitsprüfungen
Die Sicherheitsprüfung ist eine Verbundprüfung, die die Ergebnisse mehrerer sicherheitsbezogener Prüfungen aggregiert. These individual health checks address different concerns from the security checklist available at the Security Checklist documentation page. Die Prüfung ist als Feuerprobe beim Start der Instanz nützlich.
Aktive Bundles
Diese Prüfung untersucht den Status aller Bundles und:
  • gibt eine Warnung zurück, wenn eines der Bundles nicht aktiv ist oder (gerade startet, mit Lazy-Aktivierung)
  • ignoriert den Status von Bundles aus der Ignorieren-Liste
Der Parameter der Ignorieren-Liste ist konfigurierbar.
Code-Cache-Prüfung
Diese Konsistenzprüfung überprüft mehrere JVM-Bedingungen, die einen Code-Cache-Bug in Java 7 auslösen können, und:
  • gibt eine Warnung zurück, wenn die Instanz auf Java 7 mit aktiviertem Code-Cache-Flushing ausgeführt wird
  • gibt eine Warnung zurück, wenn die Instanz auf Java 7 ausgeführt wird und der reservierte Code-Cache einen Mindestschwellenwert unterschreitet (der Standardwert liegt bei 90 MB)
The minimum.code.cache.size threshold is configurable. For more information about the bug, check view_bug.do?bug_id=8012547view_bug.do?bug_id=8012547 this page .
Ressourcen-Suchpfad-Fehler
Checks if there are any resources in the path /apps/foundation/components/primary and:
  • gibt Warn zurück, wenn untergeordnete Knoten unter /apps/foundation/components/primary

Ü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 Überwachungsserver.
  2. Installieren Sie anschließend den Nagios Remote Plugin Executor (NRPE).
    Informationen zur Installation von Nagios und NRPE auf Ihrem System finden Sie in der Nagios-Dokumentation .
  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-Konfigurationsmanager .
    4. Press the Hosts link under the Monitoring section.
    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-Analyzer für Anforderungen und Abfragen
Auf den Bildschirm „Diagnose-Tools“ können Sie über den AEM-Begrüßungsbildschirm über Tools > Vorgänge > Diagnose zugreifen. You can also access the screen by directly accessing the following URL: 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.
Sie können einen Logger-Namen nicht so festlegen, dass er nur FEHLER-Meldungen über einen festgelegten Filter erfasst. Standardmäßig werden alle FEHLER-Meldungen erfasst.
Die Protokollmeldungs-Benutzeroberfläche spiegelt nicht das tatsächliche Fehlerprotokoll wider. Sofern Sie keinen anderen Typen an Protokollmeldungen in der Benutzeroberfläche konfigurieren, werden nur FEHLER-Meldungen angezeigt. Anleitungen zum Anzeigen bestimmter Protokollmeldungen finden Sie oben.
Die Einstellungen auf der Diagnoseseite wirken sich nicht darauf aus, was in den Protokolldateien protokolliert wird, und umgekehrt. Wenn das Fehlerprotokoll also INFO-Meldungen erfasst, werden sie möglicherweise nicht in der Protokollmeldungs-Benutzeroberfläche angezeigt. Über die Benutzeroberfläche ist es auch möglich, DEBUGGING-Meldungen von bestimmten Paketen zu erfassen, ohne das Fehlerprotokoll zu beeinflussen. Weitere Informationen zum Konfigurieren der Protokolldateien finden Sie unter Protokollierung .
Mit AEM 6.4 werden Wartungsaufgaben auf INFO-Ebene im Format "Rich-Information"abgemeldet. Dieser Ansatz ermöglicht bessere Einblicke in den Status der Wartungsaufgaben.
Wenn Sie Drittanbietertools (wie Splunk) verwenden, um die Wartungsaufgaben-Aktivität zu überwachen und darauf zu reagieren, können Sie die folgenden Protokollanweisungen nutzen:
Log level: INFO
DATE+TIME [MaintanceLogger] Name=<MT_NAME>, Status=<MT_STATUS>, Time=<MT_TIME>, Error=<MT_ERROR>, Details=<MT_DETAILS>

Anforderungsleistung

Die Anforderungsleistungsseite ermöglicht die Analyse der langsamsten verarbeiteten Seitenabfragen. Nur Inhaltsabfragen werden auf dieser Seite registriert. Genauer gesagt, werden die folgenden Abfragen erfasst:
  1. Requests accessing resources under /content
  2. Requests accessing resources under /etc/design
  3. Requests having the ".html" extension
Die Seite zeigt Folgendes an:
  • die Zeit, zu der die Abfrage erfolgt ist
  • die URL und die Methode der Abfrage
  • die Dauer in Millisekunden
Standardmäßig werden die langsamsten 20 Seitenabfragen erfasst. Diesen Wert können Sie aber im Konfigurationsmanager ä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 dem Ausführen der Abfrage das Kontrollkästchen Ausführungsdauer einschließen aktivieren, wird auch die Zeitdauer angezeigt, in der die Abfrage ausgeführt wurde. So erhalten Sie mehr Informationen, die Sie zur Optimierung der Indizes für Ihre Anwendung oder Bereitstellung nutzen können.

Der Index-Manager

Der Index-Manager soll die Indexverwaltung vereinfachen, beispielsweise die Pflege der Indizes oder die Statusanzeige.
It can be accessed by going to Tools - Operations - Diagnosis ​from the Welcome Screen, and then clicking the Index Manager button.
It can also be accessed directly at this URL: 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 Bundles, OSGI, Sling-Metriken und Statistiken, was zu einer großen Datei führen kann. Sie können den Einfluss großer Statusdateien verringern, indem Sie das Fenster Download-Status-ZIP ​verwenden. The window can be accessed from: AEM > Tools > Operations > Diagnosis > Download Status ZIP.
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. The Revision Clean Up ​task, located under the Daily Maintenance Window menu.
  2. The Lucene Binaries Cleanup ​task, located under the Daily Maintenance Window menu.
  3. The Workflow purge ​task, located under the Weekly Maintenance Window menu.
  4. The Data Store Garbage Collection task, located under the Weekly Maintenance Window menu.
  5. The Audit Log Maintenance task, located under the Weekly Maintenance Window menu.
  6. The Version Purge Maintenance task, located under the Weekly Maintenance Window menu.
Die Standardzeit für das tägliche Wartungsfenster ist 02:00 bis 05:00 Uhr. Die Aufgaben, die für das Zeitfenster der wöchentlichen Wartung konfiguriert sind, werden an Samstagen zwischen 01:00 und 02:00 Uhr ausgeführt.
Sie können diese Zeiten auch konfigurieren. Klicken Sie dazu auf das Zahnradsymbol auf einer der beiden Wartungskarten:
Seit AEM 6.1 können Sie die vorhandenen Wartungsfenster auch für die monatliche Ausführung konfigurieren.

Revisionsbereinigung

Weitere Informationen zur Durchführung der Revisionsbereinigung in AEM 6.4 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. This is because the lucene's binary churn will be re-claimed daily instead of the earlier dependency on a successful data store garbage collection run.
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.
  • Es kann außerdem die Gesamtleistung von AEM leicht verbessern
You can access the Lucene Binaries Cleanup task from: AEM > Tools > Operations > Maintenance > Daily Maintenance Window > Lucene Binaries Cleanup .

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 .
Weitere Informationen zur Workflow-Wartung finden Sie auf dieser Seite .

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. As a result, this minimizes the need to manually use the Version Purge tools . You can schedule and configure the Version Purge task by accessing Tools > Operations > Maintenance > Weekly Maintenance Window and following these steps:
  1. Click the Add button.
  2. Choose Version Purge from the drop-down menu.
  3. To configure the Version Purge task, click on the gears icon on the newly created Version Purge maintenance card.
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.
  • Manually - To manually stop the task, on the Version Purge maintenance card, click the Stop icon. Bei der nächsten Ausführung wird die Aufgabe sicher fortgesetzt.
Das Anhalten der Wartungsaufgabe bedeutet, dass ihre Ausführung verschoben wird, ohne den Überblick über den aktuell bereits ausgeführten Auftrag zu verlieren.
Um die Größe des Repositorys zu optimieren, sollten Sie die Aufgabe zur Versionsbereinigung regelmäßig ausführen. Die Aufgabe sollte außerhalb der Geschäftszeiten geplant werden, wenn der Netzwerkverkehr begrenzt ist.

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:
Diensteigenschaftsname Beschreibung Beispiel Typ
granite.maintenance.isStoppable Boolesches Attribut, das definiert, ob die Aufgabe vom Benutzer gestoppt werden kann. Wenn eine Aufgabe festlegt, dass sie angehalten werden kann, muss sie während ihrer Ausführung prüfen, ob sie angehalten wurde, und dann entsprechend agieren. Der Standard lautet „false“. true Optional
granite.maintenance.mandatory Boolesches Attribut, das definiert, ob eine Aufgabe obligatorisch ist und regelmäßig ausgeführt werden muss. Wenn eine Aufgabe verpflichtend ist, sich aber aktuell in keinem aktiven Planungsfenster befindet, meldet eine Konsistenzprüfung dies als Fehler. Der Standard lautet „false“. true Optional
granite.maintenance.name Ein eindeutiger Name für die Aufgabe - dieser wird verwendet, um auf die Aufgabe zu verweisen. Dabei handelt es sich in der Regel um einen einfachen Namen. MyMaintenanceTask Erforderlich
granite.maintenance.title Ein Titel für diese Aufgabe wird angezeigt Meine besondere Wartungsaufgabe Erforderlich
job.topics Dies ist ein einzigartiges Thema der Wartungsaufgabe. Die Apache Sling-Auftragsverarbeitung startet einen Auftrag mit genau diesem Thema, um die Wartungsaufgabe auszuführen, und wenn die Aufgabe für dieses Thema registriert wird, wird sie ausgeführt. Das Thema muss mit com/adobe/granite/maintenance/job/ beginnen com/adobe/granite/maintenance/job/MyMaintenanceTask Erforderlich
Apart from the above service properties, the process() method of the JobConsumer interface needs to be implemented by adding the code that should be executed for the maintance task. 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).
For situations where a maintenance task should not be run on all installations (for example, run only on the publish instance), you can make the service require a configuration in order to be active by adding @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 .
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
/*
* #%L
* sample-maintenance-task
* %%
* Copyright (C) 2014 Adobe
* %%
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
* #L%
*/
package com.adobe.granite.samples.maintenance.impl;
import java.io.File;
import java.util.Calendar;
import java.util.Collection;
import java.util.Map;
import org.apache.commons.io.FileUtils;
import org.apache.commons.io.filefilter.IOFileFilter;
import org.apache.commons.io.filefilter.TrueFileFilter;
import org.apache.felix.scr.annotations.Activate;
import org.apache.felix.scr.annotations.Component;
import org.apache.felix.scr.annotations.Properties;
import org.apache.felix.scr.annotations.Property;
import org.apache.felix.scr.annotations.Service;
import org.apache.sling.commons.osgi.PropertiesUtil;
import org.apache.sling.event.jobs.Job;
import org.apache.sling.event.jobs.consumer.JobConsumer;
import org.apache.sling.event.jobs.consumer.JobExecutionContext;
import org.apache.sling.event.jobs.consumer.JobExecutionResult;
import org.apache.sling.event.jobs.consumer.JobExecutor;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import com.adobe.granite.maintenance.MaintenanceConstants;
@Component(metatype = true,
label = "Delete Temp Files Maintenance Task",
description = "Maintatence Task which deletes files from a configurable temporary directory which have been modified in the last 24 hours.")
@Service
@Properties({
@Property(name = MaintenanceConstants.PROPERTY_TASK_NAME, value = "DeleteTempFilesTask", propertyPrivate = true),
@Property(name = MaintenanceConstants.PROPERTY_TASK_TITLE, value = "Delete Temp Files", propertyPrivate = true),
@Property(name = JobConsumer.PROPERTY_TOPICS, value = MaintenanceConstants.TASK_TOPIC_PREFIX
+ "DeleteTempFilesTask", propertyPrivate = true) })
public class DeleteTempFilesTask implements JobExecutor {
private static final Logger log = LoggerFactory.getLogger(DeleteTempFilesTask.class);
@Property(label = "Temporary Directory", description="Temporary Directory. Defaults to the java.io.tmpdir system property.")
private static final String PROP_TEMP_DIR = "temp.dir";
private File tempDir;
@Activate
private void activate(Map<string, object=""> properties) {
this.tempDir = new File(PropertiesUtil.toString(properties.get(PROP_TEMP_DIR),
System.getProperty("java.io.tmpdir")));
}
@Override
public JobExecutionResult process(Job job, JobExecutionContext context) {
log.info("Deleting old temp files from {}.", tempDir.getAbsolutePath());
Collection<file> files = FileUtils.listFiles(tempDir, new LastModifiedBeforeYesterdayFilter(),
TrueFileFilter.INSTANCE);
int counter = 0;
for (File file : files) {
log.debug("Deleting file {}.", file.getAbsolutePath());
counter++;
file.delete();
// TODO - capture the output of delete() and do something useful with it
}
return context.result().message(String.format("Deleted %s files.", counter)).succeeded();
}
/**
* IOFileFilter which filters out files which have been modified in the last 24 hours.
*
*/
private static class LastModifiedBeforeYesterdayFilter implements IOFileFilter {
private final long minTime;
private LastModifiedBeforeYesterdayFilter() {
Calendar cal = Calendar.getInstance();
cal.add(Calendar.DATE, -1);
this.minTime = cal.getTimeInMillis();
}
@Override
public boolean accept(File dir, String name) {
// this method is never actually called.
return false;
}
@Override
public boolean accept(File file) {
return file.lastModified() <= this.minTime;
}
}
}
<file></string,>
Wenn der Dienst bereitgestellt wurde, wird er an die Benutzeroberfläche des Vorgangs-Dashboards übergeben und kann zu einem der verfügbaren Wartungszeitpläne hinzugefügt werden:
This will add a corresponding resource at /apps/granite/operations/config/maintenance/ schedule / taskname . 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

The System Overview Dashboard displays a high-level overview of the configuration, hardware and health of the AEM instance. Der Status der Systemkonsistenz ist also transparent und alle entsprechenden Daten werden auf einem zentralen Dashboard zusammengeführt.
You can also watch this video for an introduction to the System Overview Dashboard.

Zugriff

To access the System Overview Dashboard, navigate to Tools > Operations > System Overview .

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.
You can also download a JSON file summarizing the dashboard information by clicking the Download button in the upper right-hand corner of the dashboard.The JSON endpoint is /libs/granite/operations/content/systemoverview/export.json and it can be used in a curl script for external monitoring.
Abschnitt Angezeigte Informationen Wann liegt ein kritischer Status vor Ist verknüpft mit
Konsistenzprüfungen
  • eine Liste der Prüfungen mit dem Status „kritisch“
  • eine Liste der Prüfungen mit dem Status „Warnung“
Visueller Hinweis:
  • ein rotes Tag für den Status „kritisch“
  • ein orangefarbenes Tag für den Status „Warnung“
  • Seite „Konsistenzberichte“
Wartungsaufgaben
  • eine Liste der fehlgeschlagenen Aufgaben
  • eine Liste der Aufgaben, die gerade ausgeführt werden
  • eine Liste der Aufgaben, deren letzte Ausführung erfolgreich war
  • eine Liste der Aufgaben, die nie ausgeführt wurden
  • eine Liste der Aufgaben, die nicht geplant sind
Visueller Hinweis:
  • ein rotes Tag für fehlgeschlagene Aufgaben
  • ein orangefarbenes Tag für Aufgaben, die gerade ausgeführt werden (da sie die Leistung beeinträchtigen könnten)
  • graue Tags für alle anderen Status
  • Seite „Wartungsaufgaben“
System
  • Betriebssystem und Version des Betriebssystems (z. B. Mac OS X)
  • system load average, as retrieved from OperatingSystemMXBeanusable
  • Festplattenspeicherplatz (auf der Partition, auf der sich das Basisverzeichnis befindet)
  • maximum heap, as returned by MemoryMXBean
Nicht zutreffend Nicht zutreffend
Instanz
  • AEM-Version
  • Liste der Ausführungsmodi
  • Datum, an dem die Instanz gestartet wurde
Nicht zutreffend Nicht zutreffend
Repository
  • Oak-Version
  • Typ des NodeStores („Segment-TAR“ oder „Dokument“)
    • Beim Typ „Dokument“ wird der Typ des Dokumentenspeichers angezeigt (RDB oder Mongo)
  • Wenn ein benutzerdefinierter Datenspeicher vorhanden ist:
    • Bei einem Dateidatenspeicher wird der Pfad angezeigt
    • Bei einem S3-Datenspeicher wird der Name des S3-Buckets angezeigt.
    • Bei einem freigegebenen S3-Datenspeicher wird der Name des S3-Buckets angezeigt.
    • Bei einem Azure-Datenspeicher wird der Container angezeigt
  • Wenn es keinen benutzerdefinierten externen Datenspeicher gibt, wird eine entsprechende Meldung angezeigt.
Nicht zutreffend Nicht zutreffend
Verteilungsagenten
  • eine Liste der Agenten mit gesperrten Warteschlangen
  • eine Liste der falsch konfigurierten Agenten („Konfigurationsfehler“)
  • eine Liste der Agenten, bei denen die Warteschlangenverarbeitung angehalten wurde
  • eine Liste der inaktiven Agenten
  • eine Liste der ausgeführten Agenten (die gerade Einträge verarbeiten)
Visueller Hinweis:
  • ein rotes Tag für gesperrte Agenten oder Konfigurationsfehler
  • ein orangefarbenes Tag für pausierte Agenten
  • ein graues Tag für pausierte, inaktive oder ausgeführte Agenten
Seite „Verteilung“
Replikationsagenten
  • eine Liste der Agenten mit gesperrten Warteschlangen
  • eine Liste der inaktiven Agenten
  • eine Liste der ausgeführten Agenten (die gerade Einträge verarbeiten)
Visueller Hinweis:
  • ein rotes Tag für gesperrte Agenten
  • ein graues Tag für pausierte Agenten
Seite „Replikation“
Workflows
  • Workflow-Aufträge:
    • Anzahl an fehlgeschlagenen Workflow-Aufträgen (falls vorhanden)
    • Anzahl der abgebrochenen Workflow-Aufträge (falls vorhanden)
  • Workflow-Zählungen - Anzahl der Workflows in einem gegebenen Status (sofern vorhanden):
    • wird ausgeführt
    • fehlgeschlagen
    • unterbrochen
    • abgebrochen
Für jeden der o. g. Status wird eine Abfrage durchgeführt, mit einem Limit von 400 Millisekunden. Bei 400 Millisekunden wird die Anzahl der bis dahin erfassten Einträge angezeigt.
Nicht interpretiert:
  • Der Benutzer muss eine Untersuchung vornehmen, wenn ein unerwarteter Status bei Workflows und Aufträgen vorliegt.
Seite „Workflow-Fehler“
Sling-Aufträge
Anzahl an Sling-Aufträgen – Anzahl an Aufträgen in einem bestimmten Status (falls vorhanden):
  • fehlgeschlagen
  • in der Warteschlange
  • abgebrochen
  • aktiv
Nicht interpretiert:
  • Der Benutzer muss eine Untersuchung vornehmen, wenn ein unerwarteter Status bei Aufträgen vorliegt oder eine hohe Anzahl angezeigt wird.
Nicht zutreffend
Voraussichtliche Knotenanzahl
Voraussichtliche Anzahl an:
  • Seiten
  • Assets
  • Tags
  • Autorisierte
  • Gesamtzahl an Knoten
Die Gesamtanzahl der Knoten wird vom Knoten nodeCounterMBean bezogen, während der Rest der Statistik von IndexInfoService abgerufen wird.
Nicht zutreffend Nicht zutreffend
Sicherung Zeigt ggf. „Online-Sicherung wird ausgeführt“ an. Nicht zutreffend Nicht zutreffend
Indizierung
Displays:
  • „Indizierung wird ausgeführt“
  • „Abfrage wird durchgeführt“
Wenn ein Indizierungs- oder Abfrage-Thread in der Thread-Sicherheitskopie vorhanden ist
Nicht zutreffend Nicht zutreffend