Lavoro con i sistemi di sicurezza in tempo reale critici e il logging è spesso l'unico modo per catturare bug rari che si presentano una volta una luna blu ogni 53rd martedì quando è una luna piena, se riesci a cogliere la mia direzione. Questo ti rende ossessivo riguardo all'argomento, quindi mi scuserò ora se comincio a far schiumare alla bocca. Quanto segue è stato scritto per i log di debug del codice nativo, ma la maggior parte è applicabile anche al mondo gestito ...
Usa i file di log di testo. Sembra ovvio, ma alcune persone cercano di generare file di log binari: è semplicemente stupido perché non ho bisogno di cercare uno strumento di lettura quando sono fuori sul campo. Inoltre, se si tratta di testo e il debug è prolisso, ci sono buone probabilità che il tecnico di campo possa leggere il file e diagnosticare il problema senza mai tornare da me. Tutti vincono.
Ho progettato sistemi in grado di registrare praticamente tutto, ma non accendo tutto per impostazione predefinita. Le informazioni di debug vengono inviate a una finestra di debug nascosta che la marca e la stampa in una listbox (limitata a circa 500 righe prima della cancellazione), e la finestra di dialogo mi permette di fermarla, salvarla automaticamente in un file di log o deviarla su un debugger allegato. Quel diversivo mi permette di vedere l'output di debug di più applicazioni tutte ordinatamente serializzate, che a volte può essere un risparmiatore di vita. Io usato per usare i livelli di registrazione numerica (più alto è il livello, più acquisisci):
off
errors only
basic
detailed
everything
ma questo è troppo inflessibile - mentre ti dirigi verso un bug è molto più efficiente essere in grado di focalizzare l'accesso esattamente su ciò di cui hai bisogno senza dover attraversare tonnellate di detriti, e potrebbe essere un tipo particolare di transazione o operazione che causa l'errore. Se ciò richiede di attivare tutto, stai solo rendendo più difficile il tuo lavoro. Hai bisogno di qualcosa di più fine.
Quindi ora sto passando alla registrazione basata su un sistema di flag. Tutto ciò che viene registrato ha un flag che indica in dettaglio il tipo di operazione, e c'è un set di checkbox che mi consente di definire cosa viene registrato. In genere questo elenco ha il seguente aspetto:
#define DEBUG_ERROR 1
#define DEBUG_BASIC 2
#define DEBUG_DETAIL 4
#define DEBUG_MSG_BASIC 8
#define DEBUG_MSG_POLL 16
#define DEBUG_MSG_STATUS 32
#define DEBUG_METRICS 64
#define DEBUG_EXCEPTION 128
#define DEBUG_STATE_CHANGE 256
#define DEBUG_DB_READ 512
#define DEBUG_DB_WRITE 1024
#define DEBUG_SQL_TEXT 2048
#define DEBUG_MSG_CONTENTS 4096
Questo sistema di registrazione viene fornito con la build release , attivata e salvata su file per impostazione predefinita. È troppo tardi per scoprire che dovresti aver effettuato la registrazione DOPO che il bug si è verificato, se quel bug si verifica solo una volta ogni sei mesi in media e non hai modo di riprodurlo. La registrazione che funziona solo con le build di debug è giusta. pianura. muto.
Il software normalmente viene fornito con ERROR, BASIC, STATE_CHANGE ed EXCEPTION attivati, ma può essere modificato nel campo tramite la finestra di dialogo debug (o un'impostazione di registro / ini / cfg, dove vengono salvati questi elementi).
Oh e una cosa: il mio sistema di debug genera un file al giorno. I tuoi requisiti potrebbero essere diversi. Ma assicurati che il tuo codice di debug inizi con ogni file con la data, la versione del codice che stai utilizzando e, se possibile, qualche indicatore per l'ID cliente, la posizione del sistema o altro. Puoi ottenere una mistura di file di registro che arrivano dal campo e hai bisogno di un registro di ciò che è venuto da dove e di quale versione del sistema stavano girando che è effettivamente nei dati stessi, e non puoi fidarti del cliente / field engineer per dirti quale versione hanno - potrebbero solo dirti quale versione PENSANO che hanno. Peggio ancora, potrebbero riportare la versione exe presente sul disco, ma la vecchia versione è ancora in esecuzione perché si sono dimenticati di riavviarsi dopo la sostituzione. Chiedi al tuo codice di darti.
Infine, non vuoi che il tuo codice generi i suoi problemi, quindi metti una funzione timer per eliminare i file di log dopo tanti giorni o settimane (basta controllare la differenza tra ora e ora della creazione del file). Questo è OK per un'app server che viene eseguita in qualsiasi momento, su un'app lato client, che puoi eliminare eliminando i vecchi dati all'avvio. Normalmente eliminiamo dopo circa 30 giorni, su un sistema senza frequenti visite di un ingegnere, potresti voler lasciarlo più a lungo. Ovviamente questo dipende anche dalla dimensione dei tuoi file di registro.