Ich schaue auf eine neue asp.net-Site 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.
Eine Option ist ELMAH. Ich habe eine Frage dazu hier gestellt: ASP.NET Fehlerbehandlung .
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.
Wir verwenden zwei Optionen für unsere Protokollierung: -
ELMAH für die Behandlung unerwarteter Ausnahmen
NLog für erwartete, manuelle (Debug, Info und Fehler) 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 zu visualisieren Fehler. Es ist also eine sehr schnelle und effektive Möglichkeit, unerwartete Fehler zu erfassen.
Nun NLog Komplimente , indem unsere Entwickler manuell Debug-Informationen in den Code an bestimmten Stellen einfügen, also wenn wir Informationen aus einem nicht-lokalen System herausholen müssen , es ist sehr leicht. Zum Beispiel haben wir in den meisten unserer Methoden log.Debug(..) -Code geschrieben, um zu sehen, was die lokalen Variablen sind oder Werte zurückgeben. Für wichtigere Informationen verwenden wir dann log.Info(..) .., aber verwenden Sie viel weniger. Schließlich verwenden wir log.Error(..) oder log.Warn(..) .. für einige schwerwiegende Fehler, die wir eingefangen haben und handhaben, in einigen try/catch Bereichen. 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 abrufen müssen und größer. Wir haben immer Warn, Error and Fatal states immer eingeschaltet. Der Debug-Status erzeugt eine Menge Daten, also verwenden wir das nur sehr sparsam.
Kurz gesagt, schlage ich vor, dass Sie TWO-Ansätze für Ihre WebApp verwenden. Elmah für ausgezeichnete unerwartete Fehlermeldung und NLog für erwartete Informationen und Fehler.
Schließlich ist NLog WAAAY einfacher zu benutzen / zu arbeiten als Log4Net. Es überlagert es im Grunde, IMO.
ASP.NET Health Monitoring leistet tatsächlich einen ziemlich guten Job direkt aus der Box!
MSDN, Vorgehensweise: Senden von E-Mails für Benachrichtigungen zur Zustandsüberwachung
Enterprise Library hat vielleicht eine Lernkurve, ist aber ein gutes Projekt.
In Asp.Net folgen Sie dem Artikel von David Hayden Enterprise Library 2.0 Logging Application Block
Ich persönlich habe log4net nicht probiert, aber die Spezifikationen und Beispiele für winforms gesehen, aber meine Organisation hat unseren eigenen Logging-Mechanismus programmiert, der Fehler in der Datei global.asax meldet und protokolliert, die alles über den Stack-Trace wissen , 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.
Tags und Links asp.net logging log4net health-monitoring