Wie man richtig Fehlerprotokollen umgehen?

https://stackoverflow.com/questions/618844

03-07-2019
|

Frage

habe ich versucht, vor der Veröffentlichung dieser Frage mehrere Suchen zu tun. Wenn dies ein Duplikat ist, lassen Sie es mich wissen, und ich werde es löschen.

Meine Frage dreht sich um die richtige Art und Weise Fehler zu behandeln produziert durch unsere Web-Anwendung. Wir protokollieren zur Zeit alles durch log4j. Wenn ein Fehler passiert, heißt es nur „ein Fehler aufgetreten ist. Die IT-Abteilung mitgeteilt wurde und funktioniert dies so schnell wie möglich zu korrigieren“ rechts auf dem Bildschirm. Dies teilt dem Benutzer nichts ... aber es hat auch die Entwickler etwas entweder nicht sagen, wenn wir versuchen, den Fehler zu reproduzieren. Wir haben in dem Fehlerprotokoll Ordner gehen und versuchen, diesen Fehler zu finden. Lassen Sie mich auch erwähnen, dass der Ordner von Protokollen aus der vergangenen Woche voll ist. Jedesmal, wenn es einen Fehler gibt, wird eine Protokolldatei für diesen Benutzer erstellt und E-Mail an die IT-Mitarbeiter auf Fehler arbeiten zugewiesen gesendet. Diese E-Mail nicht die Protokolldateinamen nennen, aber es ist eine Kopie des gleichen Fehlertextes geschrieben, die in der Protokolldatei ist.

Also, wenn Alicia ein Problem bei 7.15 mit etwas, aber es gibt 10 andere Fehler, die die gleiche Minute passieren, ich habe durch jede Protokolldatei gehen versuchen, sie zu finden.

Was ich vorschlage an meine Kolleginnen und Kollegen ist das Hinzufügen eines Fehlerprotokoll-Tabelle in der Datenbank. Dies würde für jeden Fehler einen Datensatz in die Tabelle schreiben, aufnehmen, wer es ist für die Fehler, welche Seite es passierte auf usw. Der Bonus dafür wäre, dass wir den Primärschlüsselwert aus der Tabelle (error_log_id) zurückkehren können, und zeigen, dass man auf der Seite mit einer Meldung wie „Error Referenz-ID (1337) angemeldet wurde und die richtigen IT-Mitarbeiter mitgeteilt wurden. bewahren Sie diese Referenz-ID praktisch für die zukünftige Verwendung“. Wenn wir die E-Mail bekommen, wäre es uns, die ID des Fehlers zum schnellen Nachschlagen sagen. Oder wenn der Benutzer persistent, sie können uns mit der ID und wir können die Fehler finden ziemlich schnell.

Wie Sie Ihre Setup-Fehlerprotokollierung? By the way, unser System verwendet Java-Servlets, die zu einer SQL Server-Datenbank zu verbinden.

Lösung

, antwortete ich eine ähnliche Frage hier , aber ich werde diese Antwort Anpassung an Ihre Frage.

Wir verwenden requestID für diese Zweck - zuweisen einer Anfrage-ID zu jedem eingehenden (HTTP) -Anfrage, gleich am Anfang der Verarbeitung (in-Filter) und dann, dass auf jeder Protokollzeile einzuloggen, so dass Sie später durch diese ID kann leicht diese Protokolle grep und alle relevanten Linien finden.

Wenn Sie denken, dass es sehr mühsam ist, dass die ID zu jedem Log-Anweisung hinzufügen möchten, dann sind Sie nicht allein - Java-Logging-Frameworks haben es transparent mit der Verwendung von Mapped Diagnostic Context (MDC) (zumindest log4j und diese logback haben).

RequestID kann auch als praktische Referenz-Nummer, arbeiten auszuspucken, im Falle von Fehlern (wie Sie bereits angedeutet). wie andere haben jedoch kommentiert, ist es nicht ratsam, diese Details in die Datenbank zu laden - eine bessere Nutzung des Dateisystems. Oder ist der einfachste Ansatz, nur die requestID zu verwenden - dann brauchen Sie nichts zu tun, speziell im Moment Fehler auftritt. Es ist einfach hilft Ihnen, die richtige Protokolldatei zu finden und innerhalb dieser Datei suchen.

Wie würde man RequestID aussehen?

Wir verwenden das folgende Muster:

.

besteht aus den folgenden Variablen:

instanceName eindeutig bestimmte JVM insbesondere Bereitstellungsumgebung identifiziert /.
currentTimeInMillis ist ziemlich selbsterklärend. Wir wählten es in für Menschen lesbaren Format „yyyyMMddHHmmssSSS“ darzustellen, so ist es leicht Anforderung Startzeit von ihm lesen (Achtung: Simple ist nicht Thread-sicher, so dass Sie entweder synchronisieren müssen oder einen neuen erstellen auf jede Anforderung ).
Zähler ist Anforderungszähler in diesen bestimmten Millisekunden - im seltenen Fall, dass Sie mehr als eine Anforderung ID in einer Millisekunde

Wie Sie sehen können, das ID-Format wurde so eingerichtet, dass currentTimeInMillis.counter Kombination garantiert insbesondere JVM und die gesamte ID eindeutig sein wird garantiert global eindeutig sein ( na ja, nicht im eigentlichen Sinne von „global“, aber es ist global genug für unsere Zwecke), ohne die Notwendigkeit, die Datenbank oder einen anderen zentralen Knoten. Auch die Verwendung von instanceName Variable gibt Ihnen die Möglichkeit, die Anzahl der Protokolldateien begrenzen Sie später in schauen müssen diese Anforderung finden.

Dann wird die letzte Frage: "? Das ist schön und gut in Single-JVM-Lösung, aber wie skalieren Sie, dass auf mehrere JVMs, einige Netzwerk-Protokoll-Kommunikation über"

Wie wir benutzen Frühling Remoting für unsere Remoting-Zwecke haben wir implementiert individuelle RemoteInvocationFactory (das dauert vom Kontext Anforderungs-ID und speichert sie a href <= "http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/remoting/support/ RemoteInvocation.html # addAttribute (java.lang.String,% 20java.io.Serializable) "rel = "nofollow noreferrer"> RemoteInvocation Attribute ) und RemoteInvocationExecutor (das dauert Anforderungs-ID von Attributen und fügt sie zu diagnostischen Kontext, in dem anderen JVM).

Nicht sicher, wie Sie es mit Klar RMI oder anderen Remote Methoden implementieren würden.

Andere Tipps

Wenn mehrere Server ausgeführt werden und jeder Server verlässt Nachrichten auf sich einzuloggen, ist es wirklich schwierig, sie zu verfolgen. Also, jemand oder ein Werkzeug, sollte sich in der Zeit, um sammeln und sortieren. Es ist ein guter Weg, um einen zentralen Punkt zu haben, wo alle Nachrichten gesendet werden.

Eine mögliche Lösung, haben Sie Ihre Fehlerseite umfasst eine ‚E-Mail an was auch immer‘ -Link. Wenn der Benutzer diese E-Mail klickt der Körper der E-Mail kann mit ein paar Leerzeilen, gefolgt von etwas anfangen wie:

---- Bitte ändern Sie nicht die Informationen unterhalb dieser Linie .---

Fehlerdetails

Alle Benutzer über diesen Link beschweren, werden Sie automatisch die Informationen, die Sie benötigen und ob Sie den Fehler reproduzieren haben Sie schnellen Zugriff auf die Fehlermeldung. Man könnte sogar ein Formular zum Senden der E-Mail, so dass der Benutzer sieht nie (was einige von Bedeutung sein kann), aber dann auf Ihrem System Sie verlassen sie zumindest die Lage, eine E-Mail senden.

Eigentlich finde ich es sinnvoll, die Fehlerdetails in einem HTML-Kommentar auf Fehlerseiten so zu drucken, so dass ich immer an sie selbst bekommen.

ich mit David darüber einverstanden Ich mag nicht diese Art von Informationen in einem DB gespeichert werden.

Für die Strategien der Anmeldung können Sie die Diskussion Logging Best Practices sehen .

Ich habe einen Ansatz wie die verwendeten Sie vorgeschlagen (in db log) in der Vergangenheit und es wurde sehr hilfreich.

Nicht nur Sie Katze den Fehler über SQL, aber Sie können auch Berichte von generieren, was die meisten wiederkehrenden Fehler und besuchen sie zuerst.

Auf dem Entwurf, den wir haben, ist gleich stacktraces den gleichen Datensätzen gehören (da sie im selben Ort entstanden genau wurden)

Wir hatten eine kleine Anwendung, die die db gesammelt und wir wussten, dann wurde eine neue Ausnahme erzeugt stattdessen eine E-Mail erhalten, die mit dem Rest wurden vollständig ignoriert der vorangegangenen Wochen summiert.

Natürlich ist diese Datenbank-Design für die Anwendung sehr spezifisch war wir hatten und zusätzliche Identifikationen möglich waren, hatten wir Software-Version, bauen, einige Male Eingabeparameter, etc. etc.

Mit der Zeit bekommen die Systemadministratoren wissen, was mit jeder Art von Ausnahme zu machen und entsprechend verfahren.

Aber! Ihre Anwendung kann das nicht ohnehin groß. Wahrscheinlich kann man das gleiche haben nur die Protokolldateien parsen.

würde ich die Idee der Speicherung von Fehlerprotokollen in einer Datenbank entgegenzutreten. Das Logging-System sollte so einfach wie möglich sein und nicht beinhalten Komponenten, die einen Protokolldatensatz zu schreiben, nicht zu 100% necesary sind.

Die Dinge können ziemlich komplex, wenn sie in eine DB Anmeldung - z.B. Sie können Probleme mit allen Datenbank-Fehlern im Zusammenhang mit der Anmeldung (wie Fehler zu protokollieren, die aufgetreten, weil DB nicht wegen einer schweren Last oder einer Infrastruktur Fehler reagiert, zum Beispiel); andere Frage, die ich eine potentielle Notwendigkeit für die Protokollierung separate Transaktionen haben, sehen würde, etc.

Auf der anderen Seite, für einen Fehler eine Referenz-ID aufweist, ist keine schlechte Idee, aber wieder, dies bedeutet es auch, die Komplexität des Erfassungssystems zu erhöhen (zB wie würden Sie die ref propagieren. ID durch alle Schichten Ihrer Anwendung wenn ein Fehler auftritt?)

In Projekten, die ich zu tun habe, die allgemeine Richtlinie ist es, Fehler wie verbosely wie möglich anmelden, und so viele Kontextinformationen wie möglich zu schließen (die Protokolle zu schreiben, verwenden wir einen ‚konventionellen‘ Ansatz in die Regel - log4j oder simillar ). Normalerweise funktioniert dies gut, auch für hoch belastete Systeme.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow