Wie kann die Fehlerprotokollierung für Ausnahmen am besten verwaltet werden?

Einführung

Wenn ein Fehler auf einer Website oder einem System auftritt, ist es natürlich hilfreich, ihn zu protokollieren und dem Benutzer eine höfliche Nachricht mit einem Referenzcode für den Fehler anzuzeigen.

Und wenn Sie viele Systeme haben, möchten Sie diese Informationen nicht verteilen - es ist gut, einen einzigen zentralen Ort dafür zu haben.

Auf der einfachsten Ebene sind lediglich eine inkrementierende ID und ein serialisierter Speicherauszug der Fehlerdetails erforderlich. (Und möglicherweise ist der "zentralisierte Ort" ein E-Mail-Posteingang.)

Am anderen Ende des Spektrums befindet sich möglicherweise eine vollständig normalisierte Datenbank, mit der Sie auch auf Knopfdruck eine Fehlergrafik pro Tag anzeigen oder feststellen können, welche Art von Fehler auf System X am häufigsten auftritt, ob Server A über mehr Datenbanken verfügt Verbindungsfehler als Server B und so weiter.

Ich beziehe mich hier auf das Protokollieren von Fehlern / Ausnahmen auf Codeebene durch ein fernes System - nicht auf "menschlicher" Basis, wie dies mit Jira, Trac usw. Der Fall ist.

Fragen

Ich suche Gedanken von Entwicklern, die diese Art von System verwendet haben, insbesondere in Bezug auf:

• Was sind wesentliche Funktionen, auf die Sie nicht verzichten könnten?
• Was ist gut daran, Features zu haben, die Ihnen wirklich Zeit sparen?
• Welche Funktionen scheinen eine gute Idee zu sein, sind aber eigentlich nicht so nützlich?

Zum Beispiel würde ich sagen, dass eine "Show Duplicates" -Funktion, die das mehrfache Auftreten eines Fehlers identifiziert (ohne sich um "unwichtige" Details zu kümmern, die sich unterscheiden könnten), ziemlich wichtig ist.
Eine Schaltfläche zum "Erstellen eines Problems in [Jira / etc] für diesen Fehler" klingt nach einer guten Zeitersparnis.

Um es noch einmal zu wiederholen, ich bin auf der Suche nach praktischen Erfahrungen von Leuten, die solche Systeme verwendet haben, vorzugsweise mit der Begründung, warum eine Funktion fantastisch / schrecklich ist.
(Wenn Sie trotzdem theoretisieren wollen, markieren Sie zumindest Ihre Antwort als solche.)

Ich war in einem Projekt mit protokollierten Clientfehlern bei Verwendung der Microsoft Enterprise-Bibliothek . Alle Ausnahmen werden an unsere Mailbox geschickt. Im Betreff der E-Mail haben wir einen Hash-Code für den serialisierten Fehler hinzugefügt, um doppelte Nachrichten zu vermeiden. Man könnte natürlich serialisierte Nachrichten in der Datenbank speichern und so weiter.

Ich empfehle Ihnen, sich die Microsoft Enterprise-Bibliothek und Log4Net anzusehen .

Einige Funktionen von Log4Net

• Unterstützung für mehrere Frameworks
• Ausgabe an mehrere Protokollierungsziele
• Hierarchische Protokollierungsarchitektur
• XML-Konfiguration
• Dynamische Konfiguration
• Protokollierungskontext
• Bewährte Architektur
• Modulares und erweiterbares Design • Hohe Leistung mit Flexibilität

Bei Datenbankanwendungen eine Art von ID (wie <TABLE>:<PrimaryKeyID>), mit der Sie die Datensätze in der Datenbank verfolgen können, die sich auf den Bereich beziehen, in dem die Ausnahme abgefangen wurde.

Ich habe es mit Oracle und PL / SQL gemacht und die ID in einer Datenbanktabelle innerhalb der Anwendung vom Ausnahmehandler aufgezeichnet.

Vieles von dem, was Sie beschreiben (dh die protokollierungsspezifischen Teile), ist in der Unternehmensbibliothek implementiert, wie Amir Rezaei bemerkt hat. Alles andere scheint eher der Analyseteil zu sein (dh was mit den Protokollen danach zu tun ist).

In meinem Fall habe ich einige kleine Apps und SQL-Skripte erstellt, die einige Dinge einfacher machten. Hier sind einige der Dinge, die mir wirklich gefallen haben:

• Die Gruppierung der gleichen Fehler (dh 100 Benutzer, bei denen ungefähr zur gleichen Zeit der gleiche Fehler aufgetreten ist, besteht aus einem Fehlerbericht mit der Angabe, wie viele Fehler aufgetreten sind).
• Ticket automatisch im Case Tracker ablegen (habe es nie geschafft, es auf Knopfdruck zu machen, wollte es aber immer)
• Benutzername des Benutzers der Software (nicht nur der Computer, der bei den meisten Loggern verfügbar ist). In einigen Fällen verursachten die automatisierten Benutzerkonten Probleme, während in anderen Fällen bestimmte Benutzer die Ursache für Probleme waren. "Ich muss Mike bei der Arbeit zusehen, er verursacht immer wieder einen bestimmten Fehler."
• "User Actions" (Benutzeraktionen) - Ich hatte einen globalen Stapel, in dem jeder verfolgbare Klick / Tastendruck nachverfolgt werden konnte, der vom Benutzer ausgeführt und in Fehlerprotokollen festgehalten wurde. Das Reproduzieren des Fehlers war oft ein Fall, in dem diese Ablaufverfolgung durchlaufen und dieselben Schritte wie der Benutzer ausgeführt wurden (ich hatte gehofft, einen CodedUI-Testgenerator zu erstellen, der die Ablaufverfolgung analysiert und die Schritte automatisch ausführt, dies jedoch nie tat).

Manchmal sind die Protokollinformationen einfach zu umfangreich, um auf der Festplatte gespeichert zu werden. Ein Ansatz, den ich gesehen habe, besteht darin, Ihre Protokolleinträge in eine Firehose (etwa in Perl) zu schreiben:

# Create socket.
my $sock = IO::Socket::INET->new(
    Proto       => 'udp',
    PeerAddr    => $bcastaddr,
    Broadcast   => 1,
) or die "Can't create socket ($bcastaddr): $!";

while (<>) {
    chomp;
    unless (/File\ does\ not\ exist:/) {
        $sock->send("$eventtype:$_") or warn "Can't send: $!";
    }
}

dann kann ein Analytiker herausfinden, was er / sie anschauen möchte.

Folgendes habe ich aus der Fehlerüberwachung in unseren Anwendungen gelernt:

• In der Lage sein, eine fortlaufende Protokolldatei abzuschließen (im Allgemeinen verwende ich log4net / log4j zum Anmelden von Anwendungen und zu verfolgen BareTail zum Verfolgen des Protokolls), ist sehr nützlich, um den aktuellen Zustand eines Systems überprüfen zu können
• Um zu sehen, wann Probleme aufgetreten sind und wie häufig sie auftreten, ist es hilfreich, sie in einer Datenbank mit Zeitstempeln zu haben, mit denen Sie Berichte erstellen können.
• Die Möglichkeit, E-Mail- / SMS- / Sprachbenachrichtigungen zu senden, ist sehr hilfreich, um sicherzustellen, dass das System auf dem neuesten Stand ist. Sie müssen jedoch die Möglichkeit haben, die Arten von Fehlern, die Sie benachrichtigen, einfach anzupassen. Wenn Sie täglich 800 Fehler-E-Mails erhalten, müssen Sie die Meldung "Oh nein, das Rechenzentrum brennt" verpassen.

Ich habe mit log4net großartige Ergebnisse erzielt, da es wirklich einfach ist, sich an mehreren Stellen anzumelden und auch Änderungen an der Protokollierungskonfiguration vorzunehmen.

elmah ist ein Open Source-Fehlerprotokollierungssystem für ASP.NET-Apps und kann zu einem vorhandenen System hinzugefügt werden (über NuGet http://nuget.codeplex.com/). schnell und einfach ) werden. Es unterstützt verschiedene Backends und Benachrichtigungsfunktionen.

Ich kenne niemanden, der es zu einer Desktop-App hinzugefügt hat, da es als Website ausgeführt wird, aber nichts hindert Sie daran, es als Dienst auszuführen und Ihre Ausnahmen im Web zu veröffentlichen.

http://code.google.com/p/elmah/

ELMAH (Error Logging Modules and Handlers) ist eine anwendungsweite Fehlerprotokollierungsfunktion, die vollständig steckbar ist. Es kann dynamisch zu einer laufenden ASP.NET-Webanwendung oder sogar zu allen ASP.NET- Webanwendungen auf einem Computer hinzugefügt werden, ohne dass eine erneute Kompilierung oder Bereitstellung erforderlich ist.

Sobald ELMAH in einer laufenden Webanwendung abgelegt und entsprechend konfiguriert wurde, erhalten Sie die folgenden Funktionen, ohne eine einzelne Codezeile zu ändern:

• Protokollierung fast aller nicht behandelten Ausnahmen.
• Eine Webseite zum Remote-Anzeigen des gesamten Protokolls der neu codierten Ausnahmen.
• Eine Webseite zum Remote-Anzeigen aller Details einer protokollierten Ausnahme, einschließlich farbiger Stapelspuren.
• In vielen Fällen können Sie den ursprünglichen gelben Todesbildschirm überprüfen, den ASP.NET für eine bestimmte Ausnahme generiert hat, auch wenn der customErrorsModus deaktiviert ist.
• Eine E-Mail-Benachrichtigung über jeden Fehler zum Zeitpunkt seines Auftretens.
• Ein RSS-Feed der letzten 15 Fehler aus dem Protokoll ...