it-swarm-eu.dev

Protokollierung: Warum und was?

Ich habe noch nie Programme geschrieben, die die Protokollierung in erheblichem Maße nutzen. Das Beste, was ich getan habe, ist, Stapelspuren zu erfassen, wenn Ausnahmen auftreten.

Ich habe mich gefragt, wie viel andere Leute protokollieren. Kommt es darauf an, welche Art von Bewerbung Sie schreiben? Finden Sie die Protokolle tatsächlich hilfreich?

40
Winston Ewert

Für die Arbeit habe ich weitgehend eingebettete Anwendungen durchgeführt 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 können. Dies ist normalerweise entwicklerspezifisch. Es kann verwendet werden, um den Entwickler beim Testen der Funktion zu unterstützen, oder um bei der Diagnose eines Kundenproblems zu helfen.

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. Besonders wenn in den Händen eines Kunden. Sie beschränken ihre Anwendungsfälle niemals (selten) auf diejenigen, gegen die Sie testen.

24
Jeff

Ich denke nicht, dass es von der Art der Anwendung abhängt: Die Protokollierung ist in all (nicht trivialen) Anwendungen nützlich. Sicher, ich denke, es kann mehr in einigen Anwendungen nützlich sein als in anderen, aber ich denke nicht, dass es jemals nutzlos ist.

Insbesondere im Fehlerfall zeigt eine Stapelverfolgung den Status des Programms am Fehlerpunkt gena an, aber Sie haben nur sehr wenig Ahnung über den Status kurz vor auf den 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 geben. Ich denke, das ist etwas, von dem alle außer den trivialsten Programmen profitieren können.

Eine andere Verwendung der Protokollierung, die möglicherweise nicht für alle Programme nützlich ist, ist die statistische Analyse. 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.

19
Dean Harding

Es gibt zwei Gründe, warum die Protokollierung durchgeführt wird:

  1. Diagnose
  2. Prüfung

Diagnoseprotokollierung wurde bereits von anderen besprochen, und ich werde den Punkt nicht weiter erläutern. Ich sage nur, Sie sollten genau darüber nachdenken, 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 das Protokollieren von Nachrichten auf Informationsebene sollte wahrscheinlich übersprungen werden.

Audit Logging ist eine Geschäftsanforderung. Die Audit-Protokollierung erfasst wichtige Ereignisse im System und ist das, woran das Management und die Rechtsadler interessiert sind. Dies sind Dinge, die sich von etwas abgemeldet haben, wer welche Änderungen vorgenommen hat usw. Als Systemadministrator oder Entwickler bei der Fehlerbehebung des Systems sind Sie wahrscheinlich 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.

Das getrennte Nachdenken über die beiden ist für mich nicht nur hilfreich, weil eines "optional" und das andere obligatorisch ist, sondern weil ich sie je nach Anforderungen möglicherweise separat implementieren muss. Es kann (manchmal) vorkommen, dass beide Früchte sind, aber einer sind Äpfel und der andere Orangen. Normalerweise kann ein einzelnes Protokollierungsframework jedoch beides verarbeiten.

9
MIA

Bei den meisten Serveraufgaben ist die Protokollierung von entscheidender Bedeutung, da der Administrator normalerweise nicht da ist, wenn etwas passiert. Daher muss er dies nachträglich überprüfen.

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 zwischenrufen 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 "Datei öffnen", "Schreiben", "Abrufen" 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 dies ein anderer Ansatz, den ich beim Babysitten meiner Systeme im Hinterkopf habe, auch wenn sie um einige Größenordnungen kleiner sind.

8
Javier

Ich stamme aus einer Winforms N-Tiered-Anwendung, die alles protokollierte.

Es war nicht sehr nützlich.

Sicher, Ausnahmen zu protokollieren 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 Protokollieren von Informationen wird leicht zu einer Sucht, deren Wert selten gerechtfertigt ist. In jeder Situation, in der Sie sich kostenlos anmelden können, ist es besser, gezielte Informationen zu sammeln und an den Ort zu senden, an den Sie sie benötigen.

4
George Stocker

Das Erfassen von Ausnahmeinformationen ist ein Muss, da dies bis zu einem gewissen Grad 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.

Ist die Protokollierung nur auf die Erfassung von Fehlerinformationen beschränkt?

In meinem Fall (Webanwendung) protokolliere ich immer, welche Seite besucht wird, wann, worauf sie klicken, wo die IP & der Browser usw. Ich protokolliere sogar die Gesamtladezeit für jeden Seitenbesuch, damit ich weiß, welche Seiten langsam sind und brauchen Optimierung. so kann ich sagen, dass ich so viel wie möglich logge.

anfangs hatte ich keine Ahnung, wie wichtig es sein wird. aber anscheinend ist es in vielen Dingen sehr hilfreich (außer beim Debuggen):

  • das Verhalten des Benutzers verstehen
  • bewertung der Akzeptanz neuer Funktionen
  • unterscheiden Sie zwischen Early Adopters, Betrügern oder potenziellen Kunden

Ich denke, die Protokollierung kann an Bedeutung gewinnen, wenn wir gerne statistische Informationen darin ausgraben.

4
Anwar Chandra

Ich bin Entwickler in einem Unternehmen, dessen Produkte im Ausland eingesetzt werden. Wenn ein Support-Team nach einer Problemdefinition fragt, sind meine einzigen Diagnosewerkzeuge meine Protokolldateien und eine Kopie der Kundendatenbank. Mithilfe 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 zugehörigen Aktionen protokolliere. Wenn ich den Fehler mithilfe der 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 eine große Wahrscheinlichkeit der Irreführung darstellt).

Zweitens gibt mir die Protokollierung die Möglichkeit, die Engpässe meines Moduls am bereitgestellten Standort zu erkennen, da ich Datum und Uhrzeit bestimmter Aktionen protokolliere und dann einen Blick darauf werfen kann, welche Aktion wie viel Zeit in Anspruch nimmt.

Angenommen, unsere Lösung besteht aus 6 Modulen. In meinen Protokolldateien werden Fehlerprotokolle zu Datenbank-Timeouts angezeigt. Wenn diese Fehler auch in 5 der anderen Module 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 wird, hängt von der Konfiguration der Protokollstufe ab. Wenn es sich um ein neues Produkt handelt, setzen wir die Protokollebene auf "Alle", um so viele Daten wie möglich zu erfassen. Wenn wir das Produkt verbessern, ziehen wir es möglicherweise vor, die Protokollebene auf "Fehler" zu halten, um nur den Fehler zu protokollieren, nicht jedoch die Protokolle auf Informationsebene usw.

2
aslisabanci

Die Protokollierung ist nützlich für Informationen, die Sie von anderen Programmen nicht erhalten können:

  • Erfassen Sie Stapelspuren (Sie haben diese)
  • Erfassen Sie, welche Daten verarbeitet wurden, als Ihre Anwendung abstürzte. Denken Sie daran, Debugger helfen nur, wenn sie beim Absturz vorhanden sind.
  • Profilinformationen. Wenn Sie keinen Profiler in der Produktionsumgebung ausführen können, können Sie mithilfe der umfangreichen Protokollierung einschließlich Zeitstempel herausfinden, wo die Zeit vergangen ist. Selbst wenn Sie nicht in der Lage sind, dies zu erkennen, können Sie möglicherweise feststellen, dass es sich außerhalb Ihres Programms befindet (z. B. das Einsetzen der Speicherbereinigung).
  • Statistiken werden beim Schreiben des Programms nicht erwartet. Ich wurde gebeten, Diagramme des Verhaltens über die Zeit für Intervalle bereitzustellen, die aus anderen Gründen interessant sind. Die erforderlichen Daten könnten mit ein paar grep + awk + Perl-Ninja-Tricks aus den Protokolldateien extrahiert werden.

Hinweis: Sie möchten mindestens ZWEI Protokolldateien.

  • Eine auf DEBUG-Ebene - mit allen Informationen, die Sie sich vorstellen können, dass Sie sie jemals benötigen werden (einschließlich INFO und höher). Wenn das viel zu viel ist, sollten Sie ein zusätzliches TRACE-Level in Betracht ziehen.
  • Eine auf INFO-Ebene - bietet einen 10000-Meter-Überblick über das System. Wichtige Meilensteine ​​gehen hier.

Das INFO ist immer eingeschaltet. Der DEBUG ist bei Bedarf aktiviert.

Schreiben Sie einen Protokollcode, in dem Sie davon ausgehen, dass Sie eines Tages möglicherweise eine Situation debuggen müssen, in der Sie nur die Protokolldatei haben. Wenn Sie dies richtig machen, kann dies den Unterschied zwischen dem Auslösen und dem Heraufstufen ausmachen.

Lassen Sie für die zusätzliche Meile alle Funktionsaufrufe ihre Parameter zu einem beliebigen Stack-Trace in Java with) 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 Aufrufstapel im Wesentlichen um Parameterwerte und ermöglicht es Ihnen möglicherweise, die Situation nur mit dem Stack-Trace zu analysieren, ohne die Protokolldateien anzeigen zu müssen.

2
user1249

Die Protokollierung ist immer nützlich. Beachten Sie jedoch bei der Implementierung, dass nicht unbedingt Sie 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 einigen anderen Gruppen verwaltet wird, ist es auch hilfreich, einige eindeutige Fehlercodes in Ihre Protokolle zu schreiben. Dies kann Support, Automatisierung, ...

Ein weiterer Punkt aus Admin-Sicht: Denken Sie an die Protokollrotation.

1
Christian

Ich würde auch empfehlen, dass alle nicht trivialen Apps eine 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 wichtig, z. B. in Finanzanwendungen und anderen Domänen, für die Aktivitätsprotokolle erforderlich sind, für Sicherheit, Nutzungsmetriken und Überwachung.

1
ocodo

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, benötigen Sie wahrscheinlich keine Protokollierung.

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 protokollieren, wenn Ihr System mehrere Prozesse oder mehrere physische Maschinen umfasst, die miteinander kommunizieren. Wenn das System hängt, müssen Sie wissen, welcher Teil davon wann und warum gestorben ist. Sie müssen in der Lage sein, Protokolle zu vergleichen, um festzustellen, ob die Daten von einem Prozess zum anderen übertragen wurden oder nicht. 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.

1
Dima