Es ist sicherlich in einer Vielzahl von Methoden machbar. Ich werde jede aufgelistete Option sowie einige zusätzliche Kommentare ansprechen.
1) Wenn NGinx das kann, lass es. Ich mache es mit Apache sowie JBOSS und Tomcat. Diese sammle ich dann zentral mit syslog-ng und verarbeite sie von dort aus. Für diese Route würde ich ein durch Trennzeichen getrenntes Protokollnachrichtenformat vorschlagen, z. B. tabulatorgetrennt, da es einfacher zu analysieren und zu lesen ist. Ich weiß nicht, ob es PHP-Variablen protokolliert, aber es kann sicherlich Header und Cookie-Informationen protokollieren. Wenn Sie überhaupt NGinx-Protokollierung verwenden, würde ich nach Möglichkeit diese Route empfehlen - warum zweimal einloggen?
2) Es gibt keine "mangelnde Möglichkeit, das Datum nachträglich abzufragen", mehr unten.
3) Dies ist eine Option, aber ob sie nützlich ist oder nicht, hängt davon ab, wie lange Sie die Daten behalten und wie viel Bereinigung Sie schreiben möchten. Mehr unten.
4) MongoDB könnte sicherlich funktionieren. Sie müssen die Abfragen schreiben, und es handelt sich nicht um einfache SQL-Befehle.
Nun zum Speichern der Daten in redis. Ich protokolliere derzeit Dinge mit syslog-ng wie angegeben und verwende ein Programmziel, um die Daten zu parsen und in Redis zu stopfen. In meinem Fall habe ich mehrere Gruppierungskriterien, z. B. nach vhost und nach Cluster, daher können meine Strukturen etwas anders sein. Die Frage, die Sie sich zuerst stellen müssen, lautet:"Welche Daten möchte ich aus diesen Daten herausholen?" Einige davon werden Zähler wie Verkehrsraten sein. Einige davon werden Aggregate sein, und noch mehr Dinge wie "Meine Seiten nach Beliebtheit sortieren".
Ich werde einige der Techniken demonstrieren, um dies einfach in Redis zu bekommen (und somit wieder herauszunehmen).
Betrachten wir zunächst die Statistiken über den Datenverkehr im Laufe der Zeit. Entscheiden Sie sich zunächst für die Granularität. Möchten Sie Statistiken pro Minute oder reichen stündliche Statistiken aus? Hier ist eine Möglichkeit, den Verkehr einer bestimmten URL zu verfolgen:
Speichern Sie die Daten in einem sortierten Satz mit dem Schlüssel „traffic-by-url:URL:YYYY-MM-DD“. zum Beispiel in Python, wo "r" Ihre Redis-Verbindung ist:
r.zincrby("traffic-by-url:/foo.html:2011-05-18", "01:04",1)
Dieses Beispiel erhöht den Zähler für die URL "/foo.html" am 18. Mai um 1:04 Uhr morgens.
Um Daten für einen bestimmten Tag abzurufen, können Sie zrange auf dem Schlüssel (""traffic-by-url:URL:YYYY-MM-DD") aufrufen, um einen sortierten Satz von den am wenigsten beliebten bis zu den beliebtesten zu erhalten. Um die Top 10 zu erhalten , zum Beispiel würden Sie zrevrange verwenden und ihm den Bereich geben. Zrevrange gibt eine umgekehrte Sortierung zurück, die meisten Treffer stehen oben. Mehrere weitere sortierte Set-Befehle sind verfügbar, mit denen Sie nette Abfragen wie Paginierung, get a Bereich der Ergebnisse nach Mindestpunktzahl usw..
Sie können Ihren Schlüsselnamen einfach ändern oder erweitern, um verschiedene zeitliche Fenster zu handhaben. Indem Sie dies mit zunionstore kombinieren, können Sie automatisch weniger granulare Zeiträume zusammenfassen. Beispielsweise könnten Sie alle Schlüssel in einer Woche oder einem Monat zusammenführen und in einem neuen Schlüssel wie "traffic-by-url:monthly:URL:YYYY-MM" speichern. Indem Sie das Obige für alle URLs an einem bestimmten Tag ausführen, können Sie täglich erhalten. Natürlich könnten Sie auch einen Schlüssel für den täglichen Gesamtverkehr haben und diesen erhöhen. Es hängt hauptsächlich davon ab, wann die Daten eingegeben werden sollen - offline über den Logfile-Import oder als Teil der Benutzererfahrung.
Ich würde davon abraten, während der eigentlichen Benutzersitzung viel zu tun, da dies die Zeit verlängert, die Ihre Benutzer benötigen, um es (und die Serverlast) zu erfahren. Letztendlich wird dies ein Anruf sein, der auf Verkehrsaufkommen und Ressourcen basiert.
Wie Sie sich vorstellen können, kann das obige Speicherschema auf alle zählerbasierten Statistiken angewendet werden, die Sie möchten oder bestimmen. Ändern Sie beispielsweise die URL in die Benutzer-ID, und Sie haben eine Nachverfolgung pro Benutzer.
Sie können Protokolle auch roh in Redis speichern. Ich mache das für einige Protokolle, die sie als JSON-Strings speichern (ich habe sie als Schlüssel-Wert-Paare). Dann habe ich einen zweiten Prozess, der sie herausholt und Dinge mit den Daten macht.
Zum Speichern von Rohtreffern können Sie auch sortierte Sätze mit der Epochenzeit als Rang verwenden und mit den Befehlen zrange/zrevrange einfach ein Zeitfenster abrufen. Oder speichern Sie sie in einem Schlüssel, der auf der Benutzer-ID basiert. Sätze würden dafür funktionieren, ebenso wie sortierte Sätze.
Eine weitere Option, die ich nicht besprochen habe, die aber für einige Ihrer Daten nützlich sein kann, ist das Speichern als Hash. Dies könnte beispielsweise nützlich sein, um detaillierte Informationen über eine bestimmte Sitzung zu speichern.
Wenn Sie die Daten wirklich in einer Datenbank haben möchten, versuchen Sie es mit der Pub/Sub-Funktion von Redis und haben Sie einen Abonnenten, der sie in ein getrenntes Format parst und in eine Datei ausgibt. Führen Sie dann einen Importprozess durch, der den Kopierbefehl (oder ein Äquivalent für Ihre DB) zum Massenimport verwendet. Ihre Datenbank wird es Ihnen danken.
Ein letzter Rat hier (ich habe mir wahrscheinlich schon genug Zeit genommen) ist, den Expire-Befehl vernünftig und großzügig einzusetzen. Mit Redis 2.2 oder neuer können Sie das Ablaufdatum für gerade Zählerschlüssel festlegen. Der große Vorteil hierbei ist die automatische Datenbereinigung. Stellen Sie sich vor, Sie folgen einem Schema, wie ich es oben skizziert habe. Durch die Verwendung der Ablaufbefehle können Sie alte Daten automatisch löschen. Vielleicht möchten Sie stündliche Statistiken für bis zu 3 Monate, dann nur die täglichen Statistiken; tägliche Statistiken für 6 Monate, dann nur monatliche Statistiken. Lassen Sie einfach Ihre stündlichen Schlüssel nach drei Monaten (86400*90), Ihre täglichen um 6 (86400*180) ablaufen und Sie müssen keine Bereinigung durchführen.
Für das Geotagging führe ich eine Offline-Verarbeitung der IP durch. Stellen Sie sich einen sortierten Satz mit dieser Schlüsselstruktur vor:„traffic-by-ip:YYYY-MM-DD“ unter Verwendung der IP als Element und unter Verwendung des oben erwähnten Zinkryby-Befehls erhalten Sie Pro-IP-Verkehrsdaten. Jetzt können Sie in Ihrem Bericht den sortierten Satz abrufen und nach der IP suchen. Um beim Erstellen der Berichte Datenverkehr zu sparen, können Sie in Redis einen Hash einrichten, der die IP dem gewünschten Ort zuordnet. Zum Beispiel „geo:country“ als Schlüssel und IP als Hash-Element mit Ländercode als gespeichertem Wert.
Eine große Einschränkung, die ich hinzufügen möchte, ist, dass Sie bei sehr hohem Datenverkehr möglicherweise zwei Instanzen von Redis (oder mehr, je nach Datenverkehr) ausführen möchten. Die erste wäre die Write-Instanz, bei der die bgsave-Option nicht aktiviert wäre. Wenn Ihr Verkehr ziemlich hoch ist, werden Sie immer einen bgsave durchführen. Dafür empfehle ich die zweite Instanz. Es ist ein Sklave des ersten und speichert es auf der Festplatte. Sie können Ihre Abfragen auch gegen den Slave laufen lassen, um die Last zu verteilen.
Ich hoffe, das gibt Ihnen einige Ideen und Dinge zum Ausprobieren. Spielen Sie mit den verschiedenen Optionen herum, um zu sehen, was für Ihre spezifischen Anforderungen am besten geeignet ist. Ich verfolge viele Statistiken auf einer stark frequentierten Website (und auch MTA-Protokollstatistiken) in Redis und es funktioniert hervorragend - in Kombination mit Django und der Visualisierungs-API von Google erhalte ich sehr gut aussehende Diagramme.
