Gibt es einen Grund dafür, dass die meisten Logs im Klartext zu stehen scheinen und nicht in einer MySQL / anderen Datenbank?
Es scheint mir, dass es sehr viel einfacher wäre, sie in eine Datenbank zu schreiben ... aber wäre das ein Opfer der Geschwindigkeit oder etwas anderes?
(Ich kümmere mich nicht um die Portabilität, und natürlich hätten Sie Textprotokolle für Ihre Datenbankverbindung.)
Ich kann mir zwei große Gründe vorstellen:
Erstens sind Datenbanken langsamer als Textdateien, wenn es darum geht, Informationen einfach an eine Datei anzuhängen. Bei einer Datenbank müssen Sie eine Verbindung herstellen, Daten über das Netzwerk übertragen, in einer indizierten Struktur speichern und so weiter. Bei einer Datei müssen Sie nur den Fehler auf die lokale Festplatte schreiben.
Zweitens gehören die Dinge, die Sie protokollieren möchten, manchmal dazu, dass die Datenbank beschädigt wird. Wenn der lokale Datenträger beschädigt ist, treten größere Probleme auf als wenn versucht wird, Protokolldateien zu generieren. Aber Sie können Datenbankausfälle auch dann protokollieren, wenn alles andere funktioniert.
Abgesehen davon gibt es viele Situationen, in denen die Informationen, die ich protokollieren möchte, nur relevant sind, solange die Anwendung ordnungsgemäß funktioniert und wenn ich bereits eine Datenbankverbindung habe. In diesen Fällen melde ich mich direkt bei MySQL an.
Obwohl Sie sich nicht mit Übertragbarkeit befassen, glaube ich, dass das ein großer Teil des Grundes ist. File I / O ist nahezu universell und mit einer äußerst konsistenten API. Weitere Vorteile sind:
Das heißt, es ist nichts falsch daran, sich bei einer Datenbank anzumelden, wenn die Art der App sich dafür eignet und ich viele Apps gesehen habe, die das tun.
In der Vergangenheit waren Datenbanken teuer, und Sie würden sicherlich niemals Ihre wertvollen Datenbanklizenzen für Protokolle verschwenden wollen. Datenbanken sind heutzutage jedoch relativ billig und werden auch verarbeitet. Die Verwendung einer Datenbank für Protokolle würde Sie wahrscheinlich nicht finanziell töten.
Der Vorteil einer Protokolldatei ist, dass Sie bis zum Ende weiterschreiben. Dies ist eine relativ effiziente Operation im Vergleich zur Verwendung eines Datenbankservers.
Der Vorteil einer Datenbank besteht darin, dass Sie Ihre Protokolldaten in Datenrelationen strukturieren können, die dann mit SQL analysiert werden können. Dies kann Ihnen einen guten Einblick in den Betrieb Ihrer Software geben.
Sie können das Beste aus beiden Welten nutzen, indem Sie SQLite als Protokolldatenbank verwenden. SQLite ist eine Bibliothek mit einer SQL-Engine, die Sie mit Ihrem Programm verknüpfen. Anstatt fopen / fwrite / fclose verwenden Sie die SQLite-API, um die Datenbank zu öffnen, SQL auszuführen und die Datenbank zu schließen. Es gibt keinen Datenbankserver, da die SQLite-Engine-Operationen im Prozess Ihrer Anwendung ausgeführt werden ... genau wie fopen / fwrite / fclose. Sobald Sie Ihre Daten in einer SQLite-Datenbank (alle in einer einfachen Datei gespeichert) erfasst haben, können Sie Ihre Log-Daten mit SQL analysieren. Schauen Sie sich Ссылка für ein Beispiel an.
-------- EDIT August 2010 ------------
Die Entwickler von SQLite haben die Writeahead-Protokollierung ab SQLite-Version 3.7.0 implementiert. Dies ermöglicht viel schnellere Schreibvorgänge. Weitere Informationen finden Sie dieses Video . Mit schnellerem Schreiben ist SQLite noch nützlicher als eine Protokollierungsdatenbank.
Datenbanken enthalten einen erheblichen Overhead in Bezug auf Speicher, Speicherplatz und Effizienz. Das Hinzufügen neuer Datensätze zu einer Datenbank oder das Ändern vorhandener Datensätze ist wesentlich langsamer. (Außerdem sind viele mit SQL und / oder den Besonderheiten beim Einrichten einer Datenbank nicht vertraut.)
Wenn Sie jedoch Analyse- oder Metrik-Evaluierungsfunktionen benötigen, die mit einer einfachen Textdatei nur schwer zu bekommen sind, dann ist daran sicherlich nichts falsch. Es ist sehr von Fall zu Fall.
(Andere haben bereits auf eine Reihe von Vorteilen bei der dateibasierten Protokollierung hingewiesen.)
Ich denke, die DB-Protokollierung wird bei der Erfassung von Protokollen auf einem Remotecomputer (z. B. über syslog / rsyslog unter Linux) für die Sicherung sinnvoller. Dies kann nützlich sein, wenn der ursprüngliche Computer kompromittiert und seine Protokolle geändert werden. Das Sammeln von Protokollen in einer Datenbank (möglicherweise insbesondere auf dem Remote-Computer) ist in diesem Fall nützlich, da dies beim Aussortieren dieser Protokolle hilfreich sein kann. Sie können die Protokolle auch bequemer über Tools wie phpLogCon durchsuchen oder sie mit benutzerdefinierten Webseiten durchsuchen (oft einfacher als Melden Sie sich an der Maschine an, wenn Sie nur eine zufällige Überwachung durchführen.)
Das heißt, Remote-Logging, Protokollierung in einer Datenbank und ein nettes Tool zum Durchsuchen der Logs sind ziemlich unabhängig (ich denke, dass phpLogCon auch mit Dateiprotokollen arbeiten kann). Wenn ich Protokolle in einem DB speichere, speichere ich auch gleichzeitig Protokolle in einer Datei, um nur lesen zu können, wenn die Verbindung zur Datenbank unterbrochen ist.
Es ist wichtig zu beachten, dass es keinen Grund gibt, dass Sie keine Logs in eine Datei schreiben können (was, wie andere bereits festgestellt haben, sehr schnell, effizient und robust ist) und dann die Daten in eine Datenbank auslagert andere Maschine), um eine Analyse durchzuführen, die durch typische Datenbankfunktionen beschleunigt wird. Dies ist natürlich möglich, da Protokolldaten normalerweise nicht sofort zerlegt werden müssen. Daher ist es sinnvoll, den gesamten Overhead und die Fragilität einer Datenbank so lange zu verschieben, bis sie benötigt wird.