Quante informazioni per accedere dagli errori? [chiuso]

Question

Presso l'azienda per cui lavoro, ho creato una classe di registrazione degli errori per gestire gli errori nella mia applicazione ASP.net. È una classe personalizzata perché non ci è permesso installare software aggiuntivo sui nostri server (nLog, log4net, ecc.)

Attualmente lo uso in due dei miei progetti e ne ho riscontrato alcuni buoni risultati. In questo momento sto intrappolando gli errori che causano errori di pagina e dell'applicazione. Invia e memorizza il messaggio di errore e tutte le eccezioni interne.

Il problema che sto riscontrando ora è che sto ricevendo errori che non sono sicuro di come riprodurre. Non ho sentito segnalazioni di errori da nessuno dei miei utenti. Non sono sicuro di cosa stiano facendo o anche se li vedono come errori.

Sto pensando di creare un registro eventi su ogni pagina, o quelli su cui voglio ulteriori informazioni. Mantenerlo come variabile di sessione nella pagina e scrivere eventi (inizio / fine delle funzioni, modifiche alle variabili, ecc.). Quindi solo se viene chiamato un errore per avere quell'invio insieme al messaggio di errore per vedere se fornisce un quadro migliore di ciò che sta accadendo. Spero che farlo in questo modo non mi darà tonnellate di registri eventi quando tutti gli utenti accedono all'applicazione, voglio solo succedere prima che si verifichi l'errore con un solo utente.

Sei a conoscenza di eventuali insidie ??da tenere d'occhio con il metodo?

Hai qualche consiglio su cosa cercare?

Aggiornamento:

@Saret: capisco da dove vieni con quella risposta e sono d'accordo. Sono abbastanza nuovo per questa compagnia e devo ancora imparare come fanno le cose. In passato ho avuto conversazioni con i miei colleghi su come sarebbe bello avere questo prodotto o usare questo progetto open source. Il problema si riduce a, lavoriamo su sistemi sicuri e ottenere l'approvazione per ottenere queste cose richiede molto tempo, copertura superiore e gestione di tutta la burocrazia. Esaminerò ulteriormente la situazione perché ritengo che disporre di un buon sistema di registrazione degli errori sia importante, al momento non viene utilizzato nulla.

@Jim Blizard: volevo cercare di evitare di registrare / archiviare tutto da qualche parte per tornare indietro e scoprire cosa è importante per la situazione che ha causato l'errore. Non volevo cadere in un sovraccarico di informazioni di cui si parlava in maniera artistica che Roberto Barros collegava. Il mio attuale metodo di pensiero è, mantenendo una stringa in memoria su ogni pagina e, se si verifica un errore, sull'evento Page_Error delle pagine, afferrare quella stringa e collegarla all'eccezione che viene registrata. In questo modo sto registrando solo l'errore / le eccezioni che si sono verificate e memorizzando il registro eventi con quell'errore. Se non accade nulla, quel registro che è stato creato viene lasciato cadere nel bit bucket per non essere più visto.

@Roberto Barros: grazie per quel link, ricordo di averlo letto da qualche parte ma ho dimenticato di salvarlo.

Answer 1

Questa potrebbe non essere la risposta esatta che stai cercando, ma perché sviluppare il tuo meccanismo di registrazione degli errori quando ci sono strumenti potenti (di cui parli) che gestiscono tutti questi problemi chiave per te?

Posso apprezzare che non ti è permesso installare software aggiuntivo, ma le librerie di registrazione non sono solo classi come il tuo codice personalizzato? Dov'è la differenza fondamentale? Direi che il tempo speso a preoccuparsi per l'implementazione di un framework di registrazione potrebbe essere speso meglio sostenendo e facendo un caso aziendale per una soluzione di registrazione decente.

Answer 2

Una volta ho lavorato per un'agenzia che non avrebbe consentito l'installazione di nulla che non fosse semplicemente il mio codice o i loro (orribili) oggetti COM. Se si dispone di questo tipo di limitazione, vedere se è possibile acquisire l'origine per log4net e includerla nel progetto.

Non c'è niente di meglio di log4net al momento quando si tratta di registrazione.

Answer 3

Ho adottato personalmente il seguente approccio sulla registrazione degli errori (e solo degli errori di registro) in un'applicazione asp.net:

• uso protetto void Application_Error (mittente oggetto, EventArgs e) {     Server.Transfer (" ~ / Support / ServerErrorSupport.aspx " ;, true); } (Faccio un Server.Transfer per conservare tutti i dati dei post.)

• Genera un ID errore univoco per questo errore (in questo modo è possibile raggruppare le repliche successive per lo stesso errore). L'ID è un hash calcolato da una stringa concatenata composta da: file, method, lineNr ed error.Message. Ottengo i valori di file, metodo e lineNr tramite una regex sullo stacktrace.

• Registro tutti i seguenti dati in una struttura xml (a seconda del tipo di dati, memorizzo il valore in modo diverso, value types = > ToString (), ISerializable = > serialize, ...):

  1. MachineName: Application.Server.MachineName
  2. PhysicalRoot: Application.Server.MapPath (" ~ / ")
  3. RequestUrl: Application.Request.Url.ToString ()
  4. ApplicationSettings: WebConfigurationManager.AppSettings
  5. ConnectionSettings: WebConfigurationManager.ConnectionStrings
  6. QueryString: Application.Request.QueryString
  7. FormPost: Application.Request.Form
  8. Sessione: Application.Session
  9. HttpHeaders: Application.Request.Headers

• Salva la struttura xml come file locale contenente l'ID errore e un timestamp. Ho scelto questo approccio perché:

  • Posso inviare il rapporto (file xml) a me stesso (durante il test / debugging molto facile)
  • memorizzalo localmente o in un database durante la produzione
  • poiché il file è solo un salvataggio (dump in hd), non molto può andare storto durante la creazione del rapporto di errore (come una connessione al server, problemi di db, ecc.), assicurati di avere i permessi di scrittura.
  • Inoltre sulla pagina servererrorsupport.aspx, dopo aver salvato il file xml, l'utente ha la possibilità di includere informazioni aggiuntive e di aggiungere un indirizzo e-mail per essere aggiornato sull'avanzamento del bug. Questo viene aggiunto al documento XML.
  • Uso un file xslt per formattare i dati di errore (xml) in una bella segnalazione di errori.

Answer 4

Per errori, sono un grande fan della registrazione MOLTO. Quando le cose vanno male le informazioni sono molto preziose. Terrei l'intero registro in un unico posto (file di testo o tabella del database) con un identificatore di sessione per raggruppare eventi rilevanti.

Answer 5

Ecco cosa mi piace registrare:

• livello di errore / debug (informazioni, debug, problemi, crash, ecc ...)
• tempo
• testo descrittivo (di solito una riga)
• stack stack (se possibile)
• dati (utente, sessione, valori variabili, ecc ...)

Il modo più semplice è scrivere su un file di testo, ma può essere bello averlo in un database. È inoltre possibile utilizzare il registro eventi di Windows. Alcune cose a cui fare attenzione. Hmm ... Dovrai cancellare periodicamente i tuoi registri.

Storia divertente: una volta abbiamo avuto un logger di errori che ha effettuato l'accesso al database, ma avevamo credenziali del database errate che hanno causato un errore che è stato quindi registrato ... Finito per ottenere overflow dello stack dalla ricorsione (IIRC).