Ich habe noch nie Programme geschrieben, die die Protokollierung in erheblichem Maße nutzen. Das Beste, was ich getan habe, ist, Stack-Traces zu erfassen, wenn Ausnahmen auftreten.
Ich habe mich gefragt, wie viel loggen andere Leute? Kommt es darauf an, welche Art von Bewerbung Sie schreiben? Finden Sie die Protokolle tatsächlich hilfreich?
Antworten:
Für die Arbeit habe ich größtenteils eingebettete Anwendungen erstellt und mich in einem unschätzbaren Tool angemeldet. Zumindest müssen Fehler mit genügend Informationen protokolliert werden, um auf die Codezeile zu verweisen. Als nächstes wären wichtige Funktionspunkte in der gesamten Anwendung. Dinge wie der Administrator haben auf den Computer zugegriffen. Wir verwenden ein System, mit dem wir eine ausführlichere Protokollierung ermöglichen. Dies ist normalerweise entwicklerspezifisch. Es kann verwendet werden, um den Entwickler beim Testen der Funktion zu unterstützen, oder um die Diagnose eines Kundenproblems zu unterstützen.
Ich habe die Protokollierung in allen von mir entwickelten Anwendungen verwendet. Es hat immer zu einem besseren Verständnis des Ablaufs einer Anwendung geführt. Vor allem in den Händen eines Kunden. Sie beschränken ihre Anwendungsfälle niemals (selten) auf diejenigen, mit denen Sie testen.
Ich denke nicht, dass es von der Art der Anwendung abhängt: Die Protokollierung ist in allen (nicht trivialen) Anwendungen nützlich . Sicherlich, ich denke, es kann sein , mehr in einigen Anwendungen nützlich als andere, aber ich glaube nicht , dass es jemals ist nutzlos .
Insbesondere im Falle eines Fehlers gibt ein Stack-Trace den Status des Programms zum genauen Zeitpunkt des Fehlers an, aber Sie haben nur sehr wenig Ahnung von dem Status unmittelbar vor dem Fehler. Diese Informationen können sehr nützlich sein, um das Problem aufzuspüren, und die Protokollierung kann einen nützlichen Einblick in dieses Problem liefern. Ich denke, das ist etwas, von dem alle bis auf die trivialsten Programme profitieren können.
Eine andere Verwendung der Protokollierung, die möglicherweise nicht für alle Programme nützlich ist, ist die Statistikanalyse. Beispielsweise protokolliert Ihr Webserver normalerweise jede eingehende Anforderung, und dann gibt es viele Tools, mit denen Sie diese Protokolle analysieren und Diagramme Ihrer geschäftigsten Zeiten, der beliebtesten Seiten usw. erstellen können. Sie können diese Daten für die Kapazitätsplanung verwenden ("Benötige ich einen größeren Server?") Und so weiter.
Es gibt zwei Gründe für die Protokollierung:
Die Diagnoseprotokollierung wurde bereits von anderen besprochen, und ich werde nicht mehr weiter darauf eingehen. Ich sage nur, Sie sollten sich genau überlegen, was passiert, wenn ein Protokollfehler auftritt. Interessiert es Sie genug, eine Ausnahme über die App auszulösen oder auf andere Weise zu verwalten? Dies ist ein "es hängt davon ab", aber Protokollinformationen sollten wahrscheinlich übersprungen werden.
Die Audit-Protokollierung ist eine Geschäftsanforderung. Die Überwachungsprotokollierung erfasst wichtige Ereignisse im System und ist das, woran das Management und die Rechtsabteilung interessiert sind. Dies sind Dinge wie die, die sich abgemeldet haben, wer welche Änderungen vorgenommen hat usw. Als Systemadministrator oder Entwickler sind Sie wahrscheinlich an der Fehlerbehebung des Systems beteiligt nur wenig interessiert an diesen. In vielen Fällen ist diese Art der Protokollierung jedoch absolut Teil der Transaktion und sollte die gesamte Transaktion fehlschlagen, wenn sie nicht abgeschlossen werden kann.
Es ist für mich nicht nur hilfreich, über die beiden getrennt nachzudenken, da die eine "optional" und die andere obligatorisch ist, sondern weil ich sie je nach Anforderung möglicherweise auch separat implementieren muss. Es kann (manchmal) vorkommen, dass beide Früchte sind, aber eines sind Äpfel und das andere Orangen. In der Regel kann ein einzelnes Protokollierungsframework jedoch beides verarbeiten.
Bei den meisten Server-Aufgaben ist die Protokollierung von entscheidender Bedeutung, da der Administrator in der Regel nicht da ist, wenn etwas passiert, sodass er dies nachträglich überprüfen muss.
Ein Mitarbeiter von Google hat mir jedoch einmal mitgeteilt, dass die Serverprozesse keine Protokollierung durchführen. stattdessen sind sie "instrumentiert"; Das bedeutet, dass jeder Prozess Hooks oder Ports hat (er hat die Mechanik nicht angegeben), an denen andere Prozesse rasten können, um nach Parametern und Statistiken zu fragen. Es sind diese Überwachungsprozesse, die viele Dinge in den Protokollen speichern. Der Vorteil ist, dass die Informationen, die sie erhalten, nicht "eine Datei öffnen", "dies schreiben", "das holen" sind. Sie erhalten Dinge wie "45.453 Dateien geöffnet", "653 Clients von Service X", "344 ms durchschnittliche Antwort für Abfrage Y".
Sicherlich ist es ein anderer Ansatz, den ich beim Babysitten meiner Systeme im Hinterkopf habe, auch wenn sie einige Größenordnungen kleiner sind.
Ich kam von einer Winforms N-Tiered-Anwendung, die alles protokollierte.
Es war nicht sehr nützlich.
Sicher, das Aufzeichnen von Ausnahmen ist großartig. Aber warum sollten Sie sie auf dem Client-Computer protokollieren, wenn Sie die Ausnahme einfach per E-Mail an das Entwicklerteam senden können?
Das Aufzeichnen von Informationen wird leicht zu einer Sucht, deren Wert selten gerechtfertigt ist. In jeder Situation, in der Sie sich unentgeltlich anmelden können, ist es besser, gezielte Informationen zu sammeln und an den Ort zu senden, an dem Sie sie benötigen.
Das Erfassen von Ausnahmeinformationen ist ein Muss, da dies in gewissem Maße sehr hilfreich sein kann. Manchmal reichen Ausnahmeinformationen jedoch nicht aus, insbesondere wenn der Benutzer / Client der Anwendung keinen Fehler mit den richtigen Informationen melden kann.
Beschränkt sich die Protokollierung nur auf die Erfassung von Fehlerinformationen?
In meinem Fall (Webanwendung) protokolliere ich immer, welche Seite wann besucht wird, auf was sie klickt, wo die IP und der Browser usw. Ich protokolliere sogar die Gesamtladezeit für jeden Seitenbesuch, damit ich weiß, welche Seiten langsam sind und müssen optimiert werden. Also kann ich sagen, dass ich so viel wie möglich logge.
Ich hatte zunächst keine Ahnung, wie bedeutend es sein wird. aber anscheinend ist es in vielen Dingen sehr hilfreich (außer beim Debuggen):
Ich denke, die Protokollierung kann bedeutender werden, wenn wir statistische Informationen darin gerne ausgraben.
Ich bin Entwickler in einem Unternehmen, dessen Produkte im Ausland eingesetzt werden. Wenn ein Support-Team nach einer Problemdefinition fragt, sind meine einzigen Diagnosetools meine Protokolldateien und eine Kopie der Kundendatenbank. Unter Verwendung der Datenbank und meiner Entwicklungsumgebung habe ich die Möglichkeit, den fehlerhaften Fall zu reproduzieren, da ich die eingehenden Daten in meinem Modul und den damit verbundenen Aktionen protokolliere. Wenn ich den Fehler mithilfe der von mir gesammelten Daten reproduzieren kann, kann ich ihn durch Debuggen beheben. Wenn ich keine Protokolldateien hätte, müsste ich mich auf die Beschreibung des Kunden oder des Supportteams verlassen, was in welchem Fall passiert (was mit großer Wahrscheinlichkeit irreführend ist).
Zweitens gibt mir die Protokollierung die Möglichkeit, die Engpässe meines Moduls am implementierten Standort zu erkennen, da ich das Datum und die Uhrzeit bestimmter Aktionen protokolliere und dann sehen kann, welche Aktion wie viel Zeit in Anspruch nimmt.
Angenommen, unsere Lösung besteht aus 6 Modulen und in meinen Protokolldateien werden Fehlerprotokolle zu Datenbank-Timeouts angezeigt. Wenn diese Fehler auch in 5 anderen Modulen protokolliert werden, steigt die Wahrscheinlichkeit, dass es sich um ein SQL Server-Problem handelt. Wenn dies nur in meinem Modul protokolliert wird, wird die Wahrscheinlichkeit, dass meine Abfragen fehlerhaft sind, größer. Ich denke, solche Dinge sind nützliche Indikatoren.
Welche Art von Daten in meinen Protokolldateien angezeigt werden, hängt von der Konfiguration der Protokollebene ab. Wenn dies ein neues Produkt ist, setzen wir die Protokollebene auf "Alle", um so viele Daten wie möglich zu erfassen. Wenn wir das Produkt verbessern, möchten wir möglicherweise lieber die Protokollebene "Fehler" beibehalten, um nur die Fehlerprotokolle, nicht jedoch die Protokolle der Informationsebene usw. zu protokollieren.
Die Protokollierung ist nützlich für die Informationen, die Sie von anderen Programmen nicht erhalten können:
Hinweis: Sie möchten mindestens ZWEI Protokolldateien.
Die INFO ist immer an. Der DEBUG ist eingeschaltet, wenn er benötigt wird.
Schreiben Sie Protokollierungscode in der Erwartung, dass Sie eines Tages eine Situation debuggen müssen, in der ALLES, was Sie haben, die Protokolldatei ist. Wenn Sie es richtig machen, kann dies der Unterschied zwischen dem Abfeuern und dem Heraufstufen sein.
Für die Extrameile müssen alle Funktionsaufrufe ihre Parameter zu jedem Stack-Trace in Java mit hinzufügen
public void sendEmail(String sender, String recipient) {
try {
...
} catch (Exception e) {
throw new RuntimeException("sendEmail(sender="+sender+", recipient="+recipient+")");
}
Dieser Ansatz erweitert Ihren Aufruf-Stack im Wesentlichen um Parameterwerte und ermöglicht Ihnen möglicherweise, die Situation nur mit dem Stack-Trace zu analysieren, ohne die Protokolldateien anzeigen zu müssen.
Ich würde auch empfehlen, dass alle nicht-trivialen Apps mehrstufige Protokollierung verwenden.
Aus den Gründen, die andere angegeben haben, ist es ein unschätzbares Werkzeug zur Lösung von Problemen mit der Anwendung.
In einigen Fällen ist die Protokollierung unerlässlich, beispielsweise in Finanzanwendungen und anderen Domänen, in denen Aktivitätsprotokolle erforderlich sind, um Sicherheit, Nutzungsmetriken und Überwachung zu gewährleisten.
Dies hängt mit Sicherheit von der Art des Systems ab, das Sie erstellen.
Wenn Sie eine eigenständige Desktop-Anwendung wie ein Textverarbeitungsprogramm schreiben, ist wahrscheinlich keine Protokollierung erforderlich.
Wenn Sie ein eingebettetes System schreiben, können Sie nicht ohne Protokollierung leben. Andernfalls haben Sie keine Ahnung, warum Ihr eingebettetes Gerät einfriert. Sie müssen auch immer dann protokollieren, wenn Ihr System mehrere Prozesse oder mehrere physische Maschinen umfasst, die miteinander kommunizieren. Auch wenn das System hängt, müssen Sie wissen, welcher Teil davon wann und warum abgestorben ist. Sie müssen in der Lage sein, Protokolle zu vergleichen, um festzustellen, ob die Daten von einem Prozess zum anderen übertragen wurden. Aus dem gleichen Grund müssen Sie immer dann protokollieren, wenn Ihr System über einen längeren Zeitraum ohne direkte Benutzerinteraktion ausgeführt werden soll.
Protokollierung ist immer nützlich. Beachten Sie jedoch, dass Sie bei der Implementierung nicht unbedingt die Protokolle lesen müssen. Vielleicht ist es eine Art Administrator, Endbenutzer, Kunde, Support-Team, ...
Protokollieren Sie also nicht nur Stacktraces, sondern auch einige zusätzliche Informationen, die von Nicht-Entwicklern interpretiert werden können. Wenn Ihre Anwendung von anderen Gruppen verwaltet wird, ist es auch hilfreich, eindeutige Fehlercodes in Ihre Protokolle zu schreiben. Dies kann den Support, die Automatisierung usw. vereinfachen.
Ein weiterer Punkt aus Sicht des Administrators: Denken Sie an die Protokollrotation.