Qual è il modo migliore per gestire la registrazione degli errori per le eccezioni?

Sono stato in un progetto in cui gli errori dei client registrati si sono verificati utilizzando libreria Microsoft Enterprise . Tutte le eccezioni dove inviare alla nostra casella di posta elettronica. Nell'oggetto della posta abbiamo aggiunto il codice hash dell'errore serializzato per evitare messaggi duplicati. Ovviamente è possibile archiviare i messaggi serializzati nel database e così via.

Ti consiglio di controllare libreria Microsoft Enterprise e Log4Net .

Alcune caratteristiche di Log4Net

• Supporto per più framework
• Output su più target di registrazione
• Architettura di registrazione gerarchica
• Configurazione XML
• Configurazione dinamica
• Contesto di registrazione
• Architettura collaudata
• Design modulare ed estensibile • Elevate prestazioni con flessibilità

Nel caso di applicazioni di database, un qualche tipo di ID (come <TABLE>:<PrimaryKeyID> ) che consente di tenere traccia dei record nel database relativi all'ambito in cui è stata rilevata l'eccezione.

L'ho fatto con Oracle e PL / SQL, registrando l'ID in una tabella di database all'interno dell'applicazione, dal gestore delle eccezioni.

Gran parte di ciò che descrivi (cioè le parti specifiche del logging) sono implementate nella libreria aziendale come ha osservato Amir Rezaei. Tutto il resto sembra essere più parte della parte analitica (cioè cosa fare con i log in seguito).

Nel mio caso, ho creato alcune piccole app e script sql che hanno semplificato alcune cose. Ecco alcune delle cose che mi sono piaciute molto:

• Raggruppamento degli stessi errori insieme (ad esempio, 100 utenti hanno tutti riscontrato lo stesso bug nello stesso periodo di tempo è 1 segnalazione di bug con una nota di quante occorrenze c'erano)
• Archiviazione automatica di un ticket nel tracker del caso (mai riuscito a renderlo 'con un clic di un pulsante' ma sempre voluto)
• Nome utente dell'utente del software (non solo la macchina, che è disponibile con la maggior parte dei logger). In alcuni casi, gli account degli utenti automatizzati hanno causato problemi mentre in altri, gli utenti specifici erano la causa dei problemi. "Devo vedere che Mike fa del lavoro, continua a causare un errore specifico."
• "Azioni utente" - Avevo uno stack globale che avrebbe tenuto traccia di ogni clic azionabile / pulsante premuto mentre l'utente lo faceva e lo aveva attaccato ai log degli errori. Riprodurre l'errore era spesso un caso di camminare attraverso quella traccia ed eseguire gli stessi passi dell'utente (avevo sperato di costruire un generatore di test CodedUI che potesse analizzare la traccia ed eseguire i passaggi automaticamente, ma mai fatto)

A volte, le informazioni del registro sono troppo voluminose per essere memorizzate su disco. Un approccio che ho visto è quello di scrivere le voci di registrazione su un firehose (in, diciamo, perl) qualcosa del genere:

# Create socket.
my $sock = IO::Socket::INET->new(
    Proto       => 'udp',
    PeerAddr    => $bcastaddr,
    Broadcast   => 1,
) or die "Can't create socket ($bcastaddr): $!";

while (<>) {
    chomp;
    unless (/File\ does\ not\ exist:/) {
        $sock->send("$eventtype:$_") or warn "Can't send: $!";
    }
}

allora un analista può ignorare ciò che vuole guardare.

Ecco alcune cose che ho imparato dal monitoraggio degli errori nelle nostre applicazioni:

• Essere in grado di gestire un file di registro progressivo (generalmente utilizzo log4net / log4j per l'accesso alle applicazioni e BareTail seguire il log) è davvero utile per poter verificare lo stato attuale di un sistema
• Per vedere quando sono stati introdotti problemi e la frequenza con cui si verificano i problemi, è bello averli in un database con data e ora in cui è possibile eseguire i report.
• La possibilità di inviare e-mail / sms / avvisi vocali è molto utile per assicurarsi che i sistemi rimangano in piedi, ma devi avere la possibilità di personalizzare facilmente i tipi di errori che ti avvisano. Se ricevi 800 e-mail di errore al giorno, ti perdi il numero "Oh no, il data center è in fiamme".

Ho ottenuto ottimi risultati per log4net perché rende molto semplice accedere a più posizioni e apportare modifiche alla configurazione di registrazione anche in modo semplice.

elmah è un sistema di registrazione degli errori open source per app ASP.NET e può essere aggiunto a un sistema esistente (utilizzando NuGet link ) rapidamente e facilmente. Supporta vari backend e funzioni di notifica.

Non conosco nessuno che lo abbia aggiunto a un'app desktop mentre viene eseguito come un sito Web, ma non c'è nulla che ti impedisca di eseguirlo come servizio e di pubblicarne le eccezioni attraverso il web.

link

ELMAH (Error Logging Modules and Handlers) is an application-wide error logging facility that is completely pluggable. It can be dynamically added to a running ASP.NET web application, or even all ASP.NET web applications on a machine, without any need for re-compilation or re-deployment.

Once ELMAH has been dropped into a running web application and configured appropriately, you get the following facilities without changing a single line of your code:

• Logging of nearly all unhandled exceptions.
• A web page to remotely view the entire log of recoded exceptions.
• A web page to remotely view the full details of any one logged exception, including colored stack traces.
• In many cases, you can review the original yellow screen of death that ASP.NET generated for a given exception, even with customErrors mode turned off.
• An e-mail notification of each error at the time it occurs.
• An RSS feed of the last 15 errors from the log...