3.1 Liste der Veranstaltungsstufen
Bei der Protokollierung werden alle Ereignisse aufgezeichnet, die während der Ausführung des Programms auftreten. Ihre Pflicht als Programmierer besteht record everything importantdarin, dass productionSie bei seltsamen und/oder schwerwiegenden Fehlern nichts anderes als diese Protokolle haben.
Jeder Fehler wird um ein Vielfaches schneller behoben, wenn Sie alle Informationen darüber und über den gesamten Verlauf der Anrufe haben. Daraus folgt jedoch eine einfache Schlussfolgerung: Alles im Allgemeinen zu protokollieren: Aufrufe aller Methoden, Werte aller Parameter.
Auch das ist keine Option – zu viele Informationen sind genauso schlecht wie zu wenig. Wir brauchen intelligente Protokollierung. Von Menschen für Menschen gemacht. Und hier kommen wir zum ersten Fakt zur Protokollierung: Alle Einträge im Protokoll sind bereits zum Zeitpunkt ihrer Erstellung in Kategorien unterteilt.
Der Programmierer muss beim Schreiben eines Ereignisses in das Protokoll selbst entscheiden, wie wichtig diese Informationen sind. Der Schweregrad des Ereignisses wird vom Autor der Nachricht ausgewählt. Es log4jgibt 5 Ebenen der Wichtigkeit protokollierter Informationen:
DEBUGINFOWARNERRORFATAL
Im Folgenden werden wir ausführlicher darüber berichten.
3.2 DEBUG
Das Niveau DEBUGgilt als das unwichtigste. Informationen, die mit dieser Wichtigkeitsstufe in das Protokoll geschrieben werden, werden nur während des Anwendungsdebuggens benötigt. Um beim Debuggen benötigte Informationen zu protokollieren, wird die Methode verwendet debug().
Beispiel:
class Manager {
private static final Logger logger = LoggerFactory.getLogger(Manager.class);
public boolean processTask(Task task) {
logger.debug("processTask id = " + task.getId());
try {
task.start();
task.progress();
task.complete();
return true;
} catch (Exception e) {
logger.error("Unknown error", e);
return false;
}
}
}Beachten Sie, dass sich die Methode debugganz am Anfang der Methode befindet (die Methode hatte noch keine Zeit, etwas zu tun) und den Wert der an die Methode übergebenen Variablen in das Protokoll schreibt. Dies ist der häufigste Anwendungsfall für die Methode debug().
3.3 INFO und WARNUNG
Die nächsten beiden Ebenen sind INFOund WARN. Für sie gibt es zwei Methoden – info()und warn().
Die Ebene INFOwird lediglich für Informationsmeldungen verwendet: Dies und das passiert. Wenn Sie mit der Analyse eines Fehlers im Protokoll beginnen, kann es sehr nützlich sein, dessen Hintergrund zu lesen. Dafür ist die Methode perfekt geeignet info().
Die Ebene WARNwird zum Schreiben von Warnungen verwendet (vom Wort Warnung ). Normalerweise wird bei dieser Wichtigkeitsstufe die Information geschrieben, dass etwas schief gelaufen ist, aber das Programm weiß, was in dieser Situation zu tun ist.
Beim Schreiben einer Datei auf die Festplatte stellte sich beispielsweise heraus, dass eine solche Datei bereits vorhanden war. Hier kann das Programm eine Warnung (Warnung) protokollieren, dem Benutzer jedoch ein Dialogfeld anzeigen und anbieten, einen anderen Dateinamen auszuwählen.
Beispiel:
class FileManager {
private static final Logger logger = LoggerFactory.getLogger(FileManager.class);
public boolean saveFile(FileData file) {
logger.info(“save the file ” + file.getName());
boolean resultOK = SaveUtils.save(file);
if (resultOK) return true;
logger.warn(“file writing problem ” + file.getName());
String filename = Dialog.selectFile();
boolean result = SaveUtils.save(file, filename);
return result;
}3.4 FEHLER und FATAL
Schließlich sind die beiden wichtigsten Protokollierungsebenen ERRORund FATAL. Für sie gibt es auch spezielle Methoden mit den gleichen Namen: error()und fatal().
Sie beschlossen außerdem, Fehler in zwei Kategorien zu unterteilen: gewöhnliche Fehler und schwerwiegende Fehler . Ein schwerwiegender Fehler führt meist zu einem Anwendungsabsturz (für Desktop-Anwendungen) oder einem Webdienst-Absturz (für Webanwendungen).
Ein weiteres gutes Beispiel ist das Windows-Betriebssystem. Wenn Ihr Programm gerade abgestürzt ist, ist dies aus Sicht des Betriebssystems der Fall Error. Und wenn das Betriebssystem selbst heruntergefahren ist und Sie den Windows-Bluescreen des Todes sehen, dann ist dies bereits der Fall Fatal error.
ErrorIn Java-Anwendungen werden Ereignisse am häufigsten Fatalmit ausgelösten Ausnahmen in Verbindung gebracht. Beispiel:
class Manager {
private static final Logger logger = LoggerFactory.getLogger(Manager.class);
public boolean processTask(Task task) {
logger.debug("processTask id = " + task.getId());
try {
task.start();
task.progress();
task.complete();
return true;
} catch (Exception e) {
logger.error("Unknown error", e);
return false;
}
}
}3.5 Was protokolliert werden soll
Natürlich lohnt es sich nicht, alles hintereinander zu protokollieren. In den meisten Fällen verschlechtert sich dadurch die Lesbarkeit des Protokolls erheblich, und schließlich wird das Protokoll überhaupt erst geschrieben, um gelesen zu werden.
Darüber hinaus können Sie verschiedene persönliche und finanzielle Informationen nicht in das Protokoll schreiben. Wenn Sie dies strikt und einfach tun, können Sie mit Bußgeldern oder Klagen rechnen. Früher oder später läuft ein solcher Baumstamm zur Seite und dann gibt es keine Probleme mehr.
Was sollte also protokolliert werden?
Zunächst müssen Sie den Start der Anwendung protokollieren . Nach dem Start der Anwendung wird empfohlen, deren Betriebsmodus und verschiedene wichtige Einstellungen zu protokollieren – dies erleichtert in Zukunft das Lesen des Protokolls.
Zweitens müssen Sie den Status aller Drittanbieterdienste protokollieren , mit denen Ihre Anwendung zusammenarbeitet: Mailingsysteme, alle externen Dienste. Sie müssen zumindest den Moment der Verbindung zu ihnen sichern, um sicherzustellen, dass sie ordnungsgemäß funktionieren.
Drittens müssen alle Ausnahmen protokolliert werden . Wenn sie erwartet werden, können Informationen dazu kompakt geschrieben werden. Vollständige Informationen zu Ausnahmen liefern 50–80 % der wichtigen Informationen bei der Suche nach einem Fehler.
Sie müssen auch das Herunterfahren der Anwendung protokollieren . Die Anwendung muss normal beendet werden und darf nicht Dutzende von Fehlern in das Protokoll werfen. An dieser Stelle finden Sie häufig festsitzende Aufgaben, Probleme mit dem Thread-Pool oder Probleme beim Löschen temporärer Dateien.
Stellen Sie sicher, dass Sie alles protokollieren, was mit Sicherheit und Benutzerautorisierung zu tun hat . Wenn ein Benutzer zehnmal hintereinander versucht, sich anzumelden oder sein Passwort zurückzusetzen, sollten sich diese Informationen in den Protokollen widerspiegeln.
Protokollieren Sie so viele Informationen wie möglich über asynchrone Aufgaben – Ausnahmen gehen in solchen Threads oft verloren. Achten Sie bei einer asynchronen Aufgabe darauf, deren Start und Ende zu protokollieren. Ein erfolgreicher Abschluss sollte genauso protokolliert werden wie ein problematischer.
Was sonst? Starten von zeitgesteuerten Aufgaben, Starten gespeicherter Aufgaben SQL-procedures, Synchronisieren von Daten, alles, was mit verteilten Transaktionen zu tun hat. Ich denke, das reicht für den Anfang. Sie werden diese Liste in Zukunft ergänzen.