Scrittura nel registro eventi: best practice se il registro è pieno

Naviga le tue risposte
2

Ho un'applicazione che scrive sulla propria origine evento. La Source Event stessa viene creata al momento dell'installazione per prevenire problemi di accesso dell'utente vs admin in fase di runtime.

Se la scrittura sulla nostra propria origine evento non riesce, l'evento viene invece scritto nel registro dell'applicazione (due eventi, in realtà, per i dati dell'evento originale e un altro che dice "Impossibile scrivere nel registro eventi personale perché ..." o qualcosa di simile).

Recentemente abbiamo scoperto un problema che quando il registro eventi dell'applicazione è pieno, l'eccezione non è gestita. Ora concesso, potrei solo mangiare l'eccezione (simile a ciò che questa risposta dice).

Quindi qual'è il miglior comportamento? L'applicazione sta tentando di registrare il problema e tenta di registrare che c'è un problema. Dovrei mangiare l'eccezione, lasciare che l'operazione di registrazione fallisca silenziosamente e continuare l'esecuzione? O dovrei lasciare che l'eccezione riempia lo stack di chiamate in modo che l'utente / lo sviluppatore sappia del problema?

Qual è l'approccio consigliato in queste condizioni?

    
posta MoSlo 08.12.2011 - 08:15
fonte

3 risposte

1

Usa log4net con EventLogAppender. Può degradare con grazia e scrivere al suo logger interno perché ha fallito. Puoi facilmente dimenticare di preoccuparti di mantenere il tuo codice che scrive i registri su EventLogger.

    
risposta data 08.12.2011 - 11:28
fonte
1

Dalla tua descrizione sembra che dovresti provare a impostare il tuo registro eventi per sovrascrivere le voci precedenti. Ma non sono chiaro per quale motivo si registrano gli eventi in primo luogo.

Mangiando solo l'eccezione, per me, indica che in realtà non vuoi il log in primo luogo; è un po 'come il buon vecchio VB "On Error Resume Next". Quindi se sei disposto a mangiare l'eccezione, potresti essere disposto a scaricare il log. Se non lo fai, e continui a mangiare l'eccezione, il log degli eventi sarà imperfetto in quanto sembrerà che non si siano verificati eventi dalla data di pubblicazione completa.

Se le eccezioni sono effettivamente importanti, dovresti lasciarle sbarrare lo stack in modo che un utente / amministratore sia costretto a prendere provvedimenti.

EDIT: Penso che se si dispone di una macchina in cui l'utente / amministratore consente sia il log sia il registro eventi di funzionare al massimo, pur non consentendo sovrascritture; (s) probabilmente non gli importa davvero. Penso che non vorrei lanciare un errore e interrompere l'esecuzione - ma piuttosto provare a notificare in modo più discreto - vale a dire. attivazione di un'etichetta o aggiornamento del testo di stato o simili a seconda dell'interfaccia utente.

    
risposta data 08.12.2011 - 08:27
fonte
0

A seconda delle esigenze, un'opzione potrebbe essere quella di utilizzare il Microsoft Enterprise Library blocco di registrazione. L'ho usato con successo per accedere ai flatfile e ai database interni. È possibile impostare la dimensione dei file di registro e il comportamento quando un determinato file raggiunge la sua dimensione massima. È una libreria abbastanza flessibile (open source) che vale almeno una visita.

    
risposta data 09.12.2011 - 02:14
fonte

Leggi altre domande sui tag

Layout del file system per più target di compilazione Best practice per la modellazione di un'entità di registrazione attiva che utilizza Linq-To-SQL come DAL