Strumenti di monitoraggio

Best practice per lo sviluppo di applicazioni > Monitoraggio delle applicazioni ThingWorx > Strumenti di monitoraggio

La piattaforma ThingWorx è stata sviluppata con la tecnologia Java. Gli strumenti di diagnostica e monitoraggio illustrati in questa sezione sono stati concepiti per raccogliere i criteri di misurazione delle prestazioni e altri dati dalla Java Virtual Machine (JVM). Tali strumenti consentono di monitorare le applicazioni 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 nell'applicazione ThingWorx.

PTC System Monitor (PSM)

PTC System Monitor (PSM) è un sistema di monitoraggio delle prestazioni delle applicazioni con tecnologia Dynatrace. PTC ha personalizzato Dynatrace per soddisfare i requisiti di monitoraggio delle applicazioni ThingWorx. PSM fornisce agli amministratori di sistema gli strumenti per rilevare, diagnosticare e risolvere i problemi che influiscono sullo stato operativo dell'applicazione. Monitora sia i sistemi di test che quelli di produzione e non influisce sulle prestazioni dell'applicazione ThingWorx. Questo modulo rientra nell'ambito del contratto di manutenzione, pertanto non richiede l'acquisto di licenze aggiuntive per il monitoraggio della piattaforma principale.

PSM monitora l'attività a livello di thread nel livello JVM e la converte in una tecnologia proprietaria denominata PurePath. PSM PurePath contiene dettagli sul percorso di esecuzione del servizio ThingWorx sul server e sul tempo di esecuzione. Contiene inoltre informazioni sul contesto, ad esempio le istruzioni SQL eseguite.

Funzionalità di PSM

PSM consente di eseguire le operazioni elencate di seguito.

• Aumentare l'up-time dell'applicazione per evitare errori

◦ Invia notifiche quando vengono superate le soglie, ad esempio in caso di utilizzo elevato della CPU. Ciò consente all'amministratore di eseguire azioni correttive per risolvere il problema prima che interessi l'intero sistema.

◦ Fornisce una vista cronologica dell'utilizzo delle risorse di sistema. Ciò consente di stimare i requisiti futuri di capacità per le risorse di sistema.

• Migliorare le funzionalità di monitoraggio

◦ Utilizza dashboard semplificati e personalizzabili per riepilogare lo stato del sistema e dei componenti.

◦ Fornisce funzionalità di drill-down a transazioni, utenti e componenti server singoli per ulteriori dettagli.

◦ Contiene un elenco integrato di incidenti per i problemi che hanno un impatto sullo stato del sistema.

• Migliorare le funzionalità di diagnostica con i dati in tempo reale

◦ Utilizza la tecnologia PurePath per raccogliere i dati di diagnostica in tempo reale e registrare i criteri di misurazione delle prestazioni cronologici.

◦ Elimina le ore trascorse nella riproduzione di problemi con impostazioni dettagliate aggiuntive e nella risoluzione dei problemi con il supporto tecnico PTC.

PSM raccoglie e registra in modo continuo i dati in tempo reale dall'applicazione ThingWorx e li memorizza per periodi di tempo prolungati. I dati raccolti da PSM consentono di monitorare in modo continuo i criteri di misurazione delle prestazioni riportati di seguito che hanno un impatto sulle applicazioni personalizzate. Ciò consente al team di sviluppo o ai servizi di assistenza PTC di riprodurre gli eventi che determinano il problema di prestazioni:

• Prestazioni di memoria JVM

• Tempi di esecuzione dei servizi con i dati temporali PurePath

• Memoria del sistema operativo, CPU e criteri di interrogazione dei database

• Errori di log e altri incidenti di ThingWorx

Monitoraggio diretto di JVM

Gli strumenti di monitoraggio diretto di JVM sono disponibili in Oracle o nell'estensione degli strumenti di supporto ThingWorx. Possono essere utilizzati insieme a PSM per ottenere dati di prestazione dettagliati. Se non si utilizza PSM, la raccolta dei dati direttamente dalla JVM rappresenta un'alternativa valida per identificare e correggere i problemi di prestazioni. Si consiglia di monitorare la diagnostica JVM riportata di seguito per le applicazioni 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 l'estensione degli strumenti di supporto ThingWorx.

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.

-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”

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.out esistente in gc.out.restart prima di avviare il server Apache Tomcat:

# 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. 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:

-Xloggc:logs/gc_%t.out
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails

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 utilizzando l'estensione degli strumenti di supporto

L'estensione degli strumenti di supporto ThingWorx permette di raccogliere informazioni per il supporto tecnico ThingWorx. Queste informazioni vengono utilizzate durante la risoluzione dei problemi relativi all'applicazione ThingWorx. L'estensione raccoglie i dati di diagnostica indicati di seguito.

• Dump dei thread Java - Dettagli relativi a tutti i thread in esecuzione su una Java Virtual Machine in un momento specifico. Possono registrare l'attività dei thread per i periodi specificati.

• Dump dell'heap Java - Dettagli relativi a tutti gli oggetti nello spazio dell'heap di una Java Virtual Machine in un momento specifico.

PTC consiglia di installare questa estensione nella propria istanza di ThingWorx. L'estensione è disponibile nella pagina PTC Software Download all'indirizzo support.ptc.com.

VisualVM e altri strumenti di monitoraggio JMX

VisualVM è uno strumento di monitoraggio che raccoglie i dati per le applicazioni Java. È possibile utilizzare VisualVM per monitorare le applicazioni ThingWorx. Raccoglie informazioni sulla memoria e sull'utilizzo della CPU. Genera e analizza i dump dell'heap e tiene traccia delle perdite di memoria. Si possono raccogliere i dati per le applicazioni eseguite localmente o su computer remoti.

VisualVM fornisce un'interfaccia che permette di visualizzare graficamente le informazioni sulle applicazioni Java.

È disponibile insieme a Java JDK. Per ulteriori informazioni sulle impostazioni di connessione per VisualVM, consultare la sezione in ThingWorx Help Center Impostazioni 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 i criteri di misurazione chiave riportati di seguito, che incidono sulle prestazioni dell'applicazione.

• Prestazioni di memoria JVM

• Tempo necessario per l'esecuzione dei thread

• Memoria del sistema operativo e criteri di misurazione 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 dell'applicazione 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 minimo per il log dell'applicazione, 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 dell'applicazione, se le risorse disponibili sulla piattaforma 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 Sistema > Sottosistemi > LoggingSubsystem > Configurazione:

• 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.