Tracciamento errori nelle applicazioni web live / di produzione

StackOverflow https://stackoverflow.com/questions/236851

  •  04-07-2019
  •  | 
  •  

Domanda

Attualmente lavoro in un'azienda che ha molte applicazioni personalizzate realizzate internamente. Al momento non ci sono standard per molte cose. Vorrei implementare un modo per registrare / tenere traccia degli errori che si verificano in questi programmi (la maggior parte sono asp.net).

Attualmente sto pensando di gestirlo in Global.asax nel metodo Errore applicazione. Prima prova a salvare le informazioni in un registro errori / database di tracciamento e, in caso contrario, prova a inviare un'e-mail.

Quale tipo di informazioni è più utile per ottenere dal messaggio di errore e da altre variabili dell'applicazione (pagina, nome utente ecc.)

Attualmente sto pensando di utilizzare due tabelle, una per ottenere l'errore generale e le informazioni sull'applicazione e una seconda che contiene le informazioni sull'eccezione. Questa sarà una relazione una a molte per gestire le Eccezioni interne che possono derivare da un'eccezione a livello di Applicazione.

Sono sicuro che mi mancano molti dettagli e vorrei sentire la tua strategia per gestire questo problema.

È stato utile?

Soluzione

Jeff Atwood ha scritto un ottimo gestore delle eccezioni che dovresti guardare su CodeProject

Tenterei di raccogliere quante più informazioni possibili. Informazioni sullo stack Informazioni sulla sessione Posizione dell'errore

Vorrei anche impostare un servizio web che le applicazioni chiamano per salvare le informazioni sull'eccezione nel tuo sistema.

Altri suggerimenti

Penso che ELMAH potrebbe essere quello che stai cercando.

Se si utilizza una libreria di registrazione (come Log4Net), è possibile impostare varie appendici di registrazione per accedere a e-mail, DB, file, registro eventi, ecc. mentre si dispone di una singola chiamata nel codice. Questo post copre tutto ciò di cui hai bisogno per ottenere iniziato.

C'è anche Monitoraggio dello stato di ASP.NET .

EDIT: un altro poster menziona ELMAH, che è ottimo per la registrazione degli errori ASP.NET e può essere "iniettato" dinamicamente nelle app in esecuzione.

Questo è quello che faccio e ho ancora un bug a causa di un problema di posta elettronica.

Non conservo mai nulla sul DB, perché se il DB ha un errore non avrò mai quell'errore sulla causa del DB, logicamente, l'inserimento fallirà!

Quindi invio un'email a un indirizzo email speciale come bugs@mydomain.com

Oggetto : [Nome applicazione] [Timestamp: ddmmyyyy hhmmss] Messaggio : applicazione, messaggio di errore, informazioni sulla traccia dello stack più variabili di sessione come nome utente e variabili del server come referrer.

il migliore amico di uno sviluppatore ASP.NET è le informazioni di stack stack , è qui che saprai cosa è andato storto, quale era la chiamata e dove stava chiamando.

l'unico problema che hai in questo sistema, è che non otterrai nulla se l'e-mail ha un problema (qualche eccezione durante l'invio dell'email), e per questo ho iniziato ad aggiungere un anche il file XML mensile [errorLog_ mmm_yyyy.xml] e reso semplice il "trascinamento della selezione"; pagina con una griglia che ha caricato l'XML per il mese e l'anno in cui volevo verificare gli errori. 

try 
{
   // production code
}
catch(Exception ex)
{
   Utilities.Mail.SendError(ex);
}

o il modo migliore: aggiungilo a Application_Error in global.asax: 

<%@ Application Language="C#" %>
<%@ Import Namespace="System.Diagnostics" %>
<script language="C#" runat="server">
void Application_Error(object sender, EventArgs e)
{
   //get reference to the source of the exception chain
   Exception ex = Server.GetLastError().GetBaseException();

   //log the details of the exception and page state to the
   //Windows Event Log
   EventLog.WriteEntry("myWebApplication name",
     "MESSAGE: " + ex.Message + 
     "\nSOURCE: " + ex.Source +
     "\nFORM: " + Request.Form.ToString() + 
     "\nQUERYSTRING: " + Request.QueryString.ToString() +
     "\nTARGETSITE: " + ex.TargetSite +
     "\nSTACKTRACE: " + ex.StackTrace, 
     EventLogEntryType.Error);

   Utilities.Mail.SendError(ex);
}
</script>

con il codice sopra si aggiunge l'errore al registro eventi, aggiungo l'errore al file XML nella funzione SendError (Exception).

Prestare molta attenzione quando si registrano informazioni potenzialmente riservate che sono arrivate su https. L'utente si aspetterà che sia crittografato end-to-end (che potrebbe essere un requisito legale). Assicurati di non inviarlo via e-mail normale.

Normalmente direi di registrare tutta la richiesta, inclusi get, post, cookies, state form (in ASPNET), user agent, altre intestazioni, data / ora, macchina server ecc

MA in alcuni casi ciò comporterebbe la registrazione di alcune informazioni che non dovresti registrare in modo permanente (come i numeri di carta di credito che vengono trasmessi a un fornitore di pagamenti). L'invio tramite e-mail è ancora peggio.

Vale la pena verificare se HTTPS è attivo e, in tal caso, ridurre la quantità di informazioni registrate per evitare questo problema. Ho appena inviato una stringa per dire se il campo era vuoto o non vuoto.

In realtà sembra che tu abbia pensato abbastanza bene alla soluzione.

Lavoro nel negozio di sviluppo web, quindi oltre agli errori di registrazione, mi assicuro anche che eventuali errori critici di sistema come il fallimento di query db e simili vengano inviati via email in modo da poterli saltare e risolverli immediatamente.

Un'alternativa da considerare sarebbe quella di inviare via e-mail un rapporto ogni giorno che fornisca informazioni su ogni errore generato in ciascuna applicazione e qualsiasi informazione pertinente che vorresti ricevere nell'e-mail.

Registriamo tutti i nostri errori in una singola tabella per quell'applicazione (ovviamente è più facile fare quando lavori su applicazioni in cui i database sono tutti contenuti internamente) incluso il timestamp dell'errore e il testo completo del messaggio di eccezione che è stato anche inviato tramite e-mail.

Il messaggio di eccezione contiene una traccia della funzione in modo da sapere quale fosse la funzione di chiamata originale, nonché i numeri di file e di riga per tutte le funzioni nello stack. Ciò semplifica il back-tracking di ogni dato bug.

Quando la registrazione nel database non riesce, è possibile scrivere nel registro eventi del server o in un file Log.txt. La tua scelta qui dipende in parte dal fatto che tu abbia accesso ai server web che li contengono.

L'invio di e-mail di notifica di errore è una buona idea se hai bisogno di una risposta rapida. Ma non esiste un elenco degli errori da esaminare attraverso di essi.

Lo faccio creando una speciale classe di eccezione personalizzata con proprietà che includono informazioni utente (ID, nome se disponibile), tutte le variabili di sessione, tutte le variabili del modulo (in modo da poter vedere come il modulo è stato popolato e quali immissione utente) e qualche indicazione oltre la traccia dello stack di dove si è verificato l'errore (quale pagina, quale classe, quale metodo). Includere anche il nome della procedura memorizzata chiamata e l'invio dei parametri o lo stesso SQL. Inoltre tutte le proprietà dell'eccezione (traccia stack, ecc.). E campi DisplayMessage e InternalMessage. DisplayMessage viene visualizzato per l'utente. InternalMessage viene registrato nel registro e visualizzato nella pagina di errore personalizzata in modalità debug.

Eseguo il log in Page_Error nella pagina di base e come fail-safe in Application_Error.

A volte aggiungo una coppia chiave-valore in web.config per contenere il mio indirizzo e-mail (o una lista di distribuzione). Se c'è un valore in quella chiave, viene inviata un'email di notifica. Se non c'è alcun valore, non viene inviato e-mail. Quindi, durante i test o la produzione iniziale, posso ottenere una notifica personale immediata del problema. Trascorso il periodo iniziale, rimuovo l'indirizzo e-mail in web.config.

la registrazione è buona, ma monitoraggio delle applicazioni è migliore.

avvertenza: sono l'autore di CALM

Siamo rimasti frustrati dalle applicazioni di segnalazione errori del sito Web disponibili, quindi abbiamo scritto le nostre su Clearwind Consulting. È gratuito e lo usiamo internamente per i nostri progetti. Fornisce informazioni complete sull'errore come codici di errore completi, tipo di browser, traceback, uno snippet del codice che ha causato l'errore, frequenza dell'errore rappresentata graficamente per oltre 30 giorni. A Clearwind, facciamo lo sviluppo di applicazioni web. Avevamo bisogno di uno strumento che ci fornisse dati reali che potremmo utilizzare in modo efficiente sui nostri siti Web.

Puoi scegliere come ricevere una notifica di errore nel tuo sito web. RSS, e-mail o qualsiasi metodo che funzioni meglio per te può essere utilizzato per ricevere notifiche di errore. E sì, puoi inviare gli errori al tuo iPhone mentre bevi. È interamente scritto in Django, quindi puoi usare JSON, RoR, XML, CSV, ecc. Se desideri taggare o formattare i tuoi dati. O semplicemente vieni al sito Web.

Se ti piace, visita www.areciboapp.com.

È gratuito, facilmente aggiungibile (o rimosso da) qualsiasi sito Web e fornisce informazioni reali per consentirti di correggere gli errori, piuttosto che solo un 404. Nessuna vendita difficile qui. Basta un invito per venire a dare un'occhiata e vedere se potrebbe aiutare te e il tuo sito web. Pensiamo che potrebbe.

È una buona idea accedere a un registro eventi personalizzato sul server e a qualsiasi altro logging & amp; notifica. Se l'errore è stato causato da un problema di infrastruttura, lo stesso problema potrebbe anche impedire al gestore errori di inviare e-mail o salvare su un database.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top