Wenn Sie die Protokolldateien eines beliebigen Produktionssystems durchsehen, werden Sie erstaunt sein, wie viele Meldungen auf der Fehlerebene protokolliert werden. Es ist nicht ungewöhnlich, Hunderte bis Tausende von Fehlermeldungen pro Tag zu finden! Wenn Sie Entwickler oder Systemadministratoren auf diese Meldungen hinweisen, bekomme ich in der Regel die Antwort: "Oh, das ist normal". Lassen Sie mich Ihnen sagen: Das ist nicht normal. Jede Diagnosemeldung, die auf der Error-Ebene protokolliert wird, ist ein Hinweis auf einen Fehler im System. Wenn eine Fehlerprotokollmeldung auf eine Situation verweist, die nicht fehlerhaft ist, ist das ein Fehler an sich und kann Sie für echte Fehler, die protokolliert werden, blind machen. Das Lustige daran ist, dass das Anwendungsprotokoll ein sehr guter Indikator für die Reife des Systems ist.

Als Architekt muss ich oft den Reifegrad des Systems definieren. Der Reifegrad bezieht sich auf die Systemqualität in Bezug auf die Fehlerhäufigkeit der Software. Wie oft soll also ein Fehler im System auftreten? Sie können dies mit der Frage vergleichen: "Wie oft möchten Sie, dass Ihr Auto eine Panne hat?" Einmal pro Tag? Einmal in der Woche? Einmal im Monat? Einmal im Jahr? Dies gilt unabhängig von der Schwere der Störung: Es kann sich um eine Warnleuchte handeln, die einen Zustand anzeigt, den es gar nicht gibt, oder um einen kompletten Ausfall. Aber wie ich aus meiner Erfahrung mit italienischen Autos weiß: Je häufiger kleine Fehler auftreten, desto größer ist die Wahrscheinlichkeit, dass ein großer Fehler wie eine Panne auftritt. Der Zusammenhang zwischen der Fehlerdichte und der mittleren Zeit zwischen zwei Ausfällen wurde auch von Caper Jones vor langer Zeit bei einem Computersystem beobachtet. Warum sind also die Anwendungsprotokolle ein sehr guter Indikator für die Reife des Systems? Die Argumentation ist ganz einfach: Wo Menschen arbeiten, werden Fehler gemacht. Wenn ein Fehler im Quellcode gemacht wird, wird ein "Defekt" in das System eingefügt. Ein Defekt ist ein potenzieller Fehler, der unter bestimmten Bedingungen zu einem Ausfall führen kann. Ein Fehler ist die Unfähigkeit des Systems, die angeforderte Funktion gemäß der Spezifikation auszuführen. Einige Arten von Fehlern, wie z.B. das Erzeugen eines falschen Ergebnisses, werden im Protokoll nicht angezeigt. Einige andere Fehler werden jedoch im Systemprotokoll erscheinen. Die Häufigkeit der in einer Protokolldatei gemeldeten Fehler ist eine Teilmenge aller Fehler im System, die wiederum eine Teilmenge aller Fehler im System ist. Daher ist die Häufigkeit der Fehlermeldungen im Protokoll ein guter Indikator dafür, wie gut das System aufgebaut ist! Wenn die Protokolle eine sehr hohe Häufigkeit von Fehlermeldungen aufweisen, würde man viele Fehler im System erwarten. Andererseits würde mich das völlige Fehlen von Fehlern in den Protokolldateien misstrauisch machen. Es könnte sein, dass es sich um ein sehr gut entwickeltes Produkt handelt, aber es könnte auch auf das Fehlen einer anderen Systemqualität hinweisen: Analysierbarkeit. Analysierbarkeit ist die Qualität des Systems, die sich auf den Aufwand bezieht, der für die Diagnose von Mängeln oder Fehlerursachen erforderlich ist. Natürlich hilft Ihnen die Analyse der Protokolldatei eines Produktionssystems nicht dabei, ein qualitativ hochwertiges System zu erstellen. Aber wenn Sie ein System aufbauen, sollten Sie die Fehlerhäufigkeit in den Protokolldateien überwachen, der genauen Ursache Aufmerksamkeit schenken und sie beseitigen, wenn es sich um einen strukturellen Fehler handelt. Auf diese Weise fügt die Protokolldatei Ihrem Entwicklungsprozess eine billige und leicht verfügbare Technik zur Fehlerbeseitigung hinzu.