Zum Hauptinhalt gehen

Aussagekräftige Logs?!

Kommentare

1 Kommentar

  • Zendesk API User
    Author: hoebbel - 8/12/2011 12:52

    Hallo Herr Strecker,

    Wenn Sie schreiben, man benötigt die "drüberliegenden INFO Meldungen", meinen Sie tatsächlich im Log vorher stehende Meldungen oder zeitlich vorausgehende Meldungen? Im Log, wie ich es im Monitoring Bereich sehe, stehen nämlich die ältesten Seiten ganz unten.

    Sorry, ich lesen die Logfiles immer als Textdateien (direkt das fs-server.log aus dem Dateisystem), und da sind die Fehlermeldungen dann genau anders herum sortiert als im Server-Monitoring.

    Ich meinte die zeitlich vorrausgehenden Meldungen.

    Die Fehler traten bei uns "spontan" auf, d.h. beim letzten Deployment funktionierte alles, jetzt gibt es Probleme. In diesem Fall handelt es sich sogar um ein produktives System. Wenn wir jetzt für alle Seiten, die das entsprechende Template verwenden, den Debug-Modus einschalten, wird das Deployment sicherlich viel länger dauern, oder?

    Die "spontan" auftretenden Fehler resultieren aber wahrscheinlich aus Änderungen im projekt (zum Beispiel wurde ein Medium neu verlinkt, welches nie freigegeben wurde und auf dieses wird nun versucht per Skript zuzugreifen, ohne das geprüft wird, ob das Medium wirklich existiert.

    Die Dauer des Deployments wird sich verlängern, aber diese Verlängerung sollte marginal sein.

    Die Größe der Logfiles wird allerdings deutlich anschwellen.

    Warum schaltet man die - gerade bei Fehlern eklatant wichtigen - Kontext-Informationen ab? Aus meiner Erfahrung weiß ich, dass man mit den richtigen Informationen (hier wären es: Seite/Inhalt bzw. ID, Kanal, Sprache, Section/Template, Stacktrace) viel schneller ans Ziel kommt als wenn man erst eine globale Einstellung anpassen muss, das ganze Projekt erneut generieren muss, dann den Fehler suchen, und am Ende der Behebung die Einstellung wieder rückgängig machen muss. Ich sage ja nicht, dass die Informationen immer geloggt werden müssen, aber im Fehlerfall (der ja hoffentlich nicht oft auftritt) ist die Information kritisch.

    Eigentlich sollten diese Fehler während der Entwicklungsphase des Projektes durch entsprechende QS identifiziert und ausgeschlossen werden. Während dieser Phase macht es dann Sinn, den debugMode zu aktivieren.

    Aufgrund der Angaben, auf welcher Seite der Fehler geflogen ist, die auch im normalen log zu finden sind, kann man die Generierung/Vorschau im debugMode auf einzelne Seiten beschränken. Eine Generierung des kompletten Projektes ist nur notwendig, wenn die Fehler auf sehr vielen Seiten auftreten.

    P.S: Das Umstellen des global.debugMode hat von 7 Fehlern/0 Warnungen zu 7 Fehlern/4460 Warnungen geführt...

    Diese zusätzlichen WARN Meldungen sind höchstwahrscheinlich Meldungen, die besagen, dass ein NULL Wert nicht abgefangen wird. Im Templatequelltext werden die meisten dieser Fehler ohne den debugMode nicht ausgegeben, da deren Ausgabe nur für die Entwicklungsphase eines Projektes von Bedeutung sein sollte.

    Viele Grüsse aus Dortmund,

      Holger Höbbel

    0

Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.