Warum wird das Dateisystem für Protokolle anstelle von RDBMS bevorzugt?


44

Die Frage sollte aus dem Titel hervorgehen. Beispielsweise speichert Apache seine Zugriffs- und Fehlerprotokolle in Dateien anstelle von RDBMS, unabhängig davon, wie groß oder klein sie verwendet werden.

Für RDMS müssen wir nur SQL-Abfragen schreiben, und dies erledigt die Arbeit, während wir für Dateien ein bestimmtes Format festlegen und dann Regex schreiben müssen oder Parser sein müssen, um sie zu manipulieren. Und diese könnten unter bestimmten Umständen sogar scheitern, wenn nicht viel Sorgfalt aufgewendet würde.

Dennoch scheint jeder das Dateisystem für die Verwaltung der Protokolle zu bevorzugen. Ich bin gegen keine dieser Methoden voreingenommen, möchte aber wissen, warum dies so praktiziert wird. Ist es Geschwindigkeit oder Wartbarkeit oder etwas anderes?


10
Wie würden Sie DB-Fehler protokollieren (z. B. nicht verfügbare Datenbank), wenn sich Ihr Protokollierungssystem bei einer DB anmeldet?
Marjan Venema

17
@ Marjan Wie würde ich Dateisystemfehler protokollieren, wenn es fehlschlägt ?!
Yasir

5
Richtig, aber wenn dies fehlschlägt, ist Ihre Datenbank wahrscheinlich auch nicht erreichbar. Wo und wie würde sie ohne das Dateisystem in ihre Tabellen schreiben?
Marjan Venema

2
@ Yasir: Senden Sie alle Protokollnachrichten an einen Syslog-Server, bevor Sie sich im Dateisystem anmelden :)
Brian

1
@MarjanVenema das was wenn spiel sinnlos ist. Was passiert, wenn die lokale Festplatte voll ist, Ihre Protokollierung fehlschlägt, aber App und Betriebssystem können weitermachen. Wenn Sie sich auf einem entfernten DB-Server anmelden, können Sie sich trotzdem anmelden. Es gibt Vor- und Nachteile für das Speichern von Protokollnachrichten. Welche davon am besten geeignet ist, hängt davon ab, was Sie aus der Protokollierung herausholen möchten. Tut mir leid, ich lasse die Herde zurück zum Dateiprotokoll gehen, das ist der einzig wahre Weg.
Andy

Antworten:


37
  1. Zu viele Dinge können mit der Datenbank fehlschlagen, und es ist auch wichtig, diese Fehler zu protokollieren.

  2. Sofern Sie kein Datenbanksystem haben, das autonome Transaktionen (oder überhaupt keine Transaktionen) zulässt, erfordert die Protokollierung eine separate Verbindung, sodass ein Rollback oder ein Commit bei der Protokollierung das Rollback oder das Commit in der Anwendung nicht beeinträchtigt.

  3. Viele Dinge, die es wert sind, protokolliert zu werden, passieren beim Start, dh möglicherweise bevor die Datenbankverbindung hergestellt wurde.

  4. In einer typischen Konfiguration wird jeden Tag eine neue Protokolldatei erstellt, alte Protokolldateien werden komprimiert und 2 Wochen lang aufbewahrt, bevor sie schließlich gelöscht werden. In einem RDBMS ist es nicht einfach, dasselbe zu tun.


1
Ich habe dieses Experiment ausprobiert und es lief nicht gut. RDBMS basiert auf der Idee, dass Daten relativ selten im Verhältnis zur Anzahl der Lesevorgänge geschrieben werden. Protokollierung ist im Grunde das Gegenteil. Sie schreiben die ganze Zeit und lesen selten. Dies ist eine großartige Möglichkeit, Ihren DBA zu ärgern.
JimmyJames

1
Es kann jedoch in Betracht gezogen werden, ein Zeitreihen-Datenbanksystem wie InfluxDB zu verwenden, um Protokolle zu führen. es scheint mir, dass es ein bisschen besser für die Aufgabe geeignet ist als zum Beispiel PostgreSQL. Der Vorteil gegenüber altmodischen Logfiles ist jedoch kaum vorhanden.
user281377

Die Verwendung einer nicht relationalen Datenbank mit Token-Indizierung usw. ist auf jeden Fall nützlich, und wenn Sie mit Bedacht auswählen, können sie mit dem Feuerwehrschlauch umgehen. Dies ist ein Teil der Funktionsweise von Splunk und Flume.
JimmyJames

# 4 ist eigentlich kein Problem. DELETE FROM dbo.Log WHERE LogDate < today minus 2 weeks
Robert Harvey

@RobertHarvey Dies funktioniert gut, bis Sie es in einer Umgebung mit hoher Last versuchen, in der solche Massenvorgänge ohne zusätzliche Vorsichtsmaßnahmen schwerwiegende Probleme verursachen können. Redo-Protokolle füllen Ihren Speicherplatz, machen den zu vollen Tablespace rückgängig, die Replikation wird sehr beschäftigt mit dem Replizieren des Löschvorgangs usw.
user281377

16

Ich habe bereits zuvor in die Datenbank geschriebene Protokolle gesehen (und manchmal erhalten Sie konfigurierbare Optionen für die Protokollierung, bei der die Ablaufverfolgung in eine Datei verschoben wird, Fehler in die Datenbank, Fatale in das Windows-Ereignisprotokoll).

Die Hauptgründe dafür sind Geschwindigkeit und Größe. Wenn Sie diese Option aktivieren, kann die Ablaufverfolgung zu einer enormen Anzahl von Protokolldateien führen. Ich habe die Größe von Protokolldateien in Gigabyte durchgesehen. Der andere Hauptgrund ist, dass das Lesen der Protokolle sequentiell sein muss, es besteht keine wirkliche Notwendigkeit, das Protokoll abzufragen, außer um einen bestimmten Fehler oder Eintrag zu finden - und die Suche in der Datei funktioniert perfekt.


Aber ich habe eine Verwirrung dafür. Mein Notizblock, Wordpad, Gedit oder Notepad ++ oder jeder andere Webbrowser ist nicht erfreut, eine Datei mit einer Größe von 4 GB zu öffnen. Derselbe Browser kann mir jedoch eine Liste mit Tausend Seiten mit jeweils 500 gedruckten Datensätzen anzeigen. Richtig?
Yasir

7
@Yasir, weil Sie Editoren verwenden, die versuchen, die gesamte Datei in den Speicher zu laden. Versuchen Sie, einen intelligenteren Editor zu verwenden, der in der Lage ist, die große Datei zu "streamen". Vim ist ein gutes Beispiel.
nakhli

6
@ Yasir: Das stimmt, aber Sie versuchen, das Falsche zu optimieren. In den allermeisten Fällen werden Protokolle geschrieben und nie gelesen. Sie erstellen also sehr schnell Protokolle, da dies häufig der Fall ist.
Unholysampler

5
Eh, ich habe bereits zuvor in der Datenbank protokolliert, und die Protokollnachrichten einfach abzufragen war äußerst vorteilhaft, insbesondere, wenn die Protokollierung auf Debug-Ebene aktiviert wurde, um einen schwer zu replizierenden Fehler aufzuspüren.
Andy

2
@gbjbaanb Ich fand es nicht überbewertet, und ehrlich gesagt schlagen Sie vor, mit Markierungslinien und Ausschneiden und Einfügen abzufragen, ist ein Witz. Es wird nicht nur gesucht, sondern es werden Trends analysiert, um Server zu finden, die mehr Probleme als andere hatten, welche Art von Fehlern Benutzer am häufigsten sahen usw.
Andy

15

Geschwindigkeit ist ein Grund; andere sind:

  • Fehlerstellen beseitigen. Ein Dateisystem fällt selten unter Bedingungen aus, unter denen ein DBMS nicht ausfällt, aber es gibt sehr viele Fehlerbedingungen in Datenbanken, die in Dateisystemen einfach nicht existieren.
  • Low-Tech-Zugänglichkeit. Wenn die Dinge wirklich sehr, sehr schlecht laufen, können Sie eine Rettungsshell starten oder die Festplatte auf einem anderen System bereitstellen und verfügen dennoch über geeignete Tools zum Überprüfen von Protokolldateien. Wenn es sich um eine Datenbank handelt, kann kein Datenbankserver ausgeführt werden.

3

Zuerst.

Und diese könnten unter bestimmten Umständen sogar scheitern, wenn nicht viel Sorgfalt aufgewendet würde.

Datenbanktransaktionen können nicht fehlschlagen, wenn Sie nicht vorsichtig sind?

Das Schreiben in eine Textdatei hat eine Reihe von Vorteilen, von denen der wichtigste ist

  • Text ist für Menschen lesbar. Jeder kann eine Protokolldatei mit einem einfachen Texteditor öffnen und die Nachrichten anzeigen. Sie müssen nicht wissen, wie die Datenbank organisiert ist.
  • Geschwindigkeit. Das Schreiben von Text auf einen Datenträger ist viel schneller als ein Datenbankdienst, der feststellt, wo sich der Text in einer Datenbank befindet, dort schreibt und sicherstellt, dass die Transaktion abgeschlossen ist.

Natürlich kann alles und jedes scheitern, wenn wir nicht aufpassen. Aber für diese Frage bezog ich mich auf einen High-Level-Programmierer. Als einfaches Beispiel möchte der Programmierer möglicherweise Werte durch ein bestimmtes Zeichen trennen. Sein regulärer Ausdruck funktioniert also wie ein Zauber, schlägt jedoch fehl, wenn dasselbe Zeichen in einem Werteblock enthalten ist. Auf diese Weise muss er sich um ähnliche mögliche Fälle kümmern, und er muss nicht über sie nachdenken, wenn er in der DB spart. Kannst du bitte meinen Kommentar zur Antwort von gbjbaanb sehen?
Yasir

1
Und wenn Sie Ihre SQL von Hand schreiben, haben Sie das gleiche Problem. Der Unterschied besteht darin, dass das Schreiben fehlschlägt (oder Ihre Daten beschädigt), anstatt einige Entwickler leicht zu ärgern, weil sein Suchtext einige schlechte Ergebnisse erbracht hat. Ja, es gibt Frameworks, die bedeuten, dass Sie kein SQL schreiben müssen, aber jede zusätzliche Ebene verlangsamt den Prozess. Und denken Sie daran, dies ist nur die Protokollierung. Jeder Zyklus, mit dem Sie protokollieren, ist ein Zyklus, mit dem Sie nicht wirklich arbeiten.
Unholysampler

@unholysampler Ihr Leistungsargument ist schwach. Die Protokollierung kann sehr schnell und in einem Hintergrund-Thread in einer Datenbank durchgeführt werden, und die Protokollierung in den Fs, während sie möglicherweise noch schneller sind, ist ebenfalls nicht kostenlos, insbesondere wenn sie nicht im Hintergrund durchgeführt werden.
Andy

2

Sie erheben Apache spezifisch, also werde ich dies im Detail besprechen.

Apache kann so konfiguriert werden, dass es sich bei einer Datenbank anmeldet, obwohl dazu ein externes Plugin erforderlich ist . Die Verwendung eines solchen Plugins kann die Protokollanalyse vereinfachen, jedoch nur, wenn Sie beabsichtigen, eine eigene Protokollanalysesoftware zu schreiben. Standardmäßige Protokollanalysatoren gehen davon aus, dass sich Ihre Protokolle in Dateien befinden, sodass Sie diese nicht verwenden können.

Dabei traten auch Zuverlässigkeitsprobleme auf: Wenn der Schreibpuffer des Datenbankservers voll ist (was bei mysql passieren kann, wenn Sie Ihr Dateisystemkontingent für den Benutzer verwenden, unter dem es ausgeführt wird), werden Abfragen in die Warteschlange gestellt, bis sie in der Lage sind Ab diesem Zeitpunkt wartet Apache darauf, dass der Vorgang abgeschlossen wird, was dazu führt, dass Anfragen an Ihre Website hängen bleiben.

(Dieses Problem kann jetzt natürlich behoben werden - das habe ich vor vielen Jahren getan.)


1

Ein Dateisystem ist eine Datenbank. Es ist zwar eine einfachere, hierarchische Datenbank anstelle eines relationalen DBMS, aber es ist dennoch eine Datenbank.

Der Grund, warum die Protokollierung in einem Dateisystem beliebt ist, liegt darin, dass Textprotokolle gut zur Unix-Philosophie passen: "Text ist die universelle Schnittstelle."

Unix hatte mit vielen Allzweckwerkzeugen entwickelt, die gut mit Textprotokollen zusammenarbeiten können. Es spielt keine Rolle, ob die Textprotokolle von MySQL, Apache, Ihrer benutzerdefinierten Anwendung oder Software von Drittanbietern erstellt werden. Der Sysadmin kann Standard-Unix-Tools wie grep, sed, awk, sort, uniq, cut, tail verwenden usw, um trotzdem die Protokolle zu durchsuchen.

Wenn sich jede App in einer eigenen Datenbank anmeldet, eine in MySQL, eine andere in Postgres, eine andere in Elasticsearch, eine andere in ELK, eine andere kann sich nur in MongoDB anmelden, dann müssten Sie zwanzig verschiedene Tools erlernen, um die Protokolle von jeder zu durchsuchen Anwendung. Text ist ein universelles Medium, auf das sich jeder einloggen kann.

Selbst wenn Sie es schaffen, dass alle Protokolle in einer einzigen Datenbank abgelegt werden, beispielsweise in MySQL, möchten Sie möglicherweise von jeder Anwendung unterschiedliche Tabellenschemata verwenden. Daher müssen Sie immer noch ein benutzerdefiniertes Tool schreiben, um die Protokolle für jede Datenbank abzufragen Anwendung. Und wenn Sie alle Anwendungen irgendwie überlastet haben, um sich in einem einzelnen Schema anzumelden, werden Sie wahrscheinlich feststellen, dass dieses generische Schema Ihnen nicht wirklich die gesamte Geschichte jeder Anwendung erzählen kann, sodass Sie die Protokolltexte trotzdem analysieren müssen.

Die Protokollierung in einer Datenbank macht die Arbeit in der Praxis oft nicht wirklich einfacher.

Die Protokollierung in einer Datenbank kann hilfreich sein, wenn Sie eine bestimmte Analyse im Auge haben oder eine bestimmte Anforderung an die Aufbewahrung von Audits haben, für die Sie ein bestimmtes Datenbankschema entwerfen können, um nur die Daten für diese bestimmten Zwecke zu erfassen. Für die Forensik und das Debuggen sowie für das Erfassen von Protokollen ohne bestimmte Zielsetzung sind Textprotokolle in der Regel so gut, dass sich die Kosten für das Erlernen oder Erstellen der speziellen Tools häufig nicht lohnen.


0

Schauen wir uns das auf ein paar Ebenen an:

  1. Maschinenschicht
  2. Betriebssystemschicht
  3. Service-Schicht
  4. Anwendungsschicht

In Kürze:

  • Auf der Maschinenebene können Sie wirklich nur eine Art von Speicherauszügen protokollieren.
  • Auf der Betriebssystemebene können Sie protokollieren, es steht jedoch nur das Dateisystem zur Verfügung.
  • Dienste können sich im Dateisystem anmelden, aber sie können nicht darauf vertrauen, dass andere Dienste ausgeführt werden, sodass sie sich dort nicht anmelden können.
  • Anwendungen können sich bei Diensten und im Dateisystem anmelden.

Dann haben wir den Use-Case-basierten Ansatz:

Möchten Sie knotenspezifische Fehler in einem horizontal skalierten RDBMS protokollieren, in dem Sie die zusätzliche Arbeit aufwenden müssen, um den Fehler eines bestimmten Knotens zu ermitteln, wenn Sie nur die Abdeckung für den einen Knoten öffnen und dort anzeigen können? Andererseits sollte sich Ihre Anwendung möglicherweise in einem RDBMS anmelden, um Fehler und Hinweise auf Anwendungsebene zu sammeln.

Was passiert, wenn das RDBMS sich selbst protokollieren muss, weil in die Datenbank nicht geschrieben werden kann?


-2

Komplexität. Durch Hinzufügen von RDBMS wird die Komplexität des gesamten Systems astronomisch erhöht. Die Fähigkeit, mit Komplexität umzugehen, ist das Wichtigste, was Programmierer von Quellcode-Produzenten unterscheidet.


1
Könnten Sie erläutern, was Sie unter Komplexität im Zusammenhang mit der Protokollierung in einer Datenbank im Vergleich zu einem Dateisystem verstehen? Nach meiner Erfahrung gab es in einem Geschäftsumfeld keinen signifikanten Unterschied in der Komplexität.
Adam Zuckerman

"Ja wirklich?" SqlLite erhöht die Komplexität astronomisch? Und während ein Webserver normalerweise keine Datenbank benötigt, verwenden viele LOB-Apps bereits eine, sodass dort überhaupt keine zusätzlichen Kosten anfallen.
Andy

@AdamZuckerman Natürlich erfordert jedes RDBMS Wartung, ist anfällig für Korruption, muss möglicherweise speziell optimiert werden, ist möglicherweise von einer schlechten Konfiguration betroffen, muss möglicherweise wiederhergestellt werden, bringt eigene Einschränkungen mit sich, hat eigene Abhängigkeiten, unterstützte Plattformen, Aktualisierungsprobleme, Fehler, Lizenzierung und so weiter .
noonex

@Andy in erster Linie ist SQLite kein RDBMS im klassischen Sinne - es ist "eingebettetes RDBMS". Und ja - wenn Sie SQLite für die Protokollierung benötigen, steigt die Komplexität erheblich.
Noonex

1
@noonex Sie können einfach willkürlich zwischen eingebetteten und vollständigen Servern unterscheiden, wenn dies bei RDBMS nicht der Fall ist. SqlLite bietet ACID-Konformität, worum es bei RDBMS wirklich geht. Und es erhöht die Komplexität sehr? Ich kann mir nur vorstellen, dass Sie nur an den einfachsten Anwendungen gearbeitet haben. Schließlich brauchte eine gute Arbeit, bei der ich meinen Standpunkt zu vielen LOB-Anwendungen völlig ignorierte, ohnehin eine Datenbank.
Andy

-4

Ist es Geschwindigkeit oder Wartbarkeit oder etwas anderes?

Geschwindigkeit.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.