Meine Firma betreibt eine Webseite auf der enorme Mengen von Logs anfallen. Wir können/wollen daher die Logs nicht in einer relationalen Datenbank ablegen, weil das zu langsam bzw. zu teuer (Hardware) wäre. Es sind auch keine komplizierten Abfragen geplant (eine contains-Textsuche reicht völlig aus). Wie gehen wir am besten mit den Logdaten um?
Eine Datenbank ist bei großen Datenmengen der bessere Speicherort. Die Tabellen werden nicht im Speicher gehalten solange nicht auf Sie lesen zugegriffen wird. Selbst dann werden nur einzelne Pages (ein Page ist ein kleiner Teil des Inhaltes einer Tabelle) geladen und im Speicher gehalten. Wenn ein Index auf den relevanten Spalten liegt, ist eine Abfrage in Millisekunden auch bei mehreren Gigabyte an Daten möglich ohne das auch nur ein Byte aus der Tabelle in den Speicher geladen werden müßte (auser natürlich die Pages diegebraucht werden um das Result zusammen zu bauen)
Als praktisches Beispiel, wir verwenden hier bei mir auf Arbeit eine Tabelle mit ~25 Millionen Einträge a ~8KB. Der Abruf auf unserem Testserver (Windows 2003-Server unterer Leistungsklasse mit 4GB Arbeitsspeicher) mit folgendem Statement "select * from tbl_MyTable where a_ID < 1000" braucht <1 Sekunde obwohl die Tabelle nicht im Speicher ist.
Auch wenn du keine Datenbank haben willst, ich würde einen zweitserver aufstellen (Hostserver eine zweite NIC einbauen) und dort via RSyslog die Daten empfangen von den Hauptservern. Somit ist das komplette Logging outsourced und es ist ein geringer Aufwand. Auf dem Webserver musst du natürlich über das Syslog System loggen, Apache macht das über Pipes, Lighttpd kann es per default und der IIS kann es über Snare. Logs auf dem Webserver zu belassen würde ich ab einer gewissen Anzahl an Kunden nicht mehr weil die IO des Hostsystems in die Knie gehen kann.
Ich würde wie meine Vorredner zu einer Textdatei greifen. Jeder Logeintrag sollte über einen Zeitstempel verfügen, sowie in seiner Meldung Aussagekräftig sein (z.B. ist eine Meldung wie "Der Kommandozeilenparameter xy ist unbekannt" ist besser als "Achtung Fehler"), das ist klar.
Darüber hinaus würde ich, wenn ich auf kein spezielles Loggingsystem eines Drittanbieters zurückgreifen möchte, folgende Punkte berücksichtigen:
Nur anonymisierte Daten speichern. Lieber eine User ID speichern als Username u.ä. ausgeben. Niemals Passwörter per Logdatei speichern.
Jeden Tag eine neue Logdatei erstellen
Die Logdateien beinhalten im Dateinamen das Datum, so dass diese sinnvoll sortiert angezeigt werden können
Jede Tag/Woche/Monat (abhängig davon wie schnell diese größer werden) sollten die neuen Logdateien mit einem Packprogramm gezippt werden. Am besten automatisch triggern.
Kopiere die Logdateien nach dem packen auf ein Backup-Laufwerk oder ähnliches. Ebenfalls Automatisch Triggern.
Die automatischen Prozesse oben sollten regelmäßig kontrolliert werden, am besten einen automatischen Report generieren, der wöchentlich/monatlich per Email darüber auskunft gibt wieviele Dateien gezippt wurden und ob die gleichen Dateien im Backupordner liegen
Last but not Least: Falls sinnvoll, regelmäßiges Löschen der Logfiles aus dem System und ggf. Backupordner.
Falls eine Langzeitarchivierung gefordert ist, dann den vorigen Punkt vergessen und statt dessen die Logfiles vom Backupsystem regelmäßig auf Datenträger kopieren.
Wenn ihr die Dateien nicht mit Windows betrachten wollt, würde ich ein Flatfileformat nehmen. Entsprechende Trennzeichen und ein kleines Script das alles schreibt und liest wäre schnell und einfach geschrieben.
Mit Log4Net ist es auch möglich, die Logereignisse über das Netzwerk an einen anderen zentralen Rechner zu schicken, um dort alle Logs gemeinsam zu sammeln. Das könnte dann in Form einer XML Datei geschehen.
Diese kann man dann auch sehr komfortable mit Log4View betrachten (ist allerdings kostenpflichtig)
Wenn es wirklich sehr große Logs sind, würde ich XML aber nicht empfehlen, da hier pro Logeintrag u.U. sehr viel redundante Daten anfallen. Beispiel: <log type="error">Errormessage</log> kann man sehr viel kürzer als: ERROR Errormessage speichern
Ich schließe mich den Vorrednern an. Noch zwei Tips aus eigener Erfahung:
1. Am schnellsten Text in Dateien bekommt man mit file_put_contents(). 2. Überlegt Euch ob Ihr Loglevels und/oder Tracelevels einführt, dann kann man einfacher über die Logfiles greppen. Bsp.: WARNING This is a warning log message. TRACE-4711 A log message from the component with trace level 4711. ...
Über das Loglevel lässt sich dann auch die Log-Aktivität einstellen. Bei neuen Systemen logge ich immer alles mit, wenn sie sich bewährt haben schalte ich das Loglevel runter und es werden nur noch reine Exceptions ausgegeben.
Mein Empfehlung wäre, schau dir mal die syslog Kommandos an. Der Dienst ist in fast jedem Linux / Unix System vorhanden und sehr mächtig. Zudem gibt es auch schon viele Tools die große Log Files packen und archivieren. Was ich nicht hundertprozentig weiß, ist wie der Dienst mit euer Datenflut zu recht kommt
...enorme Mengen von Logs anfallen. Wir können/wollen daher die Logs nicht in einer relationalen Datenbank ablegen, weil das zu langsam...
Sorry, aber für mich widerspricht sich dies alles. - Bei "enormen" Daten-Mengen eine Textdatei zu nehmen - ist eine Riesen-Datenbank langsamer als eine Text Datei?
Wo kommen die Logs her, wo gehen sie hin, und was steht ungefähr drin?