2009-03-16 10 views
8

Ich bin auf eine neue asp.net-Website in 3.5, die absolut keine Fehlerbehandlung oder Protokollierung hat. Was sind einige gute Möglichkeiten für die Protokollierung und Behandlung von Fehlern? Ich habe Log4Net für das 1.1-Framework verwendet, höre aber, dass es in 3.5 potenziell bessere Optionen gibt.ASP.NET-Protokollierung - log4net oder Zustandsüberwachung?

Antwort

8

Eine Option ist ELMAH. Ich habe hier eine Frage dazu gestellt: ASP.NET Error Handling.

Seitdem habe ich eine leicht modifizierte Version davon implementiert und die Protokollierung plus E-Mail ist großartig und einfach über die Datei web.config zu integrieren.

+0

Wie sichere ich seine Log-Seite? – Caveatrob

+0

Das war Teil meiner "Modifikation". Ich wollte nicht, dass irgendwelche der aufgezeichneten Informationen offengelegt wurden, also habe ich es verwässert, um die Informationen nur in der Datenbank zu protokollieren und mir eine E-Mail zu senden. Wenn ich dann eine E-Mail bekomme, kann ich mir das Datenbankprotokoll ansehen. Ich habe sowieso keine Fernanzeige. – NYSystemsAnalyst

+2

Scott Hanselman hatte auch einen guten Beitrag zum Aufstehen und Laufen mit ELMAH: http://www.hanselman.com/blog/ELMAHErrorLoggingModulesAndHandlersForASPNETAndMVCToo.aspx –

4

Wenn Sie log4net verwendet werden, um, mit dem, was Sie wissen. Es ist einfach, schnell und funktioniert gut. Ich habe es seit Jahren in 1.1, 2.0 und jetzt 3.5 verwendet.

-2

persönlich habe, habe ich versucht log4net aber die Spezifikationen und Beispiele für WinForms gesehen, aber meine Organisation codiert eigenen Logging-Mechanismus, die Berichte und Fehler protokollieren, die in der global.asax gefangen sind, dass alles, was wir brauchen Berichte Informationen über Stack-Trace, Sitzung (falls vorhanden), NVC des Formulars, Version der App, URL, die den Fehler mit Querystring verursacht hat, und HTTP-Header. Obwohl ich bemerkt habe, dass nicht alle Fehler dort protokolliert werden; Dies ist beispielsweise der Ablauf der Formularauthentifizierung oder das Neustarten/Herunterfahren des Anwendungspools oder alles, was von IIS gemeldet wurde und nicht von der Anwendung ausgelöst wurde.

6

Wir verwenden zwei Möglichkeiten für unsere Protokollierung: -

ELMAH für unerwartete Ausnahme

NLog für erwartete, Handbuch (debug, info und Fehler) den Umgang mit Informationen.

ELMAH ist ein großartiges Out-of-the-Box-Plugin, das automatisch Ausnahmen (von 404 (Seite nicht gefunden) bis 500 Ausnahmefehler) erfasst und über ein integriertes Web-Interface verfügt, um diese Fehler zu visualisieren. Es ist also eine sehr schnelle und effektive Methode, um unerwartete Fehler zu erfassen.

Jetzt NLogKomplimente diese fügen unsere Entwickler manuell, indem an bestimmten Stellen Informationen in den Code debuggen, so dass, wenn wir Informationen aus einem nicht-locahost System bekommen müssen, ist es sehr einfach. Zum Beispiel wir log.Debug(..) Code in den meisten unserer Methoden zu sehen, was die lokalen Variablen sind oder Werte zurückgegeben, etc. Für wichtigere Informationen verwenden wir dann log.Info(..) .. aber verwenden Sie diese viel weniger. Schließlich verwenden wir log.Error(..) oder log.Warn(..) für schwerwiegende Fehler, die wir gefangen haben und handhaben, in der Regel innerhalb einiger try/catch Bereiche. Auf unseren Test- oder Live-Servern schalten wir dann alle Logging-Zustände ein (z. B. Debug und höher), wenn wir LOTS von Daten, live oder einfach die allgemeinen wichtigen Informationen, wie Info States und größer, ergreifen müssen. Wir haben immer Warn, Error and Fatal Zustände immer an. Der Debug-Status erzeugt eine Menge Daten, daher verwenden wir diese nur sparsam.

Also zusammenfassend, schlage ich vor, dass Sie zwei Ansätze zu Ihrer WebApp verwenden. Elmah für ausgezeichnete unerwartete Fehler Trapping und NLog für erwartet Informationen und Fehler.

Schließlich ist NLog WAAAY einfacher zu bedienen/zu arbeiten als Log4Net. Es übertrifft es im Grunde, IMO.