Aus Sicht von Adobe Experience Manager (AEM) Assets sollte die Überwachung das Beobachten und das Erstellen von Berichten für die folgenden Prozesse und Technologien umfassen:
System-CPU
Systemspeicherauslastung
I/O-Vorgänge und -Wartezeit des Systemdatenträgers
I/O-Vorgänge des Systemnetzwerks
JMX MBeans für:
Integritätsprüfungen der OSGi-Konsole
Normalerweise kann die Überwachung in AEM Assets auf zwei Arten durchgeführt werden: Live-Überwachung und Langzeitüberwachung.
Es ist ratsam, die Live-Überwachung während der Leistungstestphase Ihres Entwicklungsprozesses oder in Situationen mit hoher Auslastung durchzuführen, um sich mit den Leistungsmerkmalen Ihrer Umgebung vertraut zu machen. Normalerweise sollte für die Live-Überwachung eine Tool-Suite eingesetzt werden. Einige Empfehlungen:
Visual VM: Mit Visual VM können Sie detaillierte Java-VM-Informationen, einschließlich CPU-Auslastung und Java-Speicherbelegung, Ansicht werden. Außerdem können Sie Code prüfen und auswerten, der auf einer Instanz ausgeführt wird.
Top: „Top“ ist ein Linux-Befehl zum Öffnen eines Dashboards, in dem Auslastungsstatistiken angezeigt werden, z. B. zur CPU-, Arbeitsspeicher- und I/O-Auslastung. Darin können Sie sich einen allgemeinen Überblick über die Vorgänge auf einer Instanz verschaffen.
Htop: „Htop“ ist ein interaktives Anzeigeprogramm für Prozesse. Es enthält ausführliche Informationen zur Auslastung von CPU und Arbeitsspeicher, die über die Informationen von „Top“ hinausgehen. Htop kann auf den meisten Linux-Systemen mit yum install htop
oder apt-get install htop
installiert werden.
Iotop: „Iotop“ ist ein ausführliches Dashboard für die I/O-Auslastung von Datenträgern. Darin werden anhand von Balken und Anzeigen die Prozesse, für die Datenträger-I/O-Vorgänge genutzt werden, sowie die verwendete Menge dargestellt. Iotop kann auf den meisten Linux-Systemen mit yum install iotop
oder apt-get install iotop
installiert werden.
Iftop: Mit „Iftop“ werden ausführliche Informationen zur Ethernet-/Netzwerkauslastung angezeigt. Es werden Statistiken pro Kommunikationskanal auf den Entitäten zur Ethernet-Verwendung und zur genutzten Bandbreite angegeben. Iftop kann auf den meisten Linux-Systemen mit yum install iftop
oder apt-get install iftop
installiert werden.
Java Flight Recorder (JFR): Ein kommerzielles Tool von Oracle, das Sie in Umgebungen, die nicht für die Produktion bestimmt sind, kostenlos nutzen können. Weitere Informationen finden Sie unter So verwenden Sie Java-Flugschreiber zur Diagnose von CQ-Laufzeitproblemen.
AEM-Datei „error.log“: Sie können die AEM-Datei „error.log“ nach Details zu Fehlern durchsuchen, die im System protokolliert wurden. Verwenden Sie den Befehl tail -F quickstart/logs/error.log
, um Fehler zu identifizieren, die Sie untersuchen sollten.
Workflow-Konsole: Nutzen Sie die Workflow-Konsole, um Workflows zu überwachen, die Verzögerungen aufweisen oder hängen.
Normalerweise verwenden Sie diese Tools zusammen, um sich einen umfassenden Überblick über die Leistung Ihrer AEM-Instanz zu verschaffen.
Dies sind Standardtools ohne direkte Unterstützung durch Adobe. Hierfür sind keine zusätzlichen Lizenzen erforderlich.
Bei der Langzeitüberwachung einer AEM-Instanz werden die gleichen Komponenten, die live überwacht werden, auch über einen längeren Zeitraum überwacht. Außerdem werden Warnungen definiert, die speziell auf Ihre Umgebung zugeschnitten sind.
Es sind mehrere Tools zum Aggregieren von Protokollen verfügbar, z. B. Splunk™ und Elastic Search/Logstash/Kabana (ELK). Zum Auswerten der Betriebszeit Ihrer AEM-Instanz ist es wichtig, dass Sie mit den jeweiligen Protokollereignissen Ihres Systems vertraut sind und basierend darauf Warnungen erstellen. Eine gute Kenntnis Ihrer Entwicklungs- und Betriebspraktiken kann Ihnen helfen, besser zu verstehen, wie Sie Ihren Protokollaggregationsprozess zur Generierung kritischer Warnungen optimieren.
Die Umgebungsüberwachung umfasst die Überwachung der folgenden Punkte:
Sie benötigen externe Tools, z. B. NewRelic™ und AppDynamics™, um die einzelnen Elemente zu überwachen. Mit diesen Tools können Sie spezifische Warnungen für Ihr System generieren, z. B. für hohe Systemauslastung, Workflow-Stau, Fehler bei Integritätsprüfungen oder nicht authentifizierten Zugriff auf Ihre Website. Adobe spricht keinerlei Empfehlungen für bestimmte Tools aus. Ermitteln Sie, welches Tool für Ihre Zwecke am besten geeignet ist, und setzen Sie es dann ein, um die erwähnten Punkte zu überwachen.
Die interne Anwendungsüberwachung umfasst das Überwachen der Anwendungskomponenten, aus denen der AEM-Stapel besteht, z. B. JVM, das Inhaltsrepository und die Überwachung mit benutzerdefiniertem Anwendungscode, der auf der Plattform erstellt wird. Im Allgemeinen wird dies mithilfe von JMX MBeans durchgeführt, die mit vielen beliebten Überwachungslösungen, z. B. SolarWinds ™, HP OpenView™, Hyperic™, Zabbix™ und anderen, direkt überwacht werden können. Für Systeme, für die keine direkte Verbindung mit JMX unterstützt wird, können Sie Shell-Skripte schreiben, um die JMX-Daten zu extrahieren und für diese Systeme in einem Format verfügbar zu machen, das nativ verstanden wird.
Der Remotezugriff auf die JMX MBeans ist standardmäßig nicht aktiviert. Weitere Informationen zur Überwachung per JMX finden Sie unter Überwachung und Verwaltung per JMX-Technologie.
In vielen Fällen ist für das effektive Überwachen eines statistischen Werts ein Ausgangswert (Baseline) erforderlich. Zum Erstellen einer Baseline beobachten Sie das System über einen bestimmten Zeitraum unter normalen Arbeitsbedingungen und ermitteln dann die Metrik für diesen Normalfall.
JVM-Überwachung
Wie alle Java-basierten Anwendungsstapel ist auch AEM von den Ressourcen abhängig, die über die zugrunde liegende Java Virtual Machine bereitgestellt werden. Sie können den Status von vielen dieser Ressourcen über Platform MXBeans überwachen, die per JVM verfügbar gemacht werden. Weitere Informationen zu MXBeans finden Sie unter Verwenden von Platform MBean Server und Platform MXBeans.
Hier sind einige Baselineparameter angegeben, die Sie für JVM überwachen können:
Arbeitsspeicher
MBean: lava.lang:type=Memory
Hinweis: Die von diesem Bean-Element gelieferten Informationen werden in Byte ausgedrückt.
Threads
java.lang:type=Threading
AEM-Überwachung
AEM stellt über JMX auch einen Satz mit Statistiken und Vorgängen bereit. Diese Daten können dazu beitragen, die Systemintegrität zu bewerten und potenzielle Probleme zu identifizieren, bevor sie für Benutzer eine Beeinträchtigung darstellen. Weitere Informationen finden Sie in der Dokumentation zu AEM JMX MBeans.
Hier sind einige Baselineparameter angegeben, die Sie für AEM überwachen können:
Replikationsagenten
MBean: com.adobe.granite.replication:type=agent,id=”<AGENT_NAME>”
URL: /system/console/jmx/com.adobe.granite.replication:type=agent,id=”<AGENT-NAME>”
Instanzen: Eine Autoren- und alle Veröffentlichungsinstanzen (für Flush-Agenten)
Alarmschwellenwert: Wenn der Wert von QueueBlocked
„true“ lautet oder der Wert von QueueNumEntries
größer als 150 % der Baseline ist.
Alarmdefinition: Blockierte Warteschlange im System. Dies ist ein Hinweis darauf, dass das Replikationsziel ausgefallen oder nicht erreichbar ist. Häufig führen Netzwerk- oder Infrastrukturprobleme dazu, dass eine übermäßig hohe Zahl von Einträgen in eine Warteschlange eingereiht wird, und dies kann sich negativ auf die Systemleistung auswirken.
Hinweis: Ersetzen Sie für die Parameter MBean und URL <AGENT_NAME>
den Namen des Replizierungsagenten, den Sie überwachen möchten.
Sitzungszähler
org.apache.jackrabbit.oak:id=7,name="OakRepository Statistics",type="RepositoryStats"
Konsistenzprüfungen
Konsistenzprüfungen, die über das Vorgangs-Dashboard durchgeführt werden können, verfügen über entsprechende JMX MBeans für die Überwachung. Sie können aber benutzerdefinierte Konsistenzprüfungen schreiben, um zusätzliche Systemstatistiken bereitzustellen.
Hier sind einige im Lieferumfang enthaltene Konsistenzprüfungen aufgeführt, die für die Überwachung verwendet werden können:
Systemprüfungen
org.apache.sling.healthcheck:name=systemchecks,type=HealthChec
kReplikations-Warteschlange
org.apache.sling.healthcheck:name=replicationQueue,type=HealthCheck
Antwortleistung
org.apache.sling.healthcheck:name=requestsStatus,type=HealthCheck
Abfrageleistung
org.apache.sling.healthcheck:name=queriesStatus,type=HealthCheck
Aktive Bundles
Fehlerprotokoll
org.apache.sling.healthcheck:name=logErrorHealthCheck,type=HealthCheck
Wenn während des Überwachungsprozesses Probleme auftreten, können Sie die folgenden Problembehandlungsschritte ausführen, um häufig auftretende Probleme mit AEM-Instanzen zu lösen:
OutOfMemoryError
-Protokolle. Weitere Informationen finden Sie unter Analysieren von Speicherproblemen.access.log
und error.log
auf Einträge, die zu Fehlerzeitpunkten erstellt wurden. Suchen Sie nach Mustern, die ggf. auf Anomalien im benutzerdefinierten Code hinweisen. Fügen Sie diese der Liste mit den zu überwachenden Ereignissen hinzu.