it-swarm.com.de

Warum verwenden die meisten Protokolldateien einfachen Text anstelle eines Binärformats?

Die Protokollierung ist notwendig, wird jedoch (relativ) selten verwendet. Als solches kann es in Bezug auf die Lagerung viel kompakter gemacht werden.

Beispielsweise werden die am häufigsten protokollierten Daten wie IP, Datum, Uhrzeit und andere Daten, die als Ganzzahl dargestellt werden können, als Text gespeichert.

Wenn die Protokollierung als Binärdaten gespeichert würde, könnte viel Speicherplatz erhalten bleiben, was weniger Rotation und eine längere Lebensdauer der Festplatte erfordert, insbesondere bei SSDs, bei denen Schreibvorgänge begrenzt sind.

Einige mögen sagen, dass es sich um ein so kleines Problem handelt, dass es nicht wirklich wichtig ist, aber angesichts der Anstrengungen, die erforderlich sind, um einen solchen Mechanismus aufzubauen, macht es keinen Sinn, dies nicht zu tun. Jeder kann das für zwei Tage in seiner Freizeit machen, warum machen die Leute das nicht?

82
php_nub_qq

systemd speichert seine Protokolldateien bekanntermaßen im Binärformat. Die Hauptprobleme, die ich damit gehört habe, sind:

  1. wenn das Protokoll beschädigt wird, ist es schwer wiederherzustellen, da spezielle Tools erforderlich sind
  2. sie sind nicht für Menschen lesbar, daher können Sie keine Standardwerkzeuge wie vi, grep, tail usw. verwenden, um sie zu analysieren

Der Hauptgrund für die Verwendung eines Binärformats (meines Wissens) war, dass es als einfacher angesehen wurde, Indizes usw. zu erstellen, d. H. Es eher wie eine Datenbankdatei zu behandeln.

Ich würde argumentieren, dass der Speicherplatzvorteil in der Praxis relativ gering ist (und abnimmt). Wenn Sie große Mengen an Protokollierung speichern möchten, ist das Zippen von gerollten Protokollen sehr effizient.

Alles in allem würden die Vorteile von Werkzeugen und Vertrautheit in den meisten Fällen wahrscheinlich auf der Seite der Textprotokollierung liegen.

163
Alex

Warum verwenden die meisten Protokolldateien einfachen Text anstelle eines Binärformats?

Suchen Sie nach dem Wort "Text" im Wikipedia-Artikel nix-Philosophie , zum Beispiel finden Sie Aussagen wie:

McIlroy, damals Leiter des Bell Labs CSRC (Computing Sciences Research Center) und Erfinder der Unix-Pipe, [9] fasste die Unix-Philosophie wie folgt zusammen: [10]

Dies ist die Unix-Philosophie: Schreiben Sie Programme, die eines tun und es gut machen. Schreiben Sie Programme, um zusammenzuarbeiten. Schreiben Sie Programme, um Textströme zu verarbeiten, da dies eine universelle Schnittstelle ist.

Oder zum Beispiel aus Grundlagen der Unix-Philosophie ,

Kompositionsregel: Entwerfen Sie Programme, die mit anderen Programmen verbunden werden sollen.

Es ist schwer zu vermeiden, überkomplizierte Monolithen zu programmieren, wenn keines Ihrer Programme miteinander kommunizieren kann.

Die Unix-Tradition empfiehlt nachdrücklich das Schreiben von Programmen, die einfache, textuelle, streamorientierte und geräteunabhängige Formate lesen und schreiben. Unter klassischem Unix werden so viele Programme wie möglich als einfache Filter geschrieben, die bei der Eingabe einen einfachen Textstrom verwenden und bei der Ausgabe in einen anderen einfachen Textstrom umwandeln.

Trotz der populären Mythologie wird diese Praxis nicht bevorzugt, weil Unix-Programmierer grafische Benutzeroberflächen hassen. Dies liegt daran, dass es viel schwieriger ist, die Programme miteinander zu verbinden, wenn Sie keine Programme schreiben, die einfache Textströme akzeptieren und ausgeben.

Textströme beziehen sich auf Unix-Tools wie Nachrichten auf Objekte in einer objektorientierten Umgebung. Die Einfachheit der Text-Stream-Schnittstelle erzwingt die Kapselung der Tools. Ausgefeiltere Formen der prozessübergreifenden Kommunikation, wie z. B. Remoteprozeduraufrufe, zeigen die Tendenz, Programme zu stark in die Interna des jeweils anderen einzubeziehen.

Jeder kann das für zwei Tage in seiner Freizeit machen, warum machen die Leute das nicht?

Das Speichern der Protokolldatei in Binärform ist nur der Anfang (und trivial). Sie müssten dann Tools schreiben, um:

  • Zeigen Sie die gesamte Protokolldatei an (edit)
  • Zeigen Sie das Ende des Protokolls an, ohne den Anfang zu lesen (tail -f)
  • Suche nach Sachen in der Datei (grep)
  • Filtern, um nur ausgewählte/interessante Dinge anzuzeigen (unter Verwendung eines beliebig komplizierten Filterausdrucks)
  • Senden Sie das Protokoll per E-Mail an eine andere Person, die nicht über Ihre Protokolldatei-Decoder-Software verfügt
  • Kopieren Sie ein Fragment der Protokolldatei und fügen Sie es ein
  • Lesen Sie die Protokolldatei, während das Programm (das die Protokolldatei erstellt) noch entwickelt und debuggt wird
  • Lesen Sie Protokolldateien aus alten Versionen der Software (die auf Kundenstandorten bereitgestellt werden und ausgeführt werden).

Natürlich kann und tut Software auch binäre Dateiformate verwenden (z. B. für relationale Datenbanken), aber es lohnt sich nicht (im Sinne von YAGNI ), normalerweise nicht wert, dies zu tun Protokolldateien.

89
ChrisW

Hier gibt es viele umstrittene Vermutungen.

Die Protokollierung war ein wesentlicher Bestandteil von (fast) jedem Job, den ich hatte. Dies ist wichtig, wenn Sie eine Übersicht über den Zustand Ihrer Anwendungen wünschen. Ich bezweifle, dass es sich um eine "Randanwendung" handelt. Die meisten Organisationen, an denen ich beteiligt war, halten Protokolle für sehr wichtig.

Wenn Sie Protokolle als Binärdateien speichern, müssen Sie sie dekodieren, bevor Sie sie lesen können. Textprotokolle zeichnen sich durch Einfachheit und Benutzerfreundlichkeit aus. Wenn Sie über die binäre Route nachdenken, können Sie Protokolle auch in einer Datenbank speichern, in der Sie sie abfragen und statistisch analysieren können.

SSDs sind heutzutage zuverlässiger als HDDs, und die Argumente gegen viele Schreibvorgänge sind weitgehend umstritten. Wenn Sie sich darüber wirklich Sorgen machen, speichern Sie Ihre Protokolle auf einer normalen Festplatte.

49
Robert Harvey

Protokolldateien sind ein wichtiger Bestandteil jeder seriösen Anwendung: Wenn die Protokollierung in der App gut ist, können Sie sehen, welche Schlüsselereignisse wann aufgetreten sind. Welche Fehler sind aufgetreten? und allgemeine Anwendungszustände, die über die Überwachung hinausgehen. Es ist üblich, von einem Problem zu hören, die integrierte Diagnose der Anwendung zu überprüfen (öffnen Sie die Webkonsole oder verwenden Sie ein Diagnosetool wie JMX) und dann die zu überprüfen Protokolldateien.

Wenn Sie ein Nicht-Text-Format verwenden, stehen Sie sofort vor einer Hürde: Wie lesen Sie die Binärprotokolle? Mit dem Protokolllesetool, das sich nicht auf Ihren Produktionsservern befindet! Oder es ist so, aber oh je, wir haben ein neues Feld hinzugefügt und dies ist der alte Leser. Haben wir das nicht getestet? Ja, aber niemand hat es hier eingesetzt. In der Zwischenzeit beginnt Ihr Bildschirm zu leuchten, und Benutzer rufen Sie an.

Oder vielleicht ist dies nicht Ihre App, aber Sie leisten Unterstützung und glauben zu wissen, dass es sich um dieses andere System und WTF handelt? Die Protokolle sind in einem Binärformat? Ok, fang an, Wiki-Seiten zu lesen, und wo fängst du an? Jetzt habe ich sie auf meinen lokalen Computer kopiert, aber - sie sind beschädigt? Habe ich eine nicht-binäre Übertragung durchgeführt? Oder ist das Protokolllesetool durcheinander?

Kurz gesagt, Textlesetools sind plattformübergreifend und allgegenwärtig, und Protokolle sind oft langlebig und müssen manchmal in Eile gelesen werden . Wenn Sie ein Binärformat erfinden, sind Sie von einer ganzen Welt gut verständlicher und benutzerfreundlicher Werkzeuge abgeschnitten. Schwerwiegender Funktionsverlust, wenn Sie ihn brauchen.

Die meisten Protokollierungsumgebungen gehen einen Kompromiss ein: Halten Sie die aktuellen Protokolle lesbar und präsent und komprimieren Sie die älteren. Das bedeutet, dass Sie den Vorteil der Komprimierung erhalten - mehr noch, weil ein Binärformat die Protokollnachrichten nicht verkleinern würde. Gleichzeitig können Sie weniger und grep usw. verwenden .

Welche möglichen Vorteile ergeben sich aus der Verwendung von Binärdateien? Ein wenig Raumeffizienz - zunehmend unwichtig. Weniger (oder kleiner) schreibt? Nun, vielleicht - tatsächlich hängt die Anzahl der Schreibvorgänge von der Anzahl der Festplatten-Commits ab. Wenn also die Protokollzeilen erheblich kleiner als die Festplattenblockgröße sind, würde eine SSD ohnehin immer wieder neue Blöcke zuweisen. Binär ist also eine geeignete Wahl, wenn:

  • sie schreiben große Mengen strukturierter Daten
  • die Protokolle müssen besonders schnell erstellt werden
  • es ist unwahrscheinlich, dass Sie sie unter "Supportbedingungen" analysieren müssen.

dies klingt jedoch weniger nach Anwendungsprotokollierung. Dies sind Ausgabedateien oder Aktivitätsdatensätze. Das Einfügen in eine Datei ist wahrscheinlich nur einen Schritt vom Schreiben in eine Datenbank entfernt.

EDIT

Ich denke, hier gibt es eine allgemeine Verwechslung zwischen "Programmprotokollen" (gemäß Protokollierungsframeworks) und "Datensätzen" (wie in Zugriffsprotokollen, Anmeldedatensätzen usw.). Ich vermute, dass die Frage am engsten mit letzterer zusammenhängt, und in diesem Fall ist das Thema weit weniger genau definiert. Es ist durchaus akzeptabel, dass ein Nachrichtendatensatz oder ein Aktivitätsprotokoll in einem kompakten Format vorliegt, insbesondere da es wahrscheinlich genau definiert ist und eher zur Analyse als zur Fehlerbehebung verwendet wird. Zu den Tools, die dies tun, gehören tcpdump und der Unix-Systemmonitor sar. Programmprotokolle hingegen sind in der Regel viel ad hocer.

36
SusanW

Ein Beispiel für ein etwas binäres Protokoll ist weit verbreitet: das Windows-Ereignisprotokoll. Auf der Pro-Seite ermöglicht dies, dass Protokollnachrichten praktisch ohne Kosten ziemlich wortreich (und damit hoffentlich hilfreich) sind, möglicherweise so etwas wie

Warnung: Die Warteschlange der zu erledigenden Foobars ist in den letzten 90 Sekunden um 517 Elemente gewachsen. Wenn dies ungefähr einmal pro Tag passiert, gibt es keinen Grund zur Sorge. Wenn dies häufiger oder schnell hintereinander geschieht, möchten Sie möglicherweise die Menge an RAM, die für die foobar-Anwendung verfügbar ist) überprüfen. Wenn dies zusammen mit dem Ereignis 12345 auftritt, verwenden Sie anscheinend eine Veraltete Datenbank und Sie rufen besser den Support unter + 1-555-12345 an, um Datenverlust zu vermeiden.

Der Hauptteil dieser Nachricht ist nur einmal als mit der Anwendung installierte Ressource vorhanden. Wenn diese Ressource jedoch nicht korrekt installiert ist (z. B. weil inzwischen eine neuere Version installiert wurde, die diese veraltete Nachricht nicht mehr unterstützt), sehen Sie im Ereignisprotokoll nur eine Standardnachricht, für die nur eine ausgefallene Formulierung vorliegt

Keine Ahnung, etwas mit "517" und "90".

und in keiner Weise mehr hilfreich.

9

TL; DR: Die Größe spielt keine Rolle, aber die Benutzerfreundlichkeit

Während der Vergleich der jeweiligen Vorteile von Text- und Binärformaten für die kurzfristige Protokollspeicherung eine wichtige Frage ist, spielt die Größe keine Rolle. Die zwei Gründe dafür sind:

  1. Protokolle sind hochredundante Informationen, die sich sehr gut komprimieren lassen: Nach meiner Erfahrung werden komprimierte Protokolldateien, deren Größe 5% oder weniger der Größe der Originaldatei beträgt, nicht selten angezeigt. Folglich sollte die Verwendung eines Textes oder eines Binärformats keine messbaren Auswirkungen auf die Langzeitspeicherung von Protokollen haben.

  2. Unabhängig vom gewählten Format füllen Protokolle schnell eine Serverfestplatte, wenn wir keine „Protokolldateisenke“ implementieren, die Protokolldateien komprimiert und an eine Langzeitspeicherplattform sendet. Die Verwendung eines Binärformats könnte dies etwas verlangsamen, aber selbst eine Änderung um den Faktor 10 wäre nicht so wichtig.

Text versus binäre Protokollformate

Das Versprechen von Unix-Systemen ist, dass, wenn wir lernen, das Standard-Toolset für Textdateien zu verwenden, die in Zeilen strukturiert sind - wie grep , sort , join , sed und awk - wir werden sie verwenden können, um schnell Prototypen zusammenzubauen, die jeden gewünschten Job ausführen, wenn auch langsam und grob. Sobald der Prototyp seine Nützlichkeit bewiesen hat, können wir ihn in eine wirklich ausgereifte Software umwandeln, um die Leistung zu steigern oder andere nützliche Funktionen hinzuzufügen. Dies ist zumindest nach meinem Verständnis die Essenz der Unix-Philosophie.

Anders ausgedrückt: Wenn wir wahrscheinlich Behandlungen und Analysen durchführen müssen, die wir bis heute nicht herausfinden können, wenn wir nicht wissen, wer diese Analyse usw. durchführen soll, befinden wir uns in der Phase, in der Prototypen und Textformate verwendet werden sollten Protokolle sind wahrscheinlich optimal. Wenn wir wiederholt eine kleine Anzahl gut identifizierter Behandlungen durchführen müssen, befinden wir uns in der Situation, in der wir ein mehrjähriges Softwaresystem entwickeln sollten, um diese Analyse durchzuführen, und es ist wahrscheinlich, dass binäre oder strukturierte Formate für Protokolle wie relationale Datenbanken vorliegen optimal.

(Vor einiger Zeit habe ich ein Blogpost darüber geschrieben.)

Die beiden Hauptfragen, die Sie stellen möchten, bevor Sie zwischen Text und Binär wählen, sind:

  • Wer ist mein Publikum?
  • Welche Inhalte muss ich vermitteln?

Eine verbreitete Meinung ist, dass das Publikum einer Protokollnachricht ein Mensch ist. Dies ist offensichtlich keine perfekte Annahme, da es viele Protokolle zum Crawlen von Protokollen gibt, aber es ist eine häufige. In diesem Fall ist es sinnvoll, die Informationen in einem Medium zu vermitteln, mit dem Menschen vertraut sind. Text hat eine lange Tradition als dieses Medium.

Beachten Sie, dass ein binäres Protokoll muss ein genau definiertes Format hat. Das Format muss so definiert sein, dass andere Benutzer Software schreiben können, die diese Protokolle verarbeitet. Einige Protokolle sind recht gut strukturiert (Ihre Frage listet mehrere auf). Andere Protokolle benötigen die Fähigkeit, Inhalte in einer weniger genau definierten natürlichen Sprachform zu vermitteln. Solche Fälle in natürlicher Sprache passen schlecht zu Binärformaten.

Für die Protokolle, die in Binärform gut beschrieben werden könnten, müssen Sie eine Auswahl treffen. Da Text für alle funktioniert, wird er häufig als Standardauswahl angesehen. Wenn Sie Ihre Ergebnisse in Text protokollieren, können Personen mit Ihren Protokollen arbeiten. Es wurde tausende Male bewiesen. Binärdateien sind schwieriger. Infolgedessen kann es sein, dass Entwickler Text einfach ausgeben, weil jeder weiß, wie sich das verhalten wird.

5
Cort Ammon

Protokolldateien liegen im Textformat vor, da sie mit jedem Texteditor oder durch Anzeigen des Inhalts über den Konsolenbefehl leicht gelesen werden können.

Einige Protokolldateien haben jedoch das Format binär, wenn viele Daten vorhanden sind. Das Produkt, an dem ich arbeite, speichert beispielsweise maximal 15000 Datensätze. Um die Datensätze auf kleinstem Raum zu speichern, werden sie binär gespeichert. Es muss jedoch eine spezielle Anwendung geschrieben werden, um die Datensätze anzuzeigen oder in ein Format zu konvertieren, das verwendet werden kann (z. B. Tabellenkalkulationen).

Zusammenfassend sind nicht alle Protokolldateien im Textformat. Das Textformat hat den Vorteil, dass keine benutzerdefinierten Tools zum Anzeigen des Inhalts erforderlich sind. Wenn viele Daten vorhanden sind, kann die Datei im Format binär vorliegen. Das Binärformat benötigt eine (benutzerdefinierte) Anwendung, um die Daten zu lesen und in einem für Menschen lesbaren Format anzuzeigen. Weitere Daten können in ein Binärformat gepackt werden. Ob das Textformat oder das Binärformat verwendet wird, hängt von der Datenmenge und der einfachen Anzeige des Inhalts ab.

4
Thomas Matthews

Eine beschädigte Textdatei ist weiterhin um den beschädigten Teil herum lesbar. Eine beschädigte Binärdatei kann wiederhergestellt werden, ist es aber möglicherweise auch nicht. Selbst wenn es restaurierbar ist, würde es viel mehr Arbeit erfordern. Der andere Grund ist, dass ein binäres Protokollierungsformat es weniger wahrscheinlich macht, dass während eines Rushs beim Erstellen eines "temporären Fixes" (auch bekannt als "der dauerhafteste aller Fixes") die Protokollierungslösung verwendet wird, anstatt etwas, das schneller erstellt werden kann.

3

In eingebetteten Systemen, in denen zur Laufzeit möglicherweise kein Ausgabekanal verfügbar ist, kann sich die Anwendung den durch die Protokollierung verursachten Geschwindigkeitstreffer nicht leisten, oder die Protokollierung würde den Effekt, den ich aufzuzeichnen versuche, häufig ändern oder maskieren Es wurde darauf zurückgegriffen, Binärdaten in ein Array oder einen Ringpuffer zu stopfen und sie entweder am Ende des Testlaufs zu drucken () oder sie roh zu speichern und einen Interpreter zu schreiben, um sie als lesbar zu drucken. In jedem Fall möchte ich lesbare Daten erhalten.

Warum sollten Sie in Systemen mit mehr Ressourcen Schemata erfinden, um zu optimieren, was nicht optimiert werden muss?

3
JRobert

Protokolldateien sollen das Debuggen von Problemen unterstützen. In der Regel ist der Festplattenspeicher viel billiger als die Engineering-Zeit. Protokolldateien verwenden Text, da es viele Tools zum Arbeiten mit Text gibt (z. B. tail -f). Sogar HTTP verwendet Klartext (siehe auch warum senden wir keine Binärdateien anstelle von Text auf http ).

Darüber hinaus ist es billiger, ein Nur-Text-Protokollierungssystem zu entwickeln und zu überprüfen, ob es funktioniert, das Debuggen bei Fehlern zu vereinfachen und nützliche Informationen wiederherzustellen, falls das System ausfällt und einen Teil des Protokolls beschädigt.

3
Casey Kuball

In der Vergangenheit waren Protokolle offizielle, handgeschriebene und sequentielle Aufzeichnungen von Ereignissen. Als Maschinen in der Lage waren, Ereignisse aufzuzeichnen, wurden diese auf ein gedrucktes Ausgabegerät wie einen Teletypdrucker geschrieben, der eine permanente sequentielle Aufzeichnung erzeugte, aber nur Text verarbeiten konnte und gelegentlich eine Glocke läutete ...

2
Chris_F

In meinen Mainframe-Tagen haben wir ein benutzerdefiniertes binäres Protokollformat verwendet. Der Hauptgrund war nicht, Platz zu sparen, sondern weil wir wollten, dass das Protokoll endlichen Platz einnimmt, indem alte Einträge durch neue überschrieben werden. Das Letzte, was wir wollten, war, dass wir Probleme, die durch das Ausfüllen der Festplatten verursacht wurden, nicht diagnostizieren konnten (1980 kostete der Speicherplatz 1000 US-Dollar pro MB, sodass die Leute nicht mehr kauften, als sie brauchten).

Jetzt mag ich immer noch die Idee einer kreisförmigen Protokolldatei, und wenn Betriebssysteme ein solches Biest anbieten würden, würde ich sie ohne zu zögern verwenden. Aber binär war eine schlechte Idee. Sie möchten wirklich keine Zeit damit verschwenden müssen, die richtigen Befehle zum Entschlüsseln einer Protokolldatei zu finden, wenn Sie ein kritisches Problem lösen müssen.

2
Michael Kay

Wir verlassen uns auf Unit-Tests, um die Robustheit unserer Software zu erreichen und aufrechtzuerhalten. (Der größte Teil unseres Codes wird kopflos auf einem Server ausgeführt. Die Analyse von Protokolldateien nach dem Betrieb ist eine Schlüsselstrategie.) Nahezu jede Klasse in unserer Implementierung führt eine Protokollierung durch. Ein wichtiger Teil unserer Unit-Tests ist die Verwendung von Scheinloggern, die beim Unit-Test verwendet werden. Ein Komponententest erstellt einen Scheinlogger und stellt ihn dem zu testenden Objekt zur Verfügung. Anschließend wird (wenn nützlich/angemessen) analysiert, was protokolliert wurde (insbesondere Fehler und Warnungen). Die Verwendung eines textbasierten Protokollformats erleichtert dies aus den gleichen Gründen wie die Analyse von "echten" Protokollen erheblich: Es stehen Ihnen weitere Tools zur Verfügung, die schnell verwendet und angepasst werden können.

2
Art Swri