Livelli di registrazione - Logback - regola empirica per assegnare i livelli di registro

Sto usando il logback nel mio progetto attuale.

Offre sei livelli di registrazione: INFO TRACCIA DEBUG AVVISO ERRORE OFF

Sto cercando una regola empirica per determinare il livello di registro per le attività comuni. Ad esempio, se un thread è bloccato, il messaggio di registro deve essere impostato sul livello di debug o sul livello delle informazioni. O se viene utilizzato un socket, il suo ID specifico deve essere registrato a livello di debug o di traccia.

Apprezzerò le risposte con più esempi per ciascun livello di registrazione.

Costruisco principalmente sistemi di tipo su larga scala e ad alta disponibilità, quindi la mia risposta è distorta a guardarla dal punto di vista del supporto alla produzione; detto ciò, assegniamo approssimativamente come segue:

• errore : il sistema è in pericolo, i clienti sono probabilmente interessati (o lo saranno presto) e la correzione probabilmente richiede l'intervento umano. La "regola 2AM" si applica qui - se sei in guardia, vuoi essere svegliato alle 2AM se si verifica questa condizione? Se sì, registralo come "errore".

• avvisa : si è verificato un evento tecnico o commerciale imprevisto, i clienti potrebbero essere interessati, ma probabilmente non è necessario alcun intervento umano immediato. Le persone in chiamata non saranno chiamate immediatamente, ma il personale di supporto vorrà rivedere questi problemi al più presto per capire qual è l'impatto. Fondamentalmente qualsiasi problema che deve essere monitorato ma potrebbe non richiedere un intervento immediato.

• info : cose che vogliamo vedere ad alto volume nel caso in cui dovessimo analizzare forensi un problema. Gli eventi del ciclo di vita del sistema (avvio, arresto del sistema) vanno qui. Gli eventi del ciclo di vita "Sessione" (login, logout, ecc.) Vanno qui. Dovrebbero essere presi in considerazione anche eventi significativi al contorno (ad es. Chiamate al database, chiamate API remote). Le eccezioni aziendali tipiche possono andare qui (ad es. Accesso non riuscito a causa di credenziali errate). Qualsiasi altro evento che pensi di dover vedere in produzione ad alto volume va qui.

• debug : praticamente tutto ciò che non taglia le "informazioni" ... qualsiasi messaggio che sia utile per tracciare il flusso attraverso il sistema e isolare i problemi, specialmente durante le fasi di sviluppo e QA. Utilizziamo log di livello "debug" per l'entrata / uscita della maggior parte dei metodi non banali e per contrassegnare eventi e punti di decisione interessanti all'interno dei metodi.

• traccia : non lo usiamo spesso, ma questo sarebbe per registri di volume estremamente dettagliati e potenzialmente elevati che in genere non si desidera abilitare anche durante il normale sviluppo. Gli esempi includono il dumping di una gerarchia di oggetti completa, la registrazione di alcuni stati durante ogni iterazione di un ciclo di grandi dimensioni, ecc.

Come o più importante della scelta dei giusti livelli di registro è garantire che i registri siano significativi e abbiano il contesto necessario. Ad esempio, ti consigliamo quasi sempre di includere l'ID del thread nei log in modo da poter seguire un singolo thread, se necessario. Potresti anche voler utilizzare un meccanismo per associare le informazioni sull'attività (ad es. ID utente) al thread in modo che venga registrato anche. Nel tuo messaggio di registro, ti consigliamo di includere informazioni sufficienti per garantire che il messaggio possa essere attuabile. Un registro come "Eccezione FileNotFound rilevata" non è molto utile. Un messaggio migliore è "Eccezione FileNotFound rilevata durante il tentativo di aprire il file di configurazione: /usr/local/app/somefile.txt. UserId = 12344."

Ci sono anche una serie di buone guide di registrazione là fuori ... ad esempio, ecco uno snippet modificato da JCL (Jakarta Commons Logging) :

• errore - Altri errori di runtime o condizioni impreviste. Aspettati che siano immediatamente visibili su una console di stato.
• avvertenza: utilizzo di API obsolete, scarso utilizzo delle API, errori "quasi", altre situazioni di runtime indesiderabili o impreviste, ma non necessariamente "errate". Aspettati che siano immediatamente visibili su una console di stato.
• info - Eventi di runtime interessanti (avvio / arresto). Aspettati che siano immediatamente visibili su una console, quindi sii prudente e mantieni il minimo.
• debug: informazioni dettagliate sul flusso attraverso il sistema. Aspettatevi che vengano scritti solo nei log.
• traccia - informazioni più dettagliate. Aspettatevi che vengano scritti solo nei log.

Il mio approccio, penso che provenga più da uno sviluppo che da un punto di vista operativo, è:

• Errore significa che non è stato possibile completare l'esecuzione di alcune attività; non è stato possibile inviare un'e-mail, non è stato possibile visualizzare una pagina, alcuni dati non possono essere archiviati in un database, qualcosa del genere. Qualcosa è definitivamente andato storto.
• Avvertimento significa che è successo qualcosa di inaspettato, ma che l'esecuzione può continuare, forse in modalità degradata; mancava un file di configurazione ma sono stati utilizzati i valori predefiniti, un prezzo è stato calcolato come negativo, quindi è stato bloccato a zero, ecc. Qualcosa non è giusto, ma non è ancora andato storto correttamente - gli avvisi sono spesso un segno che ci sarà un errore molto presto.
• Info significa che è successo qualcosa di normale ma significativo; il sistema è stato avviato, il sistema si è arrestato, è stato eseguito il processo di aggiornamento dell'inventario giornaliero, ecc. Non dovrebbe esserci un flusso continuo di questi, altrimenti c'è troppo da leggere.
• Debug significa che è successo qualcosa di normale e insignificante; un nuovo utente è arrivato sul sito, è stata visualizzata una pagina, è stato preso un ordine, un prezzo è stato aggiornato. Questa è la roba esclusa dalle informazioni perché ce ne sarebbe troppa.
• La traccia è qualcosa che non ho mai usato.

Questo può anche aiutare tangenzialmente, per capire se una richiesta di registrazione (dal codice) a un certo livello comporterà la sua effettiva registrazione dato l' effettivo livello di registrazione con cui è configurata una distribuzione. Decidi con quale livello efficace vuoi configurare la tua distribuzione dalle altre Risposte qui, quindi fai riferimento a questo per vedere se una particolare richiesta di registrazione dal tuo codice sarà effettivamente registrata quindi ...

Ad esempio :

• "Una riga di codice di registrazione che registra su WARN verrà effettivamente registrata sulla mia distribuzione configurata con ERRORE?" La tabella dice NO.
• "Una riga di codice di registrazione che registra su WARN verrà effettivamente registrata sulla mia distribuzione configurata con DEBUG?" La tabella dice SÌ.

dalla documentazione di logback :

In modo più grafico, ecco come funziona la regola di selezione. Nella tabella seguente, l'intestazione verticale mostra il livello della richiesta di registrazione, indicato da p, mentre l'intestazione orizzontale mostra il livello effettivo del logger, indicato da q. L'intersezione delle righe (richiesta di livello) e delle colonne (livello effettivo) è il valore booleano risultante dalla regola di selezione di base.

Pertanto, una riga di codice che richiede la registrazione verrà effettivamente registrata solo se il livello di registrazione effettivo della sua distribuzione è inferiore o uguale al livello di gravità richiesto della riga di codice .

Rispondo a questo proveniente da un'architettura basata su componenti, in cui un'organizzazione può eseguire molti componenti che possono fare affidamento l'uno sull'altro. Durante un errore di propagazione, i livelli di registrazione dovrebbero aiutare a identificare sia quali componenti sono interessati sia quali cause principali.

• ERRORE - Questo componente ha avuto un errore e si ritiene che la causa sia interna (qualsiasi eccezione interna, non gestita, errore della dipendenza incapsulata ... ad esempio database, esempio REST sarebbe che ha ricevuto un errore 4xx da una dipendenza). Fammi (manutentore di questo componente) dal letto.

• AVVERTENZA : si ritiene che questo componente abbia causato un errore a causa di un componente dipendente (l'esempio REST sarebbe uno stato 5xx da una dipendenza). Prendi i manutentori di QUESTO componente dal letto.

• INFO - Qualsiasi altra cosa che vogliamo raggiungere da un operatore. Se decidi di registrare percorsi felici, ti consiglio di limitare a 1 messaggio di registro per operazione significativa (ad es. Per richiesta HTTP in entrata).

Per tutti i messaggi di registro, assicurati di registrare il contesto utile (e dai la priorità a rendere i messaggi leggibili / utili all'uomo piuttosto che avere risme di "codici di errore")

• DEBUG (e sotto) - Non dovrebbe essere usato affatto (e certamente non in produzione). In fase di sviluppo, consiglierei di utilizzare una combinazione di TDD e debug (ove necessario) anziché codice inquinante con istruzioni di registro. In produzione, la registrazione INFO sopra, combinata con altre metriche, dovrebbe essere sufficiente.

Un buon modo per visualizzare i livelli di registrazione sopra è immaginare una serie di schermate di monitoraggio per ciascun componente. Quando tutto funziona bene sono verdi, se un componente registra un AVVISO, diventerà arancione (ambra) se qualcosa registra un ERRORE, diventerà rosso.

In caso di incidente dovresti avere un componente (causa principale) diventare rosso e tutti i componenti interessati dovrebbero diventare arancione / ambra.

Non diverso per le altre risposte, il mio framework ha quasi gli stessi livelli:

1. Errore: errori logici critici nell'applicazione, come un timeout della connessione al database. Cose che richiedono una correzione di bug nel prossimo futuro
2. Avvertenza: problemi senza interruzioni, ma cose a cui prestare attenzione. Come una pagina richiesta non trovata
3. Informazioni: usato nella prima riga di funzioni / metodi, per mostrare una procedura che è stata chiamata o un passaggio andato bene, come una query di inserimento eseguita
4. log: informazioni logiche, come il risultato di un'istruzione if
5. debug: contenuti variabili rilevanti da guardare permanentemente