Ich beende eine Webanwendung und versuche, etwas Logging zu implementieren. Ich habe noch nie ein gutes Beispiel dafür gesehen, was zu loggen ist. Sind es nur Ausnahmen? Gibt es noch andere Dinge, die ich protokollieren sollte? Welche Art von Informationen finden Sie nützlich, um Fehler zu finden und zu beheben?
Auf der Suche nach konkreten Anleitungen und Best Practices.
Danke
Nachverfolgung
Wenn ich Ausnahmen protokolliere, welche Informationen sollte ich speziell protokollieren? Sollte ich etwas mehr tun als _log.Error(ex.Message, ex); ?
Hier ist mein logischer Überblick darüber, was in der Anwendung und in der Anwendung protokolliert werden kann, warum Sie dies möchten und wie Sie das tun könnten. Egal, was ich empfehlen würde, ein Logging-Framework wie log4net bei der Implementierung zu verwenden.
Wenn alles andere fehlgeschlagen ist, sollte dies nicht geschehen. Es ist eine gute Idee, alle unhandelten Ausnahmen zentral zu erfassen. Dies sollte nicht viel schwieriger sein, als Ihre gesamte Anwendung in einen riesigen Versuch / Fang zu wickeln, es sei denn, Sie verwenden mehr als auf Thread. Die Arbeit endet hier nicht Obwohl, wenn Sie warten, bis die Ausnahme Sie erreicht, eine Menge nützlicher Informationen wäre außerhalb des Geltungsbereichs gegangen. Zumindest sollten Sie Versuchen Sie, bestimmte Teile des Anwendungsstatus zu sammeln, die beim Debuggen beim Abwickeln des Stapels helfen können. Ihre Anwendung sollte immer darauf vorbereitet sein, diese Art der Protokollausgabe speziell in der Produktion zu erstellen. Sehen Sie sich ELMAH an, falls Sie dies nicht bereits getan haben. Ich habe es nicht ausprobiert, aber ich habe große Dinge gehört
Was ich Anwendungsprotokolle nenne, schließt jedes Protokoll ein, das Informationen darüber aufzeichnet, was Ihre Anwendung auf konzeptioneller Ebene macht, z. B. "Gelöschte Bestellung" oder "Ein Benutzer angemeldet". Diese Art von Informationen kann nützlich sein, um Trends zu analysieren, das System zu auditieren, es zu sperren, zu testen, zu schützen und Fehler zu entdecken. Es ist wahrscheinlich eine gute Idee zu planen, diese Protokolle auch in der Produktion zu belassen, vielleicht mit verschiedenen Granularitätsgraden.
Trace-Protokollierung stellt für mich die granularste Form der Protokollierung dar. Auf dieser Ebene konzentrieren Sie sich weniger auf das, was die Anwendung tut, sondern darauf, wie sie es ausführt. Dies ist ein Schritt darüber, den Code Zeile für Zeile durchzugehen. Es ist wahrscheinlich am nützlichsten im Umgang mit Gleichzeitigkeitsproblemen oder irgendetwas in dieser Angelegenheit, das schwer zu reproduzieren ist. Sie möchten das nicht immer laufen lassen, wahrscheinlich nur bei Bedarf.
Schließlich, wie bei so vielen anderen Dingen, die normalerweise erst am Ende behandelt werden, ist der beste Zeitpunkt, um über das Protokollieren nachzudenken, am Anfang eines Projekts, damit die Anwendung mit diesem Ziel entworfen werden kann. Große Frage aber!
Vielleicht sollten Sie Seiten- / Ressourcenzugriffe protokollieren, die in Ihrer Anwendung noch nicht definiert sind, aber von Clients angefordert werden. Auf diese Weise können Sie möglicherweise Schwachstellen finden.
Einige Dinge zu loggen:
Einige Dinge, die NICHT zu protokollieren sind:
Das hängt von der Anwendung und der Zielgruppe ab. Wenn Sie Verkäufe verwalten oder Aktien handeln, sollten Sie wahrscheinlich mehr Informationen protokollieren als einen persönlichen Blog sagen. Wenn Sie das Protokoll am meisten benötigen, wenn in Ihrer Produktionsumgebung ein Fehler auftritt, können Sie es nicht lokal reproduzieren. In solchen Situationen würde es hilfreich sein, die Protokollebene und die Protokollhierarchie zu verwenden, da Sie die Protokollstufe dynamisch erhöhen können. Siehe die Dokumentation zu log4j und log4net .
Sie sollten in diesem Stadium wahrscheinlich nicht darüber nachdenken, vielmehr ist das Protokollieren in jeder Phase der Entwicklung hilfreich, um mögliche Bugs zu beseitigen, bevor sie entstehen. Abhängig von Ihrem Programm würde ich versuchen, so viele Informationen wie möglich zu erfassen. Alles protokollieren. Sie können immer aufhören, bestimmte Komponenten oder Prozesse zu protokollieren, wenn Sie diese Daten nicht ausreichend referenzieren. Zu viel Information gibt es nicht.
Wenn Sie aus meiner (begrenzten) Erfahrung nicht für jeden möglichen Fehlertyp eine spezifische Fehlertabelle erstellen möchten, erstellen Sie eine generische Datenbanktabelle, die allgemeine Informationen sowie eine Zeichenfolge akzeptiert, die Sie mit Ausnahmedaten füllen können. Bestätigungsnachrichten während erfolgreicher, aber wichtiger Prozesse usw. Ich habe eine generische Funktion mit Parametern dafür verwendet.
Sie sollten auch die Möglichkeit in Betracht ziehen, die Protokollierung bei Bedarf auszuschalten.
Hoffe, das hilft.
Meine paar Cent. Prüfen Sie nicht nur den Protokollschweregrad und die Ausnahmebedingungen, sondern überlegen Sie auch, wie Sie Ihre Protokollanweisungen so strukturieren, dass Sie die Protokolldaten in Zukunft problemlos einsehen können. Zum Beispiel - das Extrahieren von aussagekräftigen Informationen, das Ausführen von Abfragen usw. Es ist kein Problem, einen Ozean von Protokolldaten zu generieren, das Problem besteht darin, diese Daten in Informationen umzuwandeln. Strukturierung und Definition im Vorfeld hilft also bei der späteren Nutzung. Wenn Sie log4j verwenden, würde ich auch vorschlagen, den zugeordneten Diagnosekontext (MDC) zu verwenden - dies hilft beim Verfolgen von Sitzungskontexten. Neben Trace und Info würde ich auch Debug-Level verwenden, wo ich normalerweise temp halte. Artikel. Diese können ausgefiltert oder deaktiviert werden, wenn sie nicht benötigt werden.
Ich glaube, wenn Sie eine Ausnahme protokollieren, sollten Sie auch das aktuelle Datum und die Uhrzeit, die angeforderte URL, den URL-Verweis und die Benutzer-IP-Adresse speichern.
Tags und Links asp.net-mvc logging instrumentation