Strumenti di monitoraggio
ThingWorx Platform è stato sviluppato con la tecnologia Java. Gli strumenti di diagnostica e monitoraggio illustrati in questa sezione sono stati concepiti per raccogliere le metriche delle prestazioni e altri dati dalla Java Virtual Machine (JVM). Questi strumenti consentono di monitorare le soluzioni ThingWorx nel livello JVM ottenendo da JVM i dati seguenti.
• Operazioni di memoria - Consentono di controllare se le risorse di memoria allocate per il server sono sufficienti e quanto impiegano le operazioni di Garbage Collection (GC) di JVM.
• Prestazioni thread - Permettono di verificare se sono presenti transazioni lunghe o problemi di threading che possono causare problemi di prestazioni nella soluzione ThingWorx.
Monitoraggio diretto di JVM
Gli strumenti di monitoraggio diretto JVM vengono forniti da Oracle o dal sottosistema Supporto. La raccolta dei dati direttamente dalla JVM è una valida alternativa per identificare e correggere i problemi relativi alle prestazioni. Si consiglia di monitorare la diagnostica JVM seguente per le soluzioni ThingWorx.
• Monitoraggio delle prestazioni della memoria nel tempo utilizzando la registrazione di Garbage Collection, una funzionalità incorporata di JVM.
• Raccolta e analisi a livello di thread con il sottosistema Supporto.
Monitorare l'utilizzo della memoria di un server ThingWorx
La Java Virtual Machine (JVM) gestisce la propria memoria (heap) in modo nativo utilizzando il Garbage Collector (GC). GC identifica nell'heap Java gli oggetti che non sono in uso e li rimuove. È possibile monitorare l'utilizzo della memoria di un server ThingWorx registrando i dettagli raccolti da GC.
Si può utilizzare il file di log GC per identificare le tendenze nel consumo di memoria. A seconda delle tendenze è possibile controllare se è necessario modificare il parametro di heap massimo del server Apache Tomcat per ottenere prestazioni migliori. Si consiglia pertanto di impostare la registrazione per GC sul server Apache Tomcat.
JVM presenta flag che vengono chiamati in fase di esecuzione. Tali flag vengono utilizzati per scrivere le statistiche sugli eventi GC, ad esempio il tipo di evento GC, la quantità di memoria utilizzata all'inizio dell'evento, la quantità di memoria rilasciata dall'evento GC e la durata dell'evento GC.
Il file di log GC viene sovrascritto ogni volta che viene avviata la JVM. Si consiglia di eseguire il backup del file di log durante il riavvio del server. Ciò consente di capire se l'utilizzo della memoria ha causato il riavvio del server.
È possibile utilizzare strumenti di analisi quali GCEasy.io e Chewiebug GC Viewer per analizzare i log di Garbage Collection.
Come impostare la registrazione di Garbage Collection in Linux (setenv.sh)
Per impostare la registrazione del Garbage Collector in Linux, attenersi alla procedura descritta di seguito.
1. In un editor di testo aprire lo script $CATALINA_HOME/bin/setenv.sh.
Il file script setenv.sh può non essere disponibile in tutte le installazioni. Se il file non esiste, creare un nuovo file setenv.sh nella posizione.
2. Aggiungere tra virgolette il testo seguente alla fine della variabile JAVA_OPTS.
Per Java 8:
-XX:+UseG1GC -Xloggc:/logs/gc.log -XX:+PrintGCTimeStamps -XX:+PrintGCDetails
Se JAVA_OPTS non è specificato nel file setenv.sh o il file setenv.sh è nuovo, aggiungere la riga seguente nel file:
JAVA_OPTS=”-XX:+UseG1GC -Xloggc:/logs/gc.log -XX:+PrintGCTimeStamps -XX:+PrintGCDetails”
Per Java 9 e versioni successive:
-Xlog:gc:file=/logs/gc.log:time,level,tags
Se JAVA_OPTS non è specificato nel file setenv.sh o il file setenv.sh è nuovo, aggiungere la riga seguente nel file:
JAVA_OPTS="-Xlog:gc:file=/logs/gc.log:time,level,tags"
Tenere presente quanto riportato di seguito.
▪ L'opzione -XX:+PrintGC restituisce un log di output meno dettagliato. Ad esempio, il log di output riporta i seguenti dettagli:
2017-10-10T13:22:49.363-0400: 3.096: [GC (Allocation Failure) 116859K->56193K(515776K), 0.0728488 secs]
▪ L'opzione -XX:+PrintGCDetails restituisce il log di output dettagliato. Ad esempio, il log di output riporta i seguenti dettagli:
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. Aggiungere le righe riportate di seguito alla fine dello script setenv.sh. Questo codice consente di eseguire automaticamente il backup di un file gc.log esistente in gc.log.restart prima di avviare il server Apache Tomcat:
# Backup the gc.log file to gc.log.restart when a server is started.
if [ -e "$CATALINA_HOME/logs/gc.log" ]; then
cp -f "$CATALINA_HOME/logs/gc.log" "$CATALINA_HOME/logs/gc.log.restart"
fi
if [ -e "$CATALINA_HOME/logs/gc.log" ]; then
cp -f "$CATALINA_HOME/logs/gc.log" "$CATALINA_HOME/logs/gc.log.restart"
fi
4. Salvare le modifiche al file.
5. Riavviare il servizio Apache Tomcat utilizzando il controller di servizio applicabile al sistema operativo in uso.
Come impostare la registrazione di Garbage Collection in Windows (Apache Service Manager)
Per impostare la registrazione di Garbage Collection in Windows, attenersi alla procedura descritta di seguito.
1. In Esplora risorse passare a <Tomcat_home>\bin.
2. Avviare l'eseguibile il cui nome include w, ad esempio Tomcat<version number>w.exe.
3. Fare clic sulla scheda Java.
4. Nel campo Java Options aggiungere le righe seguenti:
Per Java 8:
-Xloggc:logs/gc_%t.out
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails
Per Java 9 e versioni successive:
-Xlog:gc:file=/logs/gc.log:time,level,tags
Per informazioni sulle opzioni -XX:+PrintGC e -XX:+PrintGCDetails, vedere la sezione Come impostare la registrazione di Garbage Collection in Linux (setenv.sh).
5. Fare clic su Applica per salvare le modifiche apportate alla configurazione del servizio.
6. Nella scheda Generale fare clic su Interrompi.
7. Fare clic su Avvia per riavviare il servizio Apache Tomcat.
Il nuovo log di Garbage Collection viene scritto nel file %CATALINA_HOME%\logs\gc_<Tomcat_Restart_Timestamp>.out.
Raccogliere i dati di diagnostica con il sottosistema Supporto
Per informazioni, vedere Sottosistema Supporto.
VisualVM e altri strumenti di monitoraggio JMX
VisualVM è uno strumento di monitoraggio che raccoglie i dati per le soluzioni Java. È possibile utilizzare VisualVM per monitorare le soluzioni ThingWorx. Raccoglie informazioni sulla memoria e sull'utilizzo della CPU. Genera e analizza i dump dell'heap e tiene traccia delle perdite di memoria. È possibile raccogliere i dati per le soluzioni eseguite localmente o su computer remoti.
VisualVM fornisce un'interfaccia che permette di visualizzare graficamente le informazioni sulle soluzioni Java.
È disponibile insieme a Java JDK. Per ulteriori informazioni sulle impostazioni di connessione per VisualVM, consultare la sezione in ThingWorx Help CenterImpostazioni delle opzioni di Apache Tomcat Java.
Altri strumenti che si integrano con la JVM utilizzando le estensioni JMX (Java Management Extension) forniscono funzionalità di monitoraggio simili.
VisualVM acquisisce le metriche chiave riportate di seguito, che incidono sulle prestazioni della soluzione.
• Prestazioni di memoria JVM
• Tempo necessario per l'esecuzione dei thread
• Memoria del sistema operativo e metriche della CPU
• Monitoraggio del pool di connessioni del database
VisualVM tiene traccia dei dati in tempo reale per circa 20 minuti.
Monitoraggio dei log dell'applicazione ThingWorx
I log della soluzione ThingWorx devono essere monitorati regolarmente per rilevare errori o altre operazioni anomale. Gli errori possono verificarsi sia a livello di piattaforma che negli script personalizzati utilizzati con ThingWorx. Si consiglia di esaminare i messaggi nel log degli errori ogni giorno.
Configurare l'opzione LoggingSubsystem per la scrittura della traccia stack per gli errori
L'opzione Attiva traccia stack in LoggingSubsystem scrive i messaggi di errore e le tracce stack associate nei file di log. Per default, LoggingSubsytem non è configurato per la scrittura di tracce stack (stack di chiamate) su disco. Impostare l'opzione Attiva traccia stack per scrivere stack di chiamate di eccezioni e messaggi di errore nel file ErrorLog.log, disponibile nella cartella ThingworxStorage/logs. È consigliabile impostare questa opzione per visualizzare i dettagli delle chiamate di funzione nella traccia stack durante il debug di un errore.
Mantenere i log dell'applicazione
Il livello di registrazione determina la granularità da visualizzare nei log. Si consiglia di mantenere il livello di dettaglio del log della soluzione al minimo, ad esempio Info o Avvertenza, a meno che non si stia risolvendo attivamente un problema. Prestare attenzione quando si aumenta il livello di dettaglio del log specificando Debug, Traccia o Tutti. Queste impostazioni possono avere un impatto negativo sulle prestazioni di ThingWorx. Può verificarsi un comportamento imprevedibile della soluzione, se le risorse disponibili in ThingWorx Platform non sono sufficienti.
I log vengono salvati come file separati sul server, nella cartella /ThingworxStorage/logs. I log vengono archiviati nella cartella archives, che si trova nella cartella logs. Le regole di rotazione del log sono basate sulle dimensioni del file e sulle configurazioni temporali specificate nelle Impostazioni conservazione log del sottosistema Registrazione. Tali impostazioni possono essere modificate e applicate in fase di esecuzione.
È possibile specificare le configurazioni di rollover riportate di seguito in > > > :
• Dimensione file - Il file di log viene archiviato quando la sua dimensione raggiunge o supera il valore definito nel campo Dimensione file max in KB. La dimensione file di default per un log è impostata su 100000 KB. La dimensione massima del file che è possibile impostare è 1 milione di KB.
• Tempo - I file vengono sottoposti a rollback ogni giorno a mezzanotte, quando viene attivato un evento di log. I log vengono spostati nella cartella archives. Per default, se un log rimane nella cartella archives per più di sette giorni, viene eliminato. È possibile modificare il valore di default nel campo Numero max di giorni di archiviazione, specificando da 1 a 90 giorni.
È importante monitorare le dimensioni dei log. Cancellare i file di log in modo coerente eseguendo prima il backup o eliminandoli quando contengono informazioni obsolete.