Come posso rendere più utile la mia registrazione? [duplicare]

Il problema con i log è che gli sviluppatori usano i log per aiutarli a eseguire il debug del software piuttosto che quelli che usano il software. Aggiungono messaggi che hanno senso solo a loro e rimuovono i messaggi quando non sono necessari. Questa è una cattiva pratica.

Le voci di registro come "Wtfwtf" aiutano solo uno sviluppatore che può cercare quella stringa nel codice. Una soluzione migliore è quella di registrare qualcosa che abbia un senso per un operatore o un cliente. Ciò aiuta sia lo sviluppatore che l'operatore o il cliente.

Nel tuo caso, vorrei:

1. Registra le informazioni quando ha senso per un cliente o un operatore, non per lo sviluppatore. Se lo sviluppatore vuole registrare le informazioni di debug, va bene, ma spogliatelo in produzione, spegnerlo per impostazione predefinita (a livello di registrazione) o distinguerlo chiaramente dagli altri messaggi.
2. Fornisci molte informazioni. Hai un errore quando l'utente fa un'operazione X su Y? Includere il nome utente, i dettagli di Y, la data, ecc. La maggior parte dei sistemi registra troppo poche informazioni piuttosto che troppo.
3. Non registrare informazioni sensibili alla sicurezza o riservate, come password o chiavi di crittografia. Fai attenzione a registrare tracce dello stack o cose che mostrano anche il layout interno del codice.
4. registra tutti gli errori, anche se sembrano non importanti, e cosa ha fatto il sistema (riprovato, abortito, comportamento diverso).
5. Non registrare le informazioni sulle prestazioni o altre cose per cui un registro non è adatto. Ad esempio, su Windows, utilizzare invece i contatori delle prestazioni di Windows.
6. Utilizza un formato di voce di registro coerente. Ad esempio, è possibile importare i registri in un database per fornire alcune metriche per la gestione o per cercare rapidamente tra più file di registro per ottenere informazioni. Assicurarsi che ogni voce del registro abbia la stessa struttura, le date e le ore abbiano lo stesso formato e che tutti i valori enumerati abbiano valori definiti e utilizzati in modo coerente. Nel tuo caso, assicurati che tutti i messaggi di "brutto" debug siano scritti almeno nel formato corretto.
7. Accedi utilizzando le date e le ore UTC. Le modifiche all'ora legale sono cause comuni di problemi. Aiuta anche a essere in grado di correlare facilmente i problemi da diversi server o file di registro.
8. Considera la conservazione / archiviazione / eliminazione dei log. I file di registro possono crescere molto rapidamente, consumare spazio e renderli difficili da cercare. Ad esempio, crea un nuovo file ogni giorno ed elimina i file più vecchi di un mese. Se viene creato un nuovo file di registro quando viene eseguito il programma, assegnargli un nome univoco in modo che i registri di precedenti esecuzioni non vengano sovrascritti.
9. Se i registri hanno segmenti di pubblico diversi, registrali in posizioni diverse. Ad esempio, registrare le informazioni sensibili sulla sicurezza (informazioni di controllo) separatamente. Spesso è necessario per la conformità e non dovrebbe essere manomesso.
10. I log sono raramente localizzati in lingue diverse, ma i log potrebbero dover contenere stringhe contenenti set di caratteri diversi. Utilizzare una codifica adatta (ad esempio UTF-8) in modo coerente.

Un modo semplice per affrontare molti di questi è considerare un framework di registrazione come log4J o log4net. Questi forniscono un formato strutturato, consentono la scrittura del log in posizioni diverse o multiple (ad esempio un database) e spesso utilizzano un pool di thread separato per impedire che la registrazione diventi un collo di bottiglia. Ti proteggerà anche da Iniezione CRLF dove qualcuno potrebbe tentare accidentalmente o intenzionalmente di manipolare le voci del registro.

Se il software viene utilizzato internamente, la tua organizzazione potrebbe disporre di standard di registrazione o monitoraggio che coprono parte di questo aspetto, in particolare il formato e la conservazione del registro.

Riguardo all'elaborazione di cosa registrare, quali sono i passaggi dell'algoritmo? Suddividi l'algoritmo in passaggi e registra il risultato di ciascuno di essi. Fai finta di essere il programma che spiega a un umano come hai trovato i tuoi risultati. È come mostrare il tuo lavoro quando si fa un problema di matematica a scuola. Inizia con i passaggi di alto livello, quindi lavora più a fondo.

Nel tuo caso, descrivi l'applicazione come "trovare un percorso in un grafico di nodi di rete e stabilire un percorso attraverso di essi". Sembra che ci siano due fasi: trovare il percorso e poi stabilirlo. Registra quelli. Quindi, cosa è coinvolto nel trovare un percorso? Sembra un'enumerazione di un grafico diretto. Esistono ottimizzazioni che possono escludere parti del grafico o consigliarne altre? Includi eventuali dettagli su di loro. Per quanto riguarda la creazione di un percorso, registra i dettagli di ogni dispositivo, se le connessioni sono state create correttamente e così via.

Di solito si dice che la registrazione è per gli operatori del tuo software. Tuttavia, questo non è del tutto vero, poiché i registri di DEBUG vengono solitamente attivati durante lo sviluppo, a beneficio degli sviluppatori.

Tendo a considerare i diversi livelli come interessanti per diversi ruoli:

• DEBUG: solo gli sviluppatori
• INFO: operatori / sviluppatori
• ATTENZIONE: operatori
• ERRORE / CRITICO: utenti

"Sviluppatori" sono persone con accesso al codice sorgente; "operatori" sono persone con accesso alla configurazione e a tutte le interfacce di sistema (l'interfaccia utente e possibilmente un'interfaccia amministrativa); e "utenti" sono persone che hanno solo accesso a un'interfaccia, ovvero l'interfaccia dell'utente desiderata.

Ciò significa che, quando si verifica un errore, uno sviluppatore può riavviare l'applicazione con un codice completamente diverso; un operatore può riavviarlo con una configurazione diversa; e un utente può semplicemente riprovare con un altro input.

Proprio come, in un'eccezione, dovresti mettere abbastanza informazioni per permettere al codice client di recuperare dalla situazione eccezionale, in una dichiarazione di log dovresti mettere abbastanza informazioni per permettere alla persona che la sta leggendo di cambiare qualsiasi cosa lui / lei possa cambiare sul sistema , al fine di realizzare qualsiasi cosa fosse la sua intenzione.

Quindi, se si tratta di un'istruzione DEBUG, indicare quali variabili o metodi non soddisfano la condizione, se si tratta di un WARNING, indica quale parte del sistema non è reattiva e deve essere riavviata o riconfigurata, e se è un ERRORE, indica quale input è sbagliato e perché non può essere elaborato.

Ricorda che non puoi sapere che cosa deve essere fatto (è per questo che gli operatori esistono), ma ricorda anche che al punto di logging hai tutte le informazioni su che cosa sta andando male .

Solo i miei due centesimi.

Questo è quello che sto facendo nel mio ultimo progetto - per la prima volta, quindi non sono totalmente testato in produzione.

#9384752 --- Jan 4, 2014 4:58:16 >>> FAILED :: [Chart] render <<< chart.class.php @ 43

E analizza come:

• #9384752 Identificatore univoco per trovare / marcare più facilmente ciascuna linea separata.
• --- Un separatore molto visibile e intuitivo.
• Jan 4, 2014 4:58:16 data / ora leggibile dall'uomo
• >>> Un separatore molto visibile e intuitivo.
• FAILED Stato del record.
• :: Ancora, separatore.
• [Chart] Nome del modulo.
• render Il messaggio di registro effettivo.
• <<< Separator.
• chart.class.php Nome file.
• @ Separator.
• 43 Numero di riga.

L'idea è di avere un utile debug log - nell'esempio sopra, così ho cercato di renderlo leggibile il più possibile. Quelli --- , >>> e <<< , mi aiutano tutti a leggere il registro più facilmente. Inoltre, è più facile Cerca tra i registri, ad es. >>> FAILED :: è univoco nell'intero record, quindi può essere una parola chiave per saltare tra i record senza la necessità di saltare tra parole simili nei messaggi di registro. Anche l'analisi dei record di log con Espressioni regolari o le funzioni di stringa è molto più semplice.

Anche l' Identificatore del record mi aiuta ad indirizzare quel record specifico più tardi o quando assegni compiti ad altri sviluppatori.

Il Log Message stesso è piuttosto breve perché odio perdermi tra un sacco di parole e devo leggerle per capire cosa sta succedendo. Nell'esempio sopra posso semplicemente capire che:

render method of Chart module, located in chart.class.php has failed at line 43.

Letteralmente in un secondo.

Quindi i punti chiave sono:

• Rendilo utilizzabile
• Rendilo leggibile e intuitivo
• Rendi la ricerca
• Affrontare il problema, il più breve possibile, ma includere le informazioni necessarie
• Trova dove si è verificato l'errore

P.S. Come ho detto questa è la prima volta che sto usando questo formato in un progetto, quindi ci sono potenzialmente dei difetti di progettazione di cui non sono a conoscenza.

P.P.S. Questo è il mio registro di debug per sviluppatori, quindi qualcuno potrebbe non trovarlo molto adatto per altri scopi di registrazione.