Quando utilizzare i diversi livelli di registro

Esistono diversi modi per registrare i messaggi, in ordine di fatalità:

1. FATAL

2. ERROR

3. WARN

4. INFO

5. DEBUG

6. TRACE

Come faccio a decidere quando utilizzare quale?

Qual è una buona euristica da usare?

In genere sottoscrivo la seguente convenzione:

• Traccia - Solo quando vorrei "tracciare" il codice e cercare di trovare una parte di una funzione in modo specifico.
• Debug : informazioni che sono diagnosticamente utili alle persone più che agli sviluppatori (IT, amministratori di sistema, ecc.).
• Informazioni : informazioni generalmente utili per la registrazione (avvio / arresto del servizio, ipotesi di configurazione, ecc.). Informazioni che voglio avere sempre disponibili ma di solito non mi interessa in circostanze normali. Questo è il mio livello di configurazione predefinito.
• Avvisa : tutto ciò che può potenzialmente causare stranezze nell'applicazione, ma per il quale mi sto riprendendo automaticamente. (Ad esempio il passaggio da un server primario a un server di backup, il tentativo di ripetere un'operazione, la mancanza di dati secondari, ecc.)
• Errore : qualsiasi errore fatale per l' operazione , ma non per il servizio o l'applicazione (impossibile aprire un file richiesto, dati mancanti, ecc.). Questi errori imporranno l'intervento dell'utente (amministratore o utente diretto). Di solito sono riservati (nelle mie app) per stringhe di connessione errate, servizi mancanti, ecc.
• Fatale : qualsiasi errore che sta forzando l'arresto del servizio o dell'applicazione per prevenire la perdita di dati (o ulteriore perdita di dati). Li riservo solo per gli errori e le situazioni più atroci in cui è garantito il danneggiamento o la perdita dei dati.

Vorresti che il messaggio portasse un amministratore di sistema fuori dal letto nel cuore della notte?

• si -> errore
• no -> avvisa

Trovo più utile pensare alle gravità dal punto di vista della visualizzazione del file di registro.

Fatale / Critico : errore generale dell'applicazione o del sistema che deve essere esaminato immediatamente. Sì, sveglia SysAdmin. Poiché preferiamo il nostro avviso SysAdmins e ben riposato, questa gravità dovrebbe essere usata molto raramente. Se succede quotidianamente e non è un BFD, ha perso il suo significato. In genere, un errore irreversibile si verifica solo una volta durante la durata del processo, quindi se il file di registro è collegato al processo, questo è in genere l'ultimo messaggio nel registro.

Errore : sicuramente un problema da indagare. SysAdmin dovrebbe essere avvisato automaticamente, ma non è necessario trascinarlo fuori dal letto. Filtrando un registro per esaminare gli errori e sopra si ottiene una panoramica della frequenza degli errori e si può identificare rapidamente l'errore di avvio che potrebbe aver portato a una cascata di errori aggiuntivi. Il monitoraggio dei tassi di errore rispetto all'utilizzo delle applicazioni può produrre metriche di qualità utili come MTBF che possono essere utilizzate per valutare la qualità complessiva. Ad esempio, questa metrica potrebbe aiutare a informare le decisioni sull'opportunità o meno di un altro ciclo di test beta prima di un rilascio.

Avvertenza : questo potrebbe essere un problema o potrebbe non esserlo. Ad esempio, le condizioni ambientali transitorie previste, come la perdita di connettività di rete o del database, devono essere registrate come avvisi, non errori. La visualizzazione di un registro filtrato per mostrare solo avvisi ed errori può fornire una rapida visione dei primi suggerimenti sulla causa principale di un errore successivo. Gli avvertimenti devono essere usati con parsimonia in modo da non diventare insignificanti. Ad esempio, la perdita dell'accesso alla rete dovrebbe essere un avvertimento o addirittura un errore in un'applicazione server, ma potrebbe essere solo un'informazione in un'app desktop progettata per utenti laptop occasionalmente disconnessi.

Informazioni : si tratta di informazioni importanti che devono essere registrate in condizioni normali come l'inizializzazione corretta, l'avvio e l'arresto dei servizi o il completamento con successo di transazioni significative. La visualizzazione di un registro che mostra le informazioni e sopra dovrebbe fornire una rapida panoramica dei principali cambiamenti di stato nel processo fornendo un contesto di alto livello per comprendere eventuali avvisi o errori che si verificano. Non ci sono troppi messaggi informativi. Generalmente abbiamo <5% di messaggi informativi relativi alla traccia.

Traccia : la traccia è di gran lunga la gravità più comunemente usata e dovrebbe fornire un contesto per comprendere i passaggi che portano a errori e avvisi. Avere la giusta densità di messaggi Trace rende il software molto più gestibile, ma richiede una certa diligenza perché il valore delle singole dichiarazioni Trace può cambiare nel tempo man mano che i programmi si evolvono. Il modo migliore per raggiungere questo obiettivo è prendere l'abitudine del team di sviluppo di rivedere regolarmente i registri come parte standard della risoluzione dei problemi segnalati dai clienti. Incoraggia il team a eliminare i messaggi di traccia che non forniscono più un contesto utile e ad aggiungere messaggi dove necessario per comprendere il contesto dei messaggi successivi. Ad esempio, è spesso utile registrare l'input dell'utente come modificare display o schede.

Debug : consideriamo Debug <Traccia. La distinzione è che i messaggi di debug sono compilati dai build di rilascio. Detto questo, scoraggiamo l'uso dei messaggi di debug. Consentire i messaggi di debug tende a portare sempre più messaggi di debug aggiunti e nessuno mai rimosso. Nel tempo, ciò rende i file di registro quasi inutili perché è troppo difficile filtrare il segnale dal rumore. Ciò fa sì che gli sviluppatori non utilizzino i registri che continuano la spirale della morte. Al contrario, la costante eliminazione dei messaggi Trace incoraggia gli sviluppatori a usarli, il che si traduce in una spirale virtuosa. Inoltre, ciò elimina la possibilità che vengano introdotti dei bug a causa degli effetti collaterali necessari nel codice di debug che non è incluso nella build di rilascio. Sì, lo so che non dovrebbe succedere in un buon codice, ma è meglio prevenire che curare.

Ecco un elenco di ciò che hanno i "logger".

Apache log4j: §1 , §2

1. FATAL:

   [ v1.2 : ..] eventi di errore molto gravi che presumibilmente causeranno l'interruzione dell'applicazione.

   [ v2.0 : ..] errore grave che impedisce all'applicazione di continuare.

2. ERROR:

   [ v1.2 : ..] eventi di errore che potrebbero comunque consentire all'applicazione di continuare a funzionare.

   Errore [ v2.0 : ..] nell'applicazione, possibilmente recuperabile.

3. WARN:

   [ v1.2 : ..] situazioni potenzialmente dannose.

   [ v2.0 : ..] evento che potrebbe [ sic ] portare a un errore.

4. INFO:

   [ v1.2 : ..] messaggi informativi che evidenziano l'avanzamento dell'applicazione a livello approssimativo.

   [ v2.0 : ..] evento a scopo informativo.

5. DEBUG:

   [ v1.2 : ..] eventi informativi dettagliati più utili per il debug di un'applicazione.

   [ v2.0 : ..] evento di debug generale.

6. TRACE:

   [ v1.2 : ..] eventi informativi più dettagliati rispetto al DEBUG.

   [ v2.0 : ..] messaggio di debug a grana fine, in genere acquisisce il flusso attraverso l'applicazione.

A Apache Httpd (come al solito) piace fare l'eccesso: §

1. emergere :

   Emergenze: il sistema è inutilizzabile.

2. avviso :

   È necessario agire immediatamente [ma il sistema è ancora utilizzabile].

3. critico :

   Condizioni critiche [ma non è necessario intervenire immediatamente].

   • " socket: impossibile ottenere un socket, uscita da figlio "

4. errore :

   Condizioni di errore [ma non critiche].

   • " Fine prematura delle intestazioni degli script "

5. avvertire :

   Condizioni di avvertimento. [vicino all'errore, ma non all'errore]

6. avviso :

   Condizione [ notevole ] normale ma significativa .

   • " httpd: catturato SIGBUS, tentando di scaricare il core in ... "

7. informazioni :

   Informativo [e non rilevabile].

   • ["Il server è in esecuzione da x ore. "]

8. debug :

   Messaggi a livello di debug [, ovvero messaggi registrati per motivi di rimozione del bugging )].

   • " Apertura file di configurazione ... "

9. Traccia1 → trace6 :

   Traccia messaggi [, ovvero messaggi registrati per motivi di traccia ].

   • " proxy: FTP: connessione di controllo completata "
   • " proxy: CONNECT: invio della richiesta CONNECT al proxy remoto "
   • " openssl: Handshake: start "
   • " letto dalla brigata SSL bufferizzata, modalità 0, 17 byte "
   • " ricerca mappa NON RIUSCITA:map=rewritemap key=keyname "
   • " ricerca nella cache NON RIUSCITA, forzando la ricerca di una nuova mappa "

10. trace7 → trace8 :

    Traccia messaggi, scaricando grandi quantità di dati

    • " | 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"
    • " | 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"

Apache commons-logging: §

1. fatale :

   Gravi errori che causano la risoluzione anticipata. Aspettati che siano immediatamente visibili su una console di stato.

2. errore :

   Altri errori di runtime o condizioni impreviste. Aspettati che siano immediatamente visibili su una console di stato.

3. avvertire :

   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.

4. informazioni :

   Eventi di runtime interessanti (avvio / arresto). Aspettati che siano immediatamente visibili su una console, quindi sii prudente e mantieni il minimo.

5. debug :

   informazioni dettagliate sul flusso attraverso il sistema. Aspettatevi che vengano scritti solo nei log.

6. traccia :

   informazioni più dettagliate. Aspettatevi che vengano scritti solo nei log.

Le "best practice" di registrazione comune di Apache per l'utilizzo aziendale fanno una distinzione tra debug e informazioni in base al tipo di confini che attraversano.

I confini includono:

• Confini esterni: eccezioni previste.

• Confini esterni: eccezioni impreviste.

• Confini interni.

• Significativi limiti interni.

(Vedi la guida alla registrazione dei beni comuni per maggiori informazioni al riguardo.)

Se riesci a risolvere il problema, allora è un avvertimento. Se impedisce l'esecuzione continua, si tratta di un errore.

Mi consiglia l'adozione di livelli di gravità Syslog: DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY.
Vedere http://en.wikipedia.org/wiki/Syslog#Severity_levels

Dovrebbero fornire livelli di gravità sufficienti per la maggior parte dei casi d'uso e sono riconosciuti dai parser di log esistenti. Ovviamente hai la libertà di implementare solo un sottoinsieme, ad esDEBUG, ERROR, EMERGENCY base ai requisiti della tua app.

Standardizziamo su qualcosa che esiste da secoli invece di elaborare il nostro standard per ogni diversa app che realizziamo. Una volta che si avvia l'aggregazione dei registri e si tenta di rilevare modelli tra quelli diversi, è di grande aiuto.

Avvisi da cui è possibile recuperare. Errori che non puoi. Questa è la mia euristica, altri potrebbero avere altre idee.

Ad esempio, supponiamo che tu inserisca / importi il ​​nome "Angela Müller"nella tua applicazione (annota l'umlaut sopra il u). Il tuo codice / database potrebbe essere solo in inglese (anche se probabilmente non dovrebbe essere in questi giorni) e potrebbe quindi avvisare che tutti i caratteri "insoliti" sono stati convertiti in normali caratteri inglesi.

Contrastalo con il tentativo di scrivere tali informazioni nel database e di recuperare un messaggio di rete inattivo per 60 secondi di seguito. È più un errore che un avvertimento.

Come altri hanno già detto, gli errori sono problemi; gli avvisi sono potenziali problemi.

In fase di sviluppo, utilizzo frequentemente avvisi in cui potrei mettere l'equivalente di un errore di asserzione, ma l'applicazione può continuare a funzionare; questo mi permette di scoprire se quel caso si verifica davvero, o se è la mia immaginazione.

Ma sì, si riduce agli aspetti di recuperabilità e attualità. Se riesci a recuperare, è probabilmente un avvertimento; se provoca effettivamente un errore, si tratta di un errore.

Penso che i livelli di SYSLOG AVVISO e ALERT / EMERGENCY siano in gran parte superflui per la registrazione a livello di applicazione - mentre CRITICAL / ALERT / EMERGENCY possono essere utili livelli di avviso per un operatore che può attivare azioni e notifiche diverse, per un amministratore dell'applicazione è lo stesso di FATALE. E non riesco proprio a distinguere sufficientemente tra il fatto di ricevere un avviso o alcune informazioni. Se le informazioni non sono degne di nota, non sono realmente informazioni :)

Mi piace di più l'interpretazione di Jay Cincotta: rintracciare l'esecuzione del codice è qualcosa di molto utile nel supporto tecnico e dovrebbe essere incoraggiata a inserire liberamente le dichiarazioni di traccia nel codice, specialmente in combinazione con un meccanismo di filtro dinamico per registrare i messaggi di traccia da specifici componenti dell'applicazione. Tuttavia, il livello DEBUG per me indica che stiamo ancora cercando di capire cosa sta succedendo: vedo l'output del livello DEBUG come un'opzione di solo sviluppo, non come qualcosa che dovrebbe mai apparire in un registro di produzione.

C'è comunque un livello di registrazione che mi piace vedere nei miei log degli errori quando indosso il cappello di un amministratore di sistema tanto quanto quello del supporto tecnico, o persino dello sviluppatore: OPER, per i messaggi OPERATIVI. Questo lo uso per registrare un timestamp, il tipo di operazione invocata, gli argomenti forniti, possibilmente un identificatore di attività (univoco) e il completamento dell'attività. Viene utilizzato quando, ad esempio, viene eseguita un'attività autonoma, qualcosa che è una vera chiamata all'interno dell'app più grande di lunga durata. È il tipo di cosa che voglio sempre registrato, indipendentemente dal fatto che qualcosa vada storto o no, quindi considero il livello di OPER più alto di FATAL, quindi puoi spegnerlo solo andando in modalità totalmente silenziosa. Ed è molto più che semplici dati di registro INFO: un livello di registro spesso abusato per i registri di spam con messaggi operativi minori senza alcun valore storico.

A seconda del caso, queste informazioni possono essere indirizzate a un registro di invocazione separato o possono essere ottenute filtrandole da un registro di grandi dimensioni che registra ulteriori informazioni. Ma è sempre necessario, come informazioni storiche, sapere cosa è stato fatto - senza scendere al livello di AUDIT, un altro livello di registro totalmente separato che non ha nulla a che fare con i malfunzionamenti o il funzionamento del sistema, non rientra nei livelli sopra indicati ( poiché necessita di un proprio interruttore di controllo, non di una classificazione di gravità) e che necessita sicuramente di un proprio file di registro separato.

Da RFC 5424, il protocollo Syslog (IETF) - Pagina 10:

Ogni messaggio prioritario ha anche un indicatore del livello di gravità decimale. Questi sono descritti nella tabella seguente insieme ai loro valori numerici. I valori di gravità DEVONO essere compresi nell'intervallo da 0 a 7 inclusi.

       Numerical         Severity
         Code

          0       Emergency: system is unusable
          1       Alert: action must be taken immediately
          2       Critical: critical conditions
          3       Error: error conditions
          4       Warning: warning conditions
          5       Notice: normal but significant condition
          6       Informational: informational messages
          7       Debug: debug-level messages

          Table 2. Syslog Message Severities

Buongiorno,

Come corollario di questa domanda, comunica le tue interpretazioni dei livelli di registro e assicurati che tutte le persone di un progetto siano allineate nella loro interpretazione dei livelli.

È doloroso vedere una vasta gamma di messaggi di registro in cui la gravità e i livelli di registro selezionati sono incoerenti.

Se possibile, fornire esempi dei diversi livelli di registrazione. Ed essere coerenti nelle informazioni da registrare in un messaggio.

HTH

Sono totalmente d'accordo con gli altri e penso che GrayWizardx l'abbia detto meglio.

Tutto quello che posso aggiungere è che questi livelli corrispondono generalmente alle loro definizioni del dizionario, quindi non può essere così difficile. In caso di dubbio, trattalo come un puzzle. Per il tuo particolare progetto, pensa a tutto ciò che potresti voler registrare.

Ora, puoi capire cosa potrebbe essere fatale? Sai cosa significa fatale, vero? Quindi, quali elementi nel tuo elenco sono fatali.

Ok, questo è fatale, adesso diamo un'occhiata agli errori ... risciacqua e ripeti.

Sotto Fatal, o forse Error, suggerirei che più informazioni sono sempre meglio di meno, quindi err "verso l'alto". Non sei sicuro che si tratti di Informazioni o Avviso? Quindi rendilo un avvertimento.

Penso che fatale ed errore dovrebbero essere chiari per tutti noi. Gli altri potrebbero essere più sfocati, ma è probabilmente meno vitale per farli bene.

Ecco alcuni esempi:

Fatale - impossibile allocare memoria, database, ecc. - Impossibile continuare.

Errore : nessuna risposta al messaggio, transazione interrotta, impossibile salvare il file, ecc.

Avviso : l'allocazione delle risorse raggiunge l'X% (diciamo l'80%) - questo è un segno che potresti voler ridimensionare il tuo.

Informazioni : accesso / disconnessione dell'utente, nuova transazione, file registrato, nuovo campo d / b o campo eliminato.

Debug - dump della struttura interna dei dati, livello di traccia di Anything con nome file e numero riga.
Traccia - azione eseguita / fallita, d / b aggiornato.

Un errore è qualcosa di sbagliato, assolutamente sbagliato, assolutamente impossibile, deve essere corretto.

Un avvertimento è un segno di un modello che potrebbe essere sbagliato, ma potrebbe anche non esserlo.

Detto questo, non posso trovare un buon esempio di avvertimento che non sia anche un errore. Quello che intendo con ciò è che se ti preoccupi di registrare un avviso, potresti anche risolvere il problema sottostante.

Tuttavia, cose come "l'esecuzione sql richiede troppo tempo" potrebbe essere un avvertimento, mentre "deadlock di esecuzione sql" è un errore, quindi forse ci sono alcuni casi dopo tutto.

Ho sempre considerato di avvertire il primo livello di registro che sicuramente significa che c'è un problema (ad esempio, forse un file di configurazione non è dove dovrebbe essere e dovremo correre con le impostazioni predefinite). Un errore implica, per me, qualcosa che significa che l'obiettivo principale del software è ora impossibile e proveremo a chiudere in modo pulito.

Ho creato sistemi prima che utilizzino quanto segue:

1. ERRORE - significa che qualcosa è seriamente sbagliato e quel particolare thread / processo / sequenza non può continuare. È richiesto un certo intervento utente / amministratore
2. ATTENZIONE: qualcosa non va, ma il processo può continuare come prima (ad es. Un lavoro in un set di 100 non è riuscito, ma il resto può essere elaborato)

Nei sistemi che ho creato, gli amministratori avevano ricevuto istruzioni per reagire agli ERRORI. D'altra parte, cercheremo AVVERTENZE e determineremo per ciascun caso se sono stati richiesti cambiamenti di sistema, riconfigurazioni ecc.

A proposito, sono un grande fan di catturare tutto e filtrare le informazioni in seguito.

Cosa succederebbe se si stesse acquisendo a livello di avviso e si desiderassero alcune informazioni di debug relative all'avviso, ma non si fosse in grado di ricreare l'avviso?

Cattura tutto e filtra in seguito!

Ciò vale anche per il software incorporato a meno che non si rilevi che il processore non è in grado di tenere il passo, nel qual caso si potrebbe voler riprogettare la traccia per renderla più efficiente, o la traccia interferisce con il tempismo (si potrebbe considerare il debug su un processore più potente, ma che apre un'intera lattina di worm).

Cattura tutto e filtra in seguito !!

(tra l'altro, catturare tutto è anche buono perché ti consente di sviluppare strumenti per fare qualcosa di più che mostrare semplicemente la traccia di debug (traggo grafici di sequenza messaggi dai miei e istogrammi di utilizzo della memoria. Ti dà anche una base per il confronto se qualcosa va storto in futuro (mantenere tutti i registri, sia passati che non riusciti, e assicurarsi di includere il numero di build nel file di registro)).

I miei due centesimi su FATALe TRACElivelli di registro degli errori.

ERROR è quando si verificano alcuni GUASTI (eccezione).

FATAL è in realtà DOPPIO GUASTO: quando si verificano eccezioni durante la gestione delle eccezioni.

È facile da capire per il servizio web.

1. Richiesta vieni. L'evento è registrato comeINFO
2. Il sistema rileva uno spazio su disco insufficiente. L'evento è registrato comeWARN
3. Alcune funzioni vengono chiamate per gestire la richiesta. Durante l'elaborazione della divisione per zero si verifica. L'evento è registrato comeERROR
4. Il gestore eccezioni del servizio Web viene chiamato per gestire la divisione per zero. Il servizio / framework Web invierà e-mail, ma non è possibile perché il servizio di mailing non è in linea ora. Questa seconda eccezione non può essere gestita normalmente, poiché il gestore eccezioni del servizio Web non può elaborare l'eccezione.
5. Chiamato gestore di eccezioni diverso. L'evento è registrato comeFATAL

TRACEè quando possiamo tracciare la funzione di entrata / uscita. Non si tratta di registrazione, perché questo messaggio può essere generato da alcuni debugger e il tuo codice non ha chiamato logaffatto. Quindi i messaggi che non provengono dalla tua applicazione sono contrassegnati come TRACElivello. Ad esempio, esegui l'applicazione constrace

Quindi in generale nel programma che fai DEBUG, INFOe WARNla registrazione. E solo se stai scrivendo un servizio / framework web utilizzerai FATAL. E quando esegui il debug dell'applicazione otterrai la TRACEregistrazione da questo tipo di software.

Suggerisco di usare solo tre livelli

1. Fatale - Che romperebbe l'applicazione.
2. Informazioni - Informazioni
3. Debug: informazioni meno importanti