Che cos'è un buon layout per un file di registro errori standard?

Question

Sto provando a progettare il file di registro degli errori e degli avvisi per il mio programma desktop.

Come il mio programma legge il file di input dell'utente, può trovare errori di sintassi o dati non validi di qualche tipo. Una volta che tutto è stato letto e il programma sta elaborando i dati, è possibile trovare più problemi.

Desidero scrivere messaggi su questi in un semplice file di testo. Potrei anche voler includere il testo informativo per indicare progresso, tempo, uso della memoria, ecc. Vorrrò includere i numeri di riga e forse anche le linee di input reali che causano gli errori.

Questo sarà un file che l'utente vorrà sfogliare, quindi ovviamente deve essere ben strutturato e facile da usare.

Conosci qualche guida di stile per questo, o hai visto un file di log degli errori che ti ha fatto pensare a te stesso: "Questo è un file di log ben progettato!"

---

ollowup:

Le prime tre risposte sono in realtà più applicabile per un log del server o di un evento.

Sono davvero alla ricerca di un formato per un file di registro per il mio programma desktop per descrivere tutti i problemi riscontrati con il file di input e il successo (o il fallimento) della sua elaborazione.

Sono sicuro che ci sono alcune applicazioni desktop che sono state utilizzate per produrre tali file di registro. Hai visto dei buoni?

Answer 1

syslog e log4j sono formati ampiamente utilizzati con cui gli amministratori di sistema possono essere familiari e ci sono strumenti per lavorare con essi. Dovresti almeno guardarli prima di fare il tuo formato.

Per Windows è praticamente sempre il registro eventi applicazioni, che non mi piace tanto quanto un file di testo, ma è il modo giusto. Ho visto alcune app che scrivono file di testo nella loro directory del programma o qualcosa del genere, ma è sempre ad hoc, mai standard. McAfee VirusScan, ad esempio, registra i file in C: \ Documents and Settings \ All Users \ Application Data \ McAfee \ DesktopProtection. La mia macchina ha molti registri di installazione in C: \ Documents and Settings \ username \ Impostazioni locali \ temp * .log e C: \ WINDOWS \ temp * .log. Ma ancora una volta, sono tutti diversi e ad hoc e non molto ben progettati

Answer 2

Scrivo i registri in file CSV e lo trovo molto comodo (è possibile utilizzarli come base dati o aprirli con un foglio elettronico per analisi sofisticate). Il file di registro di esempio è:

Date;Time;Severity;TID;Module;This;Source;Message 
2010/01/21;08:47:05:205;DEBUG;4936;MAIN;0x00000000;DllMain@36;DLL_PROCESS_ATTACH 
2010/01/21;08:47:05:205;DEBUG;4936;MAIN;0x00000000;DllMain@40;DLL_PROCESS_DETACH 

non sono sicuro se si adatta alle vostre esigenze, ma penso che tu hai l'idea principale. In bocca al lupo!

Answer 3

Sono pochi i file di registro in cui sono rimasto veramente colpito - in realtà, faccio fatica a pensare a qualsiasi (e non riesco a trovarne nessuno). Nella mia esperienza, i problemi che ne derivano si verificano in parte perché i registri sono formattati per essere compresi da un insider (programmatore), piuttosto che per un altro programma o un estraneo (non programmatore) da comprendere.

Spesso le informazioni cruciali sono omesse; a volte anche informazioni su data e ora. Consiglierei di renderli facilmente analizzabili; Userei una notazione ISO 8601 come "2010-01-22T10: 23: 21-08: 00" (incluso il fuso orario, nota). Includerei l'ID di processo (e del thread); Prenderò in considerazione l'inclusione del nome del programma, degli argomenti (ad esempio il nome del file); Includerei anche l'ID utente in qualche modo. Alcuni di questi potrebbero essere necessari solo una volta per esecuzione, ma altri bit potrebbero essere necessari per ciascun messaggio. Dipende in parte se il file di registro è univoco per esecuzione o condiviso tra le esecuzioni e se un singolo file può essere utilizzato da più di un utente/processo.

Quindi è necessario decidere come identificare il contenuto del messaggio e la fine del contenuto del messaggio. Soprattutto per l'analisi della macchina (ma anche per l'analisi umana), è utile se il contenuto è formattato in modo non ambiguo e la fine può essere rilevata. Potrebbe essere necessario sfuggire al contenuto (questo è il passaggio più frequentemente annullato, quindi se il messaggio di errore riguarda un messaggio di errore mal formato, è davvero difficile dire quali sono i dati del file e quale è il nuovo messaggio di errore sui dati nel file).In un programma multi-thread o in cui il file di log potrebbe essere condiviso tra i processi, è necessario considerare come anche le scritture verranno memorizzate nel buffer, specialmente se si devono gestire le lunghe code. Si desidera che ciascun messaggio sia singolarmente separato nel file di registro. Questo non è necessariamente banale: potresti persino aver bisogno di gestire un protocollo di blocco per garantire l'accesso controllato.

Considerare se è necessario fornire una stampante carina per il registro.

Considerare se un formato basato su XML (con tag iniziale e finale) sarebbe di aiuto. Non sono un grande fan di XML, ma ha alcuni vantaggi per l'elaborazione della macchina.