Frage

Ich arbeite derzeit an einem Unternehmen, das eine Menge von benutzerdefinierten Anwendungen hat, die intern getroffen werden. Es gibt derzeit nicht Standards für viele Dinge. Ich möchte eine Art und Weise implementieren aufzuzeichnen / Track Fehler, die in diesen Programmen geschehen (die meisten sind asp.net).

ich derzeit denke, dass diese in der Application Error-Methode in der Global.asax der Handhabung. Zuerst versuchen, die Informationen zu einer Fehlerprotokoll / Tracking-Datenbank zu speichern, und wenn das fehlschlägt, versuchen Sie eine E-Mail zu senden.

Welche Art von Informationen ist das nützlichste von der Fehlermeldung und anderen Anwendungsvariablen (Seite, Benutzername usw.) zu erhalten.

Ich bin derzeit Denken zwei Tabellen zu verwenden, eine den allgemeinen Fehler und Anwendungsinformationen zu erhalten, und eine zweite, die die Ausnahmeinformationen hält. Dies wird ein Eins-zu-Beziehung sein, die inneren Ausnahmen von der Hand, die von einer Anwendungsebene Ausnahme kommen kann.

Ich bin sicher, dass ich eine Menge von Details am fehlt und mag, dass Ihre Strategie für den Umgang mit dieser Frage hören.

War es hilfreich?

Lösung

Jeff Atwood schrieb eine große Exception Handler, die Sie bei auf aussehen sollte Codeproject

Ich würde versuchen, so viele Informationen wie möglich zu sammeln. Stapel Informationen Sitzungsinformationen Lage von Fehlern

Ich würde auch Setup ein Webservice, dass die Anwendungen rufen Sie die Ausnahmeinformationen in Ihr System sparen.

Andere Tipps

Ich denke, ELMAH kann sein, was Sie suchen.

Wenn Sie eine Logging-Bibliothek verwenden (wie Log4Net) Sie können verschiedene Protokollierungsappen einrichten anmelden, um eine E-Mail, DB, Datei, Ereignisprotokoll, etc., während ein einzelnes Protokoll Anruf in Ihrem Code haben. Diese Post umfasst alles, was Sie brauchen, um gestartet.

Es gibt auch ASP.NET Gesundheitsüberwachung .

EDIT:. Ein weiteres Plakat erwähnt ELMAH, die für die Aufzeichnung von ASP.NET-Fehler groß ist, und kann dynamisch sein ‚injiziert‘ in laufenden Anwendungen

Das ist, was ich tue, und ich habe noch einen Fehler wegen eines E-Mail-Problems.

Ich habe nie etwas auf der DB halten, führen, wenn die DB einen Fehler hat, die ich nie auf der DB Ursache diese Fehler hat, logisch, wird der Einsatz nicht!

Also habe ich eine spezielle E-Mail-Adresse eine E-Mail wie bugs@mydomain.com

Betreff : [Application name] [Time Stamp: ddmmyyyy hhmmss] Nachricht :. Anwendung, Fehlermeldung, Stack-Trace Information plus Sitzungsvariablen wie Benutzernamen und Server-Variablen wie Referrer-

der beste Freund eines ASP.NET Entwickler Stack-Trace Informationen , es ist hier, dass Sie wissen, was schief gelaufen ist, was der Anruf war und wo es rief.

das einzige Problem, , dass Sie in diesem System haben, ist, dass man nicht alles bekommen, wenn die E-Mail ein Problem (eine Ausnahme, wenn die E-Mail sendet) hat, und dass ich begann zu einem hinzufügen monatliche XML-Datei [errorLog_ mmm_yyyy.xml] als auch und machte eine einfache „Drag-and-drop“ Seite mit einem Gridview, die die XML für den Monat und das Jahr geladen, die ich wollte, dass die Fehler überprüfen.

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

oder die beste Art und Weise: Fügen Sie es zu der 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>

mit dem obigen Code Ihnen den Fehler in das Ereignisprotokoll hinzufügen, hänge ich den Fehler auf die XML-Datei im SendError (Exception) Funktion.

Seien Sie sehr vorsichtig, wenn potenziell vertrauliche Informationen Anmeldung, die über https angekommen ist. Der Benutzer wird erwartet, dass es verschlüsselt zu-Ende-Ende-sein (die gesetzlich vorgeschrieben sein kann). Stellen Sie sicher, Sie nicht senden Sie es per E-Mail Ebene.

Normalerweise würde ich alle die Anforderung get sagen einzuloggen, Post, Cookies, Formularzustand (in ASPNET), User-Agent, andere Header, Datum / Uhrzeit, Server-Maschine etc

Aber unter einigen Fällen, die in einigen Informationen führen würden protokolliert, die Sie nicht permanent sollen aufzuzeichnen (wie Kreditkartennummern bis hin zu einem Zahlungsanbieter übergeben werden). Senden sie per E-Mail ist noch schlimmer.

Es lohnt sich, einen Scheck zu tun, wenn HTTPS aktiviert ist, und wenn ja, reduzieren die Menge an Informationen, die Sie dieses Problem log zu vermeiden. Ich habe gerade durch einen String geschickt zu sagen, ob das Feld leer oder nicht leer ist.

Es klingt tatsächlich wie Sie die Lösung ziemlich gut durchdacht haben.

Ich arbeite in Web-Entwicklung-Shop, so dass zusätzlich zu Protokollieren von Fehlern, ich auch sicherstellen, dass alle systemkritische Fehler wie Fehler db Abfrage und dergleichen sind auch so per E-Mail, dass wir sie auf sie und reparieren sofort springen.

Eine Alternative zu betrachten wäre, einen Bericht an E-Mail jeden Tag, die in jeder Anwendung und alle relevanten Informationen geworfen Informationen zu jedem Fehler bereitstellt, die Sie in der E-Mail wünschen würden.

Wir protokollieren alle unsere Fehler in eine einzige Tabelle für diese Anwendung (natürlich, die einfacher zu tun, wenn Ihre Arbeits auf Anwendungen, bei denen die Datenbanken all in-house enthalten sind) mit dem Zeitstempel des Fehlers und dem vollständigen Wortlaut der Ausnahmemeldung, die auch per E-Mail ist.

Die Ausnahmemeldung enthält eine Funktion Spur, so dass Sie wissen, was die ursprüngliche Berufung Funktion sowie Datei- und Zeilennummern für alle Funktionen in dem Stapel war. Dies macht Back-Tracking beliebige Fehler super einfach.

Bei der Anmeldung an die Datenbank ausfällt, können Sie auf den Server des Ereignisprotokoll oder in eine Log.txt-Datei schreiben. Sie Wahl hier zum Teil davon ab, ob Sie Zugriff auf die Web-Servern diejenigen enthalten.

Senden von Fehlerbenachrichtigung E-Mail ist eine gute Idee, wenn Sie eine schnelle Antwort benötigen. Aber es gibt keine Liste der Fehler durch sie zu scannen.

Ich tue dies durch eine spezielle benutzerdefinierte Ausnahmeklasse mit Eigenschaften, einschließlich der Benutzerinformationen (ID, Name, falls vorhanden) zu schaffen, die alle Session-Variablen, alle Formularvariablen (so können Sie sehen, wie die Form wurde bevölkert und was die Benutzer eingegeben), und einige Anzeichen über die Stapelüberwachung, wo der Fehler aufgetreten ist (die Seite, die Klasse, die Methode). Auch enthält die Namen der gespeicherten Prozedur aufgerufen und die Parameter senden, oder die SQL selbst. Auch alle der Ausnahme Eigenschaften (Stack-Trace, etc). Und Displaymessage und InternalMessage Felder aus. Die Displaymessage wird dem Benutzer angezeigt. Die InternalMessage wird im Protokoll aufgezeichnet und auf der benutzerdefinierten Fehlerseite angezeigt, wenn im Debug-Modus.

ich tun, um die Protokollierung in Page_Error auf der Basisseite, und als ausfallsicher in Application_Error.

Manchmal füge ich ein Schlüssel-Wert-Paar in web.config auf meine E-Mail-Adresse (oder eine Verteilerliste) enthalten. Wenn es eine vaue in diesem Schlüssel ist, wird eine Benachrichtigung E-Mail gesendet. Wenn kein Wert ist, wird kein eomail gesendet. Dann während der Prüfung oder frühe Produktion, kann ich sofort persönliche Mitteilung des Problems erhalten. Nach den anfänglichen Zeitraum Pässen, entferne ich die E-Mail-Adresse in web.config.

Protokollierung ist gut, aber Anwendungsüberwachung ist besser.

Einschränkung: Ich bin der Autor von CALM

Wir waren mit der Website-Fehlerberichterstattung Anwendungen frustriert, die da draußen waren, so dass wir unsere eigene bei Clearwind Beratung schrieb. Es ist kostenlos und wir nutzen es intern für unsere Projekte. Es gibt komplette Fehlerinformationen wie die vollständige Fehlercodes, Browsertyp, Traceback, einen Ausschnitt aus dem Code, der die Fehler, Fehlerhäufigkeit über 30 Tage und mehr grafisch dargestellt verursacht. Bei Clearwind, haben wir die Entwicklung von Webanwendungen. Wir brauchten ein Werkzeug, das uns reale Daten geben würden wir effizient über unsere Websites verwenden können.

Sie können wählen, wie Benachrichtigung zu erhalten, wenn Ihre Website einen Fehler gibt. RSS, E-Mail, oder was auch immer Methode funktioniert am besten für Sie alle verwendet werden kann, um Fehlermeldungen zu bekommen. Und ja, können Sie die Fehler zu Ihrem iPhone senden, während Sie einen Drink haben. Es ist vollständig in Django geschrieben, so dass Sie JSON verwenden können, RoR, XML, CSV, etc., wenn Sie zu markieren, oder formatieren Sie Ihre Daten wünschen. Oder einfach nur kommen auf die Website.

Wenn Sie möchten, schauen Sie sich www.areciboapp.com.

Es ist kostenlos, leicht hinzugefügt (oder entfernt von) jede Website und gibt echte Informationen, damit Sie die Fehler beheben, anstatt nur ein 404. Nein hier schwer zu verkaufen. ein gerade einladen, einen Blick zu kommen und sehen, ob es Ihnen und Ihre Website helfen könnte. Wir denken, es könnte.

Es ist eine ziemlich gute Idee, um ein benutzerdefiniertes Ereignisprotokoll auf dem Server sowie jede andere Protokollierung und Benachrichtigung zu protokollieren. Wenn der Fehler von einem Infrastrukturproblem verursacht wurde, könnte das gleiche Problem auch die Fehlerbehandlung hält von E-Mails zu senden oder zu einer Datenbank zu speichern.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top