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

introduzione

Se si verifica un errore su un sito Web o un sistema, è ovviamente utile registrarlo e mostrare all'utente un messaggio educato con un codice di riferimento per l'errore.

E se hai molti sistemi, non vuoi che queste informazioni siano tratteggiate: è bene avere un unico posto centralizzato per esso.

Al livello più semplice, tutto ciò che serve è un ID incrementale e un dump serializzato dei dettagli dell'errore. (E forse il "luogo centralizzato" è una casella di posta elettronica.)

All'altra estremità dello spettro c'è forse un database completamente normalizzato che consente anche di premere un pulsante e vedere un grafico degli errori al giorno o identificare quale sia il tipo più comune di errore sul sistema X, indipendentemente dal fatto che il server A abbia più database errori di connessione rispetto al server B e così via.

Ciò a cui mi riferisco qui è la registrazione di errori / eccezioni a livello di codice da parte di un sistema remoto, non di un rilevamento dei problemi "basato sull'uomo", come quello fatto con Jira, Trac, ecc.

Domande

Sto cercando pensieri dagli sviluppatori che hanno utilizzato questo tipo di sistema, in particolare per quanto riguarda:

• Quali sono le funzionalità essenziali di cui non potresti fare a meno?
• Cosa c'è di buono ad avere funzionalità che ti fanno davvero risparmiare tempo?
• Quali caratteristiche potrebbero sembrare una buona idea, ma in realtà non sono così utili?

Ad esempio, direi che una funzione "mostra duplicati" che identifica la ricorrenza multipla di un errore (senza preoccuparsi di dettagli "non importanti" che potrebbero differire) è piuttosto essenziale.
Un pulsante per "creare un problema in [Jira / etc] per questo errore" sembra un buon risparmio di tempo.

Giusto per ripetere, ciò che sto cercando sono le esperienze pratiche di persone che hanno utilizzato tali sistemi, preferibilmente supportate dal motivo per cui una funzionalità è fantastica / terribile.
(Se hai intenzione di teorizzare comunque, almeno segna la tua risposta come tale.)

Sono stato in un progetto in cui con errori client registrati utilizzando la libreria Microsoft Enterprise . Tutte le eccezioni sono inviate alla nostra casella di posta. Nell'oggetto mail abbiamo aggiunto il codice hash dell'errore serializzato per evitare messaggi duplicati. Si potrebbe ovviamente archiviare messaggi serializzati nel database e così via.

Ti consiglio di consultare la libreria Microsoft Enterprise e Log4Net .

Alcune caratteristiche di Log4Net

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

Nel caso di applicazioni di database, un 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 (ad es. Le parti specifiche della registrazione) sono implementate nella libreria aziendale come ha osservato Amir Rezaei. Tutto il resto sembra essere più parte dell'analisi (ad es. 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:

• Raggruppare gli stessi errori (vale a dire 100 utenti che hanno riscontrato lo stesso errore nello stesso momento sono 1 segnalazione di bug con una nota di quante occorrenze si sono verificate)
• Archiviazione automatica di un ticket nel tracker del caso (non sono mai riuscito a farlo "con un clic di un pulsante", ma ho sempre voluto farlo)
• Nome utente dell'utente del software (non solo della macchina, 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 guardare Mike fare un po 'di lavoro, continua a causare un errore specifico."
• "Azioni dell'utente" - Avevo uno stack globale che avrebbe tenuto traccia di ogni clic / pulsante utilizzabile mentre l'utente lo faceva e lo aveva attaccato ai log degli errori. La riproduzione dell'errore era spesso un caso di camminare attraverso quella traccia ed eseguire gli stessi passaggi dell'utente (avevo sperato di costruire un generatore di test CodedUI che avrebbe analizzato la traccia ed eseguito i passaggi automaticamente, ma mai fatto)

A volte, le informazioni del registro sono troppo voluminose per essere memorizzate sul 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: $!";
    }
}

quindi un analista può estrarre ciò che vuole guardare.

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

• Essere in grado di eseguire la coda di un file di registro a rotazione (generalmente utilizzo log4net / log4j per accedere alle applicazioni e BareTail per seguire il registro) è davvero utile per poter verificare lo stato corrente di un sistema
• Per vedere quando sono stati introdotti i problemi e la frequenza con cui si verificano i problemi è bello averli in un database con timestamp a cui è possibile eseguire i report.
• La possibilità di inviare e-mail / sms / avvisi vocali è estremamente utile per assicurarsi che i sistemi rimangano attivi, ma devi avere la possibilità di personalizzare facilmente quali tipi di errori che ti avvisano. Se ricevi 800 e-mail di errore al giorno, ti perderai sicuramente quello "Oh no, il data center è in fiamme".

Ho ottenuto ottimi risultati per log4net perché rende molto semplice l'accesso a più posizioni e anche la modifica della configurazione della registrazione.

elmah è un sistema di registrazione degli errori open source per le app ASP.NET e può essere aggiunto a un sistema esistente (usando NuGet http://nuget.codeplex.com/ ) rapidamente e facilmente. Supporta vari backend e funzioni di notifica.

Non conosco nessuno che l'abbia aggiunta a un'app desktop in quanto funziona come un sito Web, ma non c'è nulla che ti impedisca di eseguirlo come servizio e di pubblicare le tue eccezioni attraverso il web.

http://code.google.com/p/elmah/

ELMAH (Error Logging Modules and Handlers) è una funzione di registrazione degli errori a livello di applicazione che è completamente collegabile. Può essere aggiunto dinamicamente a un'applicazione Web ASP.NET in esecuzione o anche a tutte le applicazioni Web ASP.NET su una macchina, senza necessità di ricompilare o ridistribuire.

Una volta che ELMAH è stato rilasciato in un'applicazione Web in esecuzione e configurato in modo appropriato, si ottengono le seguenti funzionalità senza modificare una singola riga del codice:

• Registrazione di quasi tutte le eccezioni non gestite.
• Una pagina Web per visualizzare in remoto l'intero registro delle eccezioni ricodificate.
• Una pagina Web per visualizzare in remoto tutti i dettagli di un'eccezione registrata, comprese le tracce colorate dello stack.
• In molti casi, è possibile rivedere la schermata gialla della morte originale che ASP.NET ha generato per una determinata eccezione, anche con la customErrorsmodalità disattivata.
• Una notifica e-mail di ogni errore nel momento in cui si verifica.
• Un feed RSS degli ultimi 15 errori dal registro ...