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 Anwendungen ü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 Anwendung verursachen könnten.
PTC System Monitor (PSM)
PTC System Monitor (PSM) ist ein von Dynatrace gesteuertes Application Performance Monitoring-System. PTC hat Dynatrace für die Überwachungsanforderungen von ThingWorx Anwendungen angepasst. PSM stellt Systemadministratoren Tools zur Verfügung, um Probleme zu erkennen, zu diagnostizieren und zu beheben, die sich auf den Betriebszustand der Anwendung auswirken. Es überwacht sowohl die Test- als auch die Produktionssysteme. Es wirkt sich nicht auf die Leistung der ThingWorx Anwendung aus. Dieses Modul ist als Teil Ihres Wartungsvertrags verfügbar und erfordert nicht den Erwerb zusätzlicher Lizenzen für die Hauptplattformüberwachung.
PSM überwacht die Aktivität auf Thread-Ebene, die auf JVM-Ebene erfolgt, und destilliert diese Aktivität in eine proprietäre Technologie namens PurePaths. PSM PurePath enthält Details über den Ausführungspfad des ThingWorx Dienstes auf dem Server und die Ausführungszeit. Es enthält auch Kontextinformationen, z.B. ausgeführte SQL-Anweisungen.
Funktionen von PSM
PSM ermöglicht Folgendes:
Erhöhen Sie die Betriebszeit der Anwendung, bevor sie fehlschlägt:
Sendet Benachrichtigungen, wenn die Schwellenwerte verletzt werden, z.B. hohe CPU-Verwendung. Dies ermöglicht es dem Administrator, Korrekturmaßnahmen zu ergreifen, um die Probleme zu beheben, bevor sie sich systemweit auswirken.
Bietet eine historische Ansicht der Verwendung von Systemressourcen. Dies hilft Ihnen, die zukünftigen Kapazitätsanforderungen für Systemressourcen zu schätzen.
Verbessern Sie die Überwachungsfunktionen:
Verwendet vereinfachte und anpassbare Dashboards, um den Zustand des Systems und der Komponenten zusammenzufassen.
Bietet Drilldown-Funktionen für einzelne Transaktionen, Benutzer und Serverkomponenten, um weitere Details zu erhalten.
Enthält eine integrierte Vorfall-Liste für Probleme, die sich auf den Zustand des Systems auswirken.
Verbessern Sie die Diagnosefunktionen mit Daten in Echtzeit:
Verwendet die PurePath-Technologie, um Diagnosedaten in Echtzeit zu sammeln und historische Leistungsmetriken aufzuzeichnen.
Reduziert den Aufwand für die Reproduktion von Problemen mit zusätzlichen ausführlichen Einstellungen und für die Behandlung von Problemen mit dem technischen Support von PTC.
PSM sammelt und zeichnet kontinuierlich Echtzeitdaten aus Ihrer ThingWorx Anwendung auf und speichert diese Daten über einen längeren Zeitraum. Die von PSM gesammelten Daten ermöglichen es Ihnen, die folgenden Leistungsmetriken kontinuierlich zu überwachen, die sich auf benutzerdefinierte Anwendungen auswirken. Dies hilft Ihrem Entwicklungsteam oder PTC Support Services, die Ereignisse wiederzugeben, die zum Leistungsproblem geführt haben:
JVM-Arbeitsspeicherleistung
Dienstausführungszeiten unter Verwendung von PurePath-Zeitdaten
Arbeitsspeicher-, CPU- und Datenbankabfrage-Metriken des Betriebssystems
ThingWorx Protokollfehler und andere Vorfälle
Direkte JVM-Überwachung
Tools zur direkten JVM-Überwachung werden entweder durch Oracle oder die ThingWorx Support Tools-Erweiterung bereitgestellt. Diese Tools können zusammen mit PSM verwendet werden, um detaillierte Leistungsdaten zu erhalten. Wenn Sie PSM nicht verwenden, ist das Sammeln von Daten direkt von der JVM eine gute Alternative, um Leistungsprobleme zu identifizieren und zu beheben. Es wird empfohlen, die folgenden JVM-Diagnosen für Ihre ThingWorx Anwendungen zu überwachen:
Überwachen Sie die Arbeitsspeicherleistung mithilfe der Garbage Collection-Protokollierung, einer integrierten Funktion der JVM.
Sammlung und Analyse auf Thread-Ebene unter Verwendung der ThingWorx Support Tools-Erweiterung.
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.
-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”
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
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:
-Xloggc:logs/gc_%t.out
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails
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 der Support Tools-Erweiterung sammeln
Die ThingWorx Support Tools-Erweiterung wird verwendet, um Informationen für den technischen Support von ThingWorx zu sammeln. Diese Informationen werden bei der Behandlung von Problemen in Ihrer ThingWorx Anwendung verwendet. Die Erweiterung sammelt die folgenden Diagnosedaten:
Java-Thread-Dumps – Details zu allen Threads, die zu einem bestimmten Zeitpunkt auf einer Java Virtual Machine ausgeführt werden. Sie kann die Thread-Aktivität für bestimmte Zeiträume aufzeichnen.
Java-Heap-Dumps – Details zu allen Objekten im Heap-Bereich einer Java Virtual Machine zu einem bestimmten Zeitpunkt.
PTC empfiehlt, diese Erweiterung auf Ihrer ThingWorx Instanz zu installieren. Die Erweiterung ist auf der Seite PTC Software-Downloads unter support.ptc.com verfügbar.
VisualVM und andere JMX-Tools zur Überwachung
VisualVM ist ein Tool zur Überwachung, das Daten für Java-Anwendungen sammelt. Sie können VisualVM verwenden, um ThingWorx Anwendungen 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 Anwendungen sammeln, die lokal oder auf Remoterechnern ausgeführt werden.
VisualVM bietet eine Oberfläche, mit der Sie die Informationen zu Java-Anwendungen 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-Center Java-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 Anwendung 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 Anwendungsprotokolle 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 Anwendung 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 Anwendung verhält sich evtl. unvorhersehbar, wenn die auf der 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 System > Untersysteme > LoggingSubsystem > Konfiguration 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.