In questo articolo vedremo come sono organizzati i log di Sme.UP Provider e come capire il funzionamento dello strumento.

Individuazione dei log

Sme.UP Provider estende il motore dei log di Looc.UP.

Con Looc.UP condivide la posizione dei log (sono in %appdata%\Loocup\Log) e la politica di pulizia (al riavvio tutti i file più vecchi di 8 giorni vengono eliminati).

Nel caso del Provider, essendo installato su un server, potrebbero non essere individuati immediatamente: la posizione è determinata dall’utente. Se per esempio, ci colleghiamo al server con un utente diverso da quello del Provider, digitando

"%appdata%\loocup\log"

verremo portati nella cartella appdata dell’utente corrente e non in quella del Provider.

Per andare nella cartella corretta, occorrerà utilizzare Esplora Risorse e

partendo da c:\ andare in utenti -> utente_del_provider -> Roaming\Loocup\LOG.

Solitamente la cartella “Roaming” non si trova: va abilitata la visibilità dei file nascosti e di sistema.

Organizzazione dei log

Nella cartella log, i file presenti sono organizzati per sessione_iseries, utente e componente. Il componente Grafico (EXD) e il componente Emulatore (EMU) hanno anche file di errore e di comunicazione.

Ad esempio, per la sessione 123456 (dell’utente SMEPRO) avremo tanti file di log quanti sono i componenti utilizzati. Se ad esempio troviamo il file 123456_SMEPRO_LOCFLU.log, vorrà dire che il Provider sta utilizzando il componente LOCFLU (il motore dei flussi), e così via per ogni altro componente.

Altri file interessanti sono (tutti con prefisso sessione_utente_):

  • LOSERVER: la comunicazione sulla coda server – Questo file è IMPORTANTISSIMO!
  • LOSPR: la comunicazione sulla porta http.
  • LOFIELD: i log dell’interfaccia con il campo
  • LOIOTSPI: i log dell’interfaccia con il campo – nuova versione da Roma Rev.1
  • LOA38: i log dell’interfaccia con i Webservice
  • LOWSCSPI: i log dell’interfaccia con i Webservice – nuova versione da Roma Rev.1
  • LOA39: i log dei webservice esposti dal provider
  • LOWSPSPI: i log dei webservice esposti dal provider – nuova versione da Roma Rev.1
  • LORES: risorse remote

I file di log globali

Se però siamo interessati a consultare i log con una visione globale, è necessario entrare nella cartella GLOBAL. I file che si trovano qui raggruppano in un unico file tutti i log del modulo base.

I file di log globali hanno un nome che è così composto:

<id_sessione_client>_<server_applicativo>_<utente_applicativo>_<ambiente_applicativo>_server-<nome_coda>[-<porta_server>]_http(s)[-<porta_http>]_data_ora
 

In questo caso, data un’istanza di provider avremo due file, uno che finisce con .log e che contiene i log di tutti i componenti e un .err che raccoglie solamente i log di errore.

Il nome del file di log viene creato partendo dai parametri di avvio del Provider. Nel caso la porta server o la porta http non siano indicate nei parametri di avvio, non verranno riportate nel nome del file.

Se il provider chiude la sessione principale il nome del file rimane lo stesso.

Il meccanismo di rolling

Quando il file di log supera i 100MB, il provider lo rinomina con estensione .log.1 e poi inizia a scrivere nel .log.

Se ad esempio abbiamo il file

d8kcgohmsq_--DFT_SRVAMM.SMEUP.COM_LO_SRVF_GES_10ADV_server-SRVFPA-9992_http__20170526_01.55.03066.log

superati i 100Mb avremo un

d8kcgohmsq_--DFT_SRVAMM.SMEUP.COM_LO_SRVF_GES_10ADV_server-SRVFPA-9992_http__20170526_01.55.03066.log.1

e poi

d8kcgohmsq_--DFT_SRVAMM.SMEUP.COM_LO_SRVF_GES_10ADV_server-SRVFPA-9992_http__20170526_01.55.03066.log.2

ecc.. ecc.

Il meccanismo di rolling è configurato per mantenere al massimo 20 file di rolling, pertanto arrivati a

d8kcgohmsq_--DFT_SRVAMM.SMEUP.COM_LO_SRVF_GES_10ADV_server-SRVFPA-9992_http__20170526_01.55.03066.log.20

il .20 viene eliminato e tutti gli altri scalano: il .log.19 diventa .log.20, il .log.18 diventa .log.19 e così via.

Questo rolling avviene anche per gli altri file specifici, quindi una sessione può avere vari gruppi di file di log fino ad un massimo di 20 file di 100Mb l’uno.

Questo meccanismo di rolling non garantisce la copertura di 8 gg: il rolling potrebbe avvenire in 4 ore o in 10 giorni.

La quantità di log prodotti dipende da:

  • Carico di lavoro del Provider
  • livello di dettaglio, gestibile tramite il parametro loglevel.
  • Il livello di dettaglio ha questi valori, con dettaglio decrescente:
    • DEBUG: massimo dettaglio
    • INFO (default): log informativi, di avviso e di errore
    • WARN: solo log di errore e avviso
    • ERROR: solo log di errore
    • OFF: log disabilitati

I log del wrapper

Quando il provider è installato come servizio, per poter funzionare si appoggia al programma wrapper.exe.

I log del wrapper si trovano nella cartella di installazione del Provider, sottocartella

 serviceNT\logs.

Sono organizzati per servizio e per giorno.

Questi log sono da consultare quando il Provider smette di funzionare improvvisamente e non si hanno indicazioni nei log del Provider, oppure se si vuole conoscere le date di accensione/spegnimento del servizio.

Come individuare un errore

Come abbiamo visto, nella cartella GLOBAL i nomi dei file di log sono composti e contengono:

  • il nome del server applicativo (iSeries) a cui il provider è connesso
  • l’utente applicativo del Provider
  • l’ambiente
  • il nome del provider
  • protocollo e porta http
  • la data e l’ora di avvio

Pertanto va individuato l’utente applicativo con cui gira il Provider, il nome del Provider, l’ambiente applicativo a cui è collegato e la porta http. Con queste informazioni possiamo filtrare il contenuto della cartella e individuare facilmente i file di log che ci interessano.

Il primo file da analizzare è il .ERR.

Questo file contiene solo i log di errore.

Individuato l’errore che che ha causato il malfunzionamento, si passa ad analizzare il .log o il .log.n, nel caso il file di log sia rollato. Il file .log contiente tutte le registazioni, quindi anche l’errore. E’ semplice orientarsi con data e ora e trovare le registrazioni relativa ad un intorno nel quale è avvenuto l’errore, in modo da contestualizzarlo.

Con queste informazioni e questo file è possibile aprire una segnalazione in modo rapido e circostanziato, permettendo una risoluzione più celere. Spesso l’errore stesso è autoesplicativo:

java.io.FileNotFoundException: input.txt (No such file or directory)
	at java.io.FileInputStream.open(Native Method)
	at java.io.FileInputStream.(FileInputStream.java:146)
	at java.io.FileReader.(FileReader.java:72)

Non è difficile capire che l’errore è che il file input.txt non esiste.

Problemi comuni

Una premessa importante

Il Provider è un’applicazione che funziona su un sistema Windows e quando deve accedere a file si appoggia al sistema operativo che lo ospita. Per questo motivo bisognerà considerare le autorizzazioni dell’utente Windows, non quelle dell’utente applicativo. L’utente applicativo entra in gioco quando il provider si collega e dialoga con l’iSeries.

Il Provider si avvia ma dopo pochi secondi si chiude.

Nel file di log globale, trovo “Java bind exception: Address already in use” c’è già un’istanza di un Provider che è attiva su quella porta server /  porta http.

Questo può essere dovuto ad una cattiva configurazione (due Provider che usano la stessa porta server o http), oppure ad un Provider che non si è chiuso correttamente e alloca ancora una o più porte.

Il Provider non si avvia o smette di funzionare improvvisamente.

Nel file di log globale trovo “ObjectDoesNotExistException“: significa che quando parte il Provider non riesce a creare le code di comunicazione, oppure le code vengono eliminate.

Va controllato che su iSeries:

  1. tutti i servizi necessari al Provider siano attivi (usare LoocupNetTester per le verifiche).
  2. il sottosistema dei job LO_xxxxx deve essere attivo (normalmente è il QBATCHUI).
  3. non siano schedulate operazioni di pulizia delle code successive all’avvio del Provider.

Ultimo ma non meno importante, dal momento in cui il Provider si avvia fino allo spegnimento, l’iSeries deve essere raggiungibile.

Un problema ad un flusso.

Aprire il file LOCFLU e verificare la fun e i vari passi di esecuzione.

Se non c’è traccia, aprire il file LOSERVER e verificare che ci sia la richiesta di esecuzione.

Se non c’è verificare il LOA37: potrebbe stare scrivendo su un’altra coda oppure potrebbero esserci più provider che usano la stessa coda.

Il Provider non riesce a scrivere su IFS

Quando il Provider funziona come servizio non può eseguire funzioni interne quali ad esempio il JA_00_15;NET.AUT. Ciò significa, che, se l’utente di windows del servizio non riesce ad accedere all’IFS, neppure il Provider riuscirà ad accedervi.

La soluzione in questo caso è di disinstallare il servizio del Provider e schedulare avvii e spegnimenti configurando opportunamente gli script start_server.cmd e stop_server.cmd, presenti nella cartella di installazione, LOOCUP_SCP. Per evitare che un aggiornamento del Provider cancelli questi file, si consiglia di copiarli in una apposita cartella.

La struttura dei file di log GLOBALI – DETTAGLI TECNICI

Nei file .log, le informazioni sono registrate senza nessun ritorno a capo, questo significa che ogni riga contiene una registrazione. Eventuali ritorni a capo vengono sostituiti da spazi.

La struttura dei file di log è composta da una parte fissa e da una variabile.

la parte fissa è composta da queste informazioni:

  • data -ora registrazione
  • livello (DEBUG/INFO/WARN/ERROR) che informa sul tipo di messaggio e la gravità
  • thread java
  • componente
  • sessione client (quella del provider è identificabile perché termina con –DFT)
  • server applicativo
  • utente applicativo
  • ambiente applicativo

La parte variabile può essere un testo, e in questo caso inizia con msg:, oppure 4 valori seguiti da un messaggio.

In questo secondo caso avremo livello, chiave1, chiave2, lista attributi e un testo. Questa organizzazione viene utilizzata per loggare particolari fasi, per esempio nella lettura dell’XML da iSeries, vedremo le informazioni su quale classe ha eseguito la lettura, i punti in cui è passata e il numero di lettura.