it-swarm.dev

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

Die Frage sollte aus dem Titel klar hervorgehen. Zum Beispiel speichert Apache seine Zugriffs- und Fehlerprotokolle in Dateien anstelle von RDBMS, unabhängig davon, wie groß oder klein es verwendet wird.

Für RDMS müssen wir nur SQL-Abfragen schreiben und es wird die Arbeit erledigen, während wir für Dateien ein bestimmtes Format festlegen und dann Regex schreiben müssen oder Parser sein können, um sie zu manipulieren. Und diese könnten unter bestimmten Umständen sogar scheitern, wenn keine große Sorgfalt angewendet würde.

Dennoch scheint jeder das Dateisystem für die Pflege der Protokolle zu bevorzugen. Ich bin nicht voreingenommen gegen eine dieser Methoden, aber ich würde gerne wissen, warum es so praktiziert wird. Ist es Geschwindigkeit oder Wartbarkeit oder etwas anderes?

44
Yasir
  1. Zu viele Dinge können mit der Datenbank fehlschlagen, und die Protokollierung dieser Fehler ist ebenfalls wichtig.

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

  3. Viele Dinge, die es wert sind, protokolliert zu werden, passieren während des Startvorgangs, d. H. Möglicherweise bevor die Datenbankverbindung hergestellt wurde.

  4. In einem typischen Setup 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.

38
user281377

Ich habe schon früher Protokolle gesehen, die in die Datenbank geschrieben wurden (und manchmal erhalten Sie konfigurierbare Optionen für die Protokollierung, bei denen die Ablaufverfolgung in die Datei geht, Fehler in die Datenbank, Fatale in das Windows-Ereignisprotokoll).

Die Hauptgründe sind Geschwindigkeit und Größe. Wenn Sie eine gewisse Ablaufverfolgung aktivieren, kann dies zu einer enormen Menge an Protokollierung führen. Ich habe Protokolldateien mit einer Größe von Gigabyte durchsucht. Der andere Hauptgrund ist, dass das Lesen der Protokolle sequentiell erfolgen muss. Es besteht keine wirkliche Notwendigkeit, das Protokoll abzufragen, außer um einen bestimmten Fehler oder Eintrag zu finden - und das Suchen in der Datei funktioniert perfekt dafür.

16
gbjbaanb

Geschwindigkeit ist ein Grund; andere sind:

  • Fehlerquellen beseitigen. Ein Dateisystem fällt selten unter Bedingungen aus, unter denen ein DBMS dies nicht tun würde, aber es gibt viele Fehlerbedingungen in Datenbanken, die in Dateisystemen einfach nicht vorhanden sind.
  • Low-Tech-Zugänglichkeit. Wenn die Dinge wirklich sehr, sehr schlecht laufen, können Sie eine Rettungs-Shell starten oder die Festplatte auf einem anderen System bereitstellen und haben immer noch geeignete Tools zum Überprüfen von Protokolldateien. Wenn es sich um eine Datenbank handelt, können Sie keinen Datenbankserver ausführen.
16
tdammers

Erst einmal.

Und diese könnten unter bestimmten Umständen sogar scheitern, wenn keine große Sorgfalt angewendet würde.

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

Das Schreiben in eine Textdatei bietet 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 sehen, was die Nachrichten sind. Sie müssen nicht verstehen, wie die Datenbank organisiert ist.
  • Geschwindigkeit. Das Schreiben von Text auf eine Disc ist viel schneller als ein Datenbankdienst, der herausfindet, wo sich der Text in einer Datenbank befindet, ihn dort schreibt und sicherstellt, dass die Transaktion abgeschlossen ist.
3
unholysampler

Sie sprechen Apache speziell an, daher 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 Protokollanalyse-Software zu schreiben. Standardmäßige Protokollanalysatoren von der Stange gehen davon aus, dass sich Ihre Protokolle in Dateien befinden, sodass Sie diese nicht verwenden können.

Als ich dies tat, 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 verbrauchen, unter dem es ausgeführt wird), werden Abfragen in die Warteschlange gestellt, bis sie in der Lage sind Um fortzufahren, beginnt Apache zu warten, bis es beendet ist, was zu blockierten Anfragen an Ihre Website führt.

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

2
Jules

Ein Dateisystem ist eine Datenbank. Es ist zwar eine einfachere, hierarchische Datenbank anstelle eines relationalen DBMS, aber es ist trotzdem 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 wurde mit vielen Allzweck-Tools entwickelt, die gut mit Textprotokollen funktionieren. Es spielt keine Rolle, ob die Textprotokolle von MySQL, Apache, Ihrer benutzerdefinierten Anwendung oder Software von Drittanbietern erstellt werden, die lange nicht unterstützt werden. Der Systemadministrator kann Standard-Unix-Tools wie grep, sed, awk, sort, uniq, cut, tail verwenden usw., um die Protokolle trotzdem zu durchsuchen.

Wenn sich jede App in einer eigenen Datenbank anmeldet, eine in MySQL, eine in Postgres, eine in Elasticsearch, eine andere in ELK, eine andere nur in MongoDB, dann müssen Sie zwanzig verschiedene Tools lernen, um die Protokolle der einzelnen zu durchsuchen Anwendung. Text ist ein universelles Medium, bei dem sich jeder anmelden kann.

Selbst wenn Sie es schaffen, dass alle Protokolle in einer einzigen Datenbank gespeichert werden, z. B. MySQL, werden Sie möglicherweise feststellen, dass jede Anwendung mit unterschiedlichen Tabellenschemata protokollieren möchte, sodass Sie immer noch ein benutzerdefiniertes Tool schreiben müssen, um die Protokolle für jedes Protokoll abzufragen Anwendung. Und wenn Sie irgendwie alle Anwendungen überfüllt haben, um sich in einem einzelnen Schema zu protokollieren, werden Sie wahrscheinlich feststellen, dass dieses generische Schema Ihnen nicht wirklich die ganze Geschichte jeder Anwendung erzählen kann, sodass Sie die Protokolltexte trotzdem analysieren müssen.

Die Protokollierung in einer Datenbank erleichtert die Arbeit in der Praxis häufig nicht wesentlich.

Die Protokollierung in einer Datenbank kann hilfreich sein, wenn Sie eine bestimmte Analyse im Auge haben oder bestimmte Anforderungen 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. Aber für Forensik und Debugging und wenn Sie Protokolle ohne bestimmte Ziele erfassen, sind Textprotokolle normalerweise so gut, dass sich die Kosten für das Erlernen oder Erstellen der speziellen Tools oft nicht lohnen.

1
Lie Ryan

Schauen wir uns das auf einigen Ebenen an:

  1. Maschinenschicht
  2. Betriebssystemschicht
  3. Serviceschicht
  4. Anwendungsschicht

In Kürze:

  • Auf der Maschinenebene können Sie wirklich keine andere Protokollierung als irgendeine Art von Speicherauszügen durchführen.
  • Auf der Betriebssystemebene können Sie protokollieren, aber Sie haben wirklich 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 zusätzliche Arbeit benötigen, um den Fehler eines bestimmten Knotens zu finden, wenn Sie einfach die Haube für den einen Knoten öffnen und dort anzeigen können? Andererseits sollte sich Ihre Anwendung möglicherweise bei einem RDBMS anmelden, um Fehler und Hinweise auf Anwendungsebene zu erfassen.

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

0
ojrask