Tools zur Überwachung
Die ThingWorx Plattform wurde mit Java-Technologie entwickelt. Die in diesem Abschnitt erläuterten Tools zur Diagnose und Überwachung dienen dazu, Leistungsmetriken und andere Daten von der Java Virtual Machine (JVM) zu sammeln. Verwenden Sie diese Tools, um Ihre ThingWorx Lösungen über die JVM-Schicht zu überwachen. Die Tools rufen die folgenden Daten von der JVM ab:
• Arbeitsspeicheroperationen – Prüfen Sie, ob dem Server genügend Arbeitsspeicherressourcen zugeordnet sind und wie lange die Operationen der JVM-Garbage Collection (GC) dauern.
• Thread-Leistung – Prüfen Sie, ob es lange Transaktionen oder Threading-Probleme gibt, die Leistungsprobleme in Ihrer ThingWorx Lösung verursachen könnten.
Direkte JVM-Überwachung
Direkte JVM-Überwachungstools werden von Oracle oder dem Support-Untersystem bereitgestellt. Das direkte Sammeln von Daten von der JVM ist eine gute Alternative, um Leistungsprobleme zu identifizieren und zu beheben. Es wird empfohlen, die folgenden JVM-Diagnosen für Ihre ThingWorx Lösungen zu überwachen:
• Überwachen Sie die Arbeitsspeicherleistung mithilfe der Garbage Collection-Protokollierung, einer integrierten Funktion der JVM.
• Sammlung und Analyse auf Thread-Ebene unter Verwendung des Untersystems für Support.
Arbeitsspeicherverwendung eines ThingWorx Servers überwachen
Die Java Virtual Machine (JVM) verwaltet ihren eigenen Arbeitsspeicher (Heap) nativ mithilfe des Garbage Collector (GC). GC identifiziert und entfernt Objekte im Java-Heap, die nicht verwendet werden. Sie können die Arbeitsspeicherverwendung eines ThingWorx Servers überwachen, indem Sie die vom GC gesammelten Details protokollieren.
Sie können die GC-Protokolldatei verwenden, um Trends im Arbeitsspeicherverbrauch zu identifizieren. Je nach Trends können Sie prüfen, ob der maximale Heap-Parameter des Apache Tomcat-Servers geändert werden sollte, um eine bessere Leistung zu erzielen. Daher wird empfohlen, die Protokollierung für GC auf dem Apache Tomcat-Server einzurichten.
JVM hat Flags, die zur Laufzeit aufgerufen werden. Diese Flags werden verwendet, um die Statistiken zu GC-Ereignissen zu schreiben, z.B. den Typ des GC-Ereignisses, den zu Beginn des Ereignisses verbrauchten Arbeitsspeicher, die Menge des vom GC-Ereignis freigegebenen Arbeitsspeichers und die Dauer des GC-Ereignisses.
Die GC-Protokolldatei wird jedes Mal überschrieben, wenn die JVM gestartet wird. Es wird empfohlen, die Protokolldatei während des Serverneustarts zu sichern. Auf diese Weise können Sie analysieren, ob der Server durch die Arbeitsspeicherverwendung neu gestartet wurde.
Sie können Analyse-Tools wie GCEasy.io und Chewiebug GC Viewer verwenden, um die Protokolle aus der Garbage Collection zu analysieren.
So richten Sie die Garbage Collection-Protokollierung unter Linux ein (setenv.sh)
Führen Sie die folgenden Schritte durch, um die Garbage Collector-Protokollierung unter Linux einzurichten:
1. Öffnen Sie das Skript $CATALINA_HOME/bin/setenv.sh in einem Text-Editor.
Die Skriptdatei setenv.sh ist möglicherweise nicht in allen Installationen verfügbar. Wenn die Datei nicht vorhanden ist, erstellen Sie eine neue Datei setenv.sh am Speicherort.
2. Hängen Sie den folgenden Text am Ende der Variablen JAVA_OPTS in doppelten Anführungszeichen an.
Für Java 8:
-XX:+UseG1GC -Xloggc:/logs/gc.log -XX:+PrintGCTimeStamps -XX:+PrintGCDetails
Wenn JAVA_OPTS in der Datei setenv.sh nicht angegeben wird oder die Datei setenv.sh neu ist, fügen Sie die folgende Zeile in der Datei hinzu:
JAVA_OPTS=”-XX:+UseG1GC -Xloggc:/logs/gc.log -XX:+PrintGCTimeStamps -XX:+PrintGCDetails”
Für Java 9 und höher:
-Xlog:gc:file=/logs/gc.log:time,level,tags
Wenn JAVA_OPTS in der Datei setenv.sh nicht angegeben wird oder die Datei setenv.sh neu ist, fügen Sie die folgende Zeile in der Datei hinzu:
JAVA_OPTS="-Xlog:gc:file=/logs/gc.log:time,level,tags"
Beachten Sie Folgendes:
▪ Die Option -XX:+PrintGC gibt ein weniger ausführliches Ausgabeprotokoll zurück. Das Ausgabeprotokoll enthält beispielsweise die folgenden Details:
2017-10-10T13:22:49.363-0400: 3.096: [GC (Allocation Failure) 116859K->56193K(515776K), 0.0728488 secs]
▪ Die Option -XX:+PrintGCDetails gibt ein detailliertes Ausgabeprotokoll zurück. Das Ausgabeprotokoll enthält beispielsweise die folgenden Details:
2017-10-10T13:18:36.663-0400: 35.578: [GC (Allocation Failure) 2017-10-10T13:18:36.663-0400: 35.578: [ParNew: 76148K->6560K(76672K), 0.0105080 secs] 262740K->193791K(515776K), 0.0105759 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]
3. Fügen Sie am Ende des Skripts setenv.sh die folgenden Zeilen hinzu. Dieser Code sichert automatisch eine vorhandene Datei gc.out in gc.out.restart, bevor der Apache Tomcat-Server gestartet wird:
# Backup the gc.out file to gc.out.restart when a server is started.
if [ -e "$CATALINA_HOME/logs/gc.out" ]; then
cp -f "$CATALINA_HOME/logs/gc.out" "$CATALINA_HOME/logs/gc.out.restart"
fi
if [ -e "$CATALINA_HOME/logs/gc.out" ]; then
cp -f "$CATALINA_HOME/logs/gc.out" "$CATALINA_HOME/logs/gc.out.restart"
fi
4. Speichern Sie die Änderungen an der Datei.
5. Starten Sie den Apache Tomcat-Dienst mit dem Dienstcontroller für Ihr Betriebssystem neu.
So richten Sie die Garbage Collection-Protokollierung unter Windows ein (Apache Service Manager)
Führen Sie die folgenden Schritte aus, um die Garbage Collector-Protokollierung unter Windows einzurichten:
1. Navigieren Sie in Windows Explorer zu <Tomcat_home>\bin.
2. Starten Sie die ausführbare Datei, die w im Namen hat. Beispiel: Tomcat<version number>w.exe.
3. Klicken Sie auf die Registerkarte Java.
4. Fügen Sie im Feld Java Options die folgenden Zeilen hinzu:
Für Java 8:
-Xloggc:logs/gc_%t.out
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails
Für Java 9 und höher:
-Xlog:gc:file=/logs/gc.log:time,level,tags
Informationen zu den Optionen -XX:+PrintGC und -XX:+PrintGCDetails finden Sie im Abschnitt So richten Sie die Garbage Collection-Protokollierung unter Linux (setenv.sh) ein.
5. Klicken Sie auf Anwenden, um die Änderungen an der Dienstkonfiguration zu speichern.
6. Klicken Sie auf der Registerkarte Allgemein auf Beenden.
7. Klicken Sie auf Starten, um den Apache Tomcat-Dienst neu zu starten.
Das neue Garbage Collection-Protokoll wird in die Datei %CATALINA_HOME%\logs\gc_<Tomcat_Restart_Timestamp>.out geschrieben.
Diagnosedaten mithilfe des Untersystems für Support sammeln
Weitere Informationen finden Sie unter Support-Untersystem.
VisualVM und andere JMX-Tools zur Überwachung
VisualVM ist ein Tool zur Überwachung, das Daten für Java-Lösungen sammelt. Sie können VisualVM verwenden, um ThingWorx Lösungen zu überwachen. Es sammelt Informationen über die Verwendung von Arbeitsspeicher und CPU. Es generiert und analysiert Heap-Dumps und verfolgt Arbeitsspeicherlecks. Sie können Daten für Lösungen sammeln, die lokal oder auf Remoterechnern ausgeführt werden.
VisualVM bietet eine Oberfläche, mit der Sie die Informationen zu Java-Lösungen grafisch anzeigen können.
VisualVM ist zusammen mit dem Java JDK verfügbar. Weitere Informationen zu Verbindungseinstellungen für VisualVM·finden·Sie·im·Abschnitt· im ThingWorx Hilfe-CenterJava-Optionseinstellungen für Apache Tomcat.
Andere Tools, die mit der JVM mithilfe von Java Management Extensions (JMX) integriert werden, bieten ebenfalls ähnliche Überwachungsfunktionen.
VisualVM erfasst die folgenden Schlüsselmetriken, die sich auf die Leistung der Lösung auswirken:
• JVM-Arbeitsspeicherleistung
• Zeit, die zum Ausführen von Threads erforderlich ist
• Arbeitsspeicher des Betriebssystems und CPU-Metriken
• Überwachung des Datenbankverbindungspools
VisualVM verfolgt Echtzeitdaten für ca. 20 Minuten.
Überwachung von ThingWorx Anwendungsprotokollen
ThingWorx Lösungsprotokolle sollten regelmäßig auf Fehler oder andere anormale Operationen überwacht werden. Fehler können entweder auf der Plattformebene oder in den benutzerdefinierten Skripts auftreten, die mit ThingWorx verwendet werden. Es wird empfohlen, die Meldungen im Fehlerprotokoll täglich zu prüfen.
LoggingSubsystem-Option für das Schreiben der Stapelablaufverfolgung für Fehler konfigurieren
Die Option Stapel-Ablaufverfolgung aktivieren in LoggingSubsystem schreibt Fehlermeldungen und zugeordnete Stapelablaufverfolgungen in Protokolldateien. Standardmäßig ist LoggingSubsytem nicht so konfiguriert, dass Stapelablaufverfolgungen (Aufrufstapel) auf die Festplatte geschrieben werden. Legen Sie die Option Stapel-Ablaufverfolgung aktivieren fest, um Aufrufstapel von Ausnahmen und Fehlermeldungen in die Datei ErrorLog.log zu schreiben, die im Ordner ThingworxStorage/logs verfügbar ist. Es wird empfohlen, diese Option so festzulegen, dass die Details der Funktionsaufrufe in der Stapelablaufverfolgung beim Debuggen eines Fehlers angezeigt werden.
Anwendungsprotokolle beibehalten
Die Protokollebene bestimmt, wie viel Granularität in den Protokollen angezeigt werden sollte. Es wird empfohlen, für die Protokollebene der Lösung minimale Ausführlichkeit wie Informationen oder Warnung zu verwenden, es sei denn, Sie behandeln ein Problem aktiv. Seien Sie vorsichtig, wenn Sie die Ausführlichkeit des Protokolls auf Debugging, Ablaufverfolgung oder Alle erhöhen. Dies kann sich nachteilig auf die Leistung von ThingWorx auswirken. Die Lösung verhält sich möglicherweise unvorhersehbar, wenn die auf der ThingWorx Plattform verfügbaren Ressourcen nicht ausreichen.
Protokolle werden als separate Dateien auf dem Server im Ordner /ThingworxStorage/logs gespeichert. Die Protokolle werden im Ordner archives archiviert, der sich im Ordner logs befindet. Die Protokollrotationsregeln basieren auf den Dateigrößen- und Zeitkonfigurationen, die in den Protokollaufbewahrungs-Einstellungen des Untersystems für die Protokollierung festgelegt werden. Diese Einstellungen können geändert und zur Laufzeit angewendet werden.
Sie können die folgenden Rollover-Konfigurationen in > > > angeben:
• Dateigröße – Die Protokolldatei wird archiviert, wenn ihre Größe die im Feld Maximale Dateigröße in KB definierte Größe erreicht oder überschreitet. Die Standard-Dateigröße für ein Protokoll ist auf 100.000 KB festgelegt. Die maximale Dateigröße, die Sie festlegen können, ist 1.000.000 KB.
• Zeit – Es wird täglich um Mitternacht ein Rollover für die Daten durchgeführt, wenn ein Protokollereignis ausgelöst wird. Die Protokolle werden in den Ordner archives verschoben. Standardmäßig wird ein Protokoll gelöscht, wenn es sich mehr als 7 Tage im Ordner archives befindet. Der Standardwert kann im Feld Maximale Anzahl der Tage für Archiv geändert werden. Sie können 1 bis 90 Tage angeben.
Es ist wichtig, die Protokollgrößen zu überwachen. Bereinigen Sie die Protokolldateien konsistent, indem Sie die Dateien zuerst sichern oder sie verwerfen, wenn Sie veraltete Informationen enthalten.