Datenarchitektur für Ereignisprotokollmetriken?

Mein Dienst hat eine große Anzahl von Benutzerereignissen, und wir möchten Dinge wie "Zählen des Auftretens des Ereignistyps T seit Datum D " ausführen .

Wir versuchen zwei grundlegende Entscheidungen zu treffen:

1. Was soll man aufbewahren? Speichern jedes Ereignisses oder nur Speichern von Aggregaten

   • (Ereignisprotokollstil) Protokolliere jedes Ereignis und zähle sie später, vs.
   • (Zeitreihenstil) Speichern Sie eine einzelne aggregierte "Anzahl von Ereignissen E für Datum D " für jeden Tag

2. Wo sollen die Daten gespeichert werden?

   • In einer relationalen Datenbank (insbesondere MySQL)
   • In einer nicht relationalen (NoSQL) Datenbank
   • In Flatlog-Dateien (zentral über das Netzwerk gesammelt syslog-ng)

Was ist die Standardpraxis / wo kann ich mehr über den Vergleich der verschiedenen Systemtypen lesen?

Zusätzliche Details:

• Der gesamte Ereignisstrom ist groß, möglicherweise Hunderttausende von Einträgen pro Tag
• Derzeit müssen wir jedoch nur bestimmte Arten von Ereignissen zählen
• Wir benötigen nicht unbedingt Echtzeitzugriff auf die Rohdaten oder Aggregationsergebnisse

IMHO ist "Alle Ereignisse in Dateien protokollieren, sie zu einem späteren Zeitpunkt crawlen, um den Stream zu filtern und zu aggregieren" ein ziemlich standardmäßiger UNIX-Weg, aber meine Rails-y-Landsleute scheinen zu glauben, dass nichts real ist, es sei denn, es ist in MySQL.

Es kommt immer darauf an, ich gebe dir meinen Rat, dir eine neue Perspektive zu bieten

Was soll man aufbewahren? Speichern jedes Ereignisses oder nur Speichern von Aggregaten

(Ereignisprotokollstil) Protokolliere jedes Ereignis und zähle sie später, vs.

Wenn Sie vorhaben, keine Details auszulassen, obwohl diese für mich jetzt nicht relevant sind, ist dies aus meiner Sicht der beste Ansatz, da Sie manchmal, wie die Ergebnisse zeigen, einige andere Ereignisse finden, die für X oder Y nicht relevant waren , oder sie brachten keine zusätzlichen Informationen mit, aber nach einer Analyse ist dies einfach der Fall, und Sie müssen auch diese nachverfolgen. Dann würde es einige Zeit dauern, bis Sie sie dem Bild hinzufügen können, da sie zwar aufgezeichnet, aber nicht berücksichtigt wurden .

(Zeitreihenstil) Speichern Sie eine einzelne aggregierte "Anzahl von Ereignissen E für Datum D" für jeden Tag

Wenn Sie es morgen implementieren und verwenden möchten, kann es funktionieren, aber wenn Sie dann neue Anforderungen haben oder eine Korrelation mit einem anderen Ereignis finden, das Sie aus irgendeinem Grund ausgelassen haben, müssen Sie dieses neue Ereignis hinzufügen und dann einige warten lange Zeit schöne Aggregationsebenen zu haben

Wo sollen die Daten gespeichert werden?

In einer relationalen Datenbank (insbesondere MySQL)

Die erste Option kann für eine Datenbank schwierig sein, wenn Sie alle Ereignisse aufzeichnen möchten. Aus diesem Grund kann MySQL leider zu klein werden. Wenn Sie sich für RDBMS-Lösungen entscheiden, denken Sie möglicherweise an größere Lösungen wie PostgreSQL oder proprietäre Lösungen wie Oracle oder DB2 .

Aber für die Aggregation wäre eine gute Wahl, abhängig von der erzeugten Last können Sie im Code aggregieren und diese Aggregationen in die DB einfügen.

In einer nicht relationalen (NoSQL) Datenbank

Wenn Sie sich für diese Lösung gehen, müssen Sie sehen , welche nähern Sie nett folgen wollen Read auf wikipedia Sie können helfen, kann ich Ihnen nicht viel zu diesem Thema helfen , weil ich einfach nicht genug Erfahrung haben, ich meistens RDBMS verwenden.

In flachen Protokolldateien (zentral über das Netzwerk über Syslog-ng gesammelt)

Ich persönlich würde Sie davon abhalten, diese Option zu wählen. Wenn die Datei zu groß wird, ist das Parsen schwieriger, aber ich kenne den Hauptzweck immer noch nicht, nämlich ein System zu überwachen oder einfach ein Protokoll zu überprüfen Datei ...

Ich hoffe es hilft!

Ich denke, dass Ihre Idee, Protokolle zu analysieren, zu zählen und Ergebnisse in einer DB zu speichern, gültig ist. Ich bin mir nicht sicher, ob Sie all diese unformatierten Protokolle in der Datenbank haben möchten (ich denke, das haben Ihre Landsleute vorgeschlagen). Sie haben bereits die Protokolle in Dateien, richtig? Sie könnten diese einfach archivieren. Ich nehme an, dass dieses Bit wirklich von Ihren Anwendungsfällen abhängt.

Stimmen Sie auch @ Thorbjørn Ravn Andersen zu, wenn Sie Ihre "Kommentarantwort" auf die Frage verschieben.

Hängt von Ihrer beabsichtigten Verwendung ab. Wenn Sie ein Standarddiagramm oder einen Standardbericht mit aggregierten Werten haben, möchten Sie die Ereignisse einfach filtern, sobald sie eingehen, und sie in den entsprechenden Bereich aggregieren. Wenn Sie einen Drilldown zu bestimmten Ereignissen durchführen müssen oder wenn Sie der Meinung sind, dass Sie Ereignisse später erneut analysieren / neu kategorisieren möchten, sollten Sie die einzelnen Ereignisse speichern.

Wenn Sie Zeit und Raum haben, möchte ich normalerweise die Daten aggregieren, aber die Details in einer (komprimierten) Datei speichern. Die Details müssen nicht leicht zugänglich sein, da ich sie so gut wie nie brauche, sie stehen jedoch zur erneuten Verarbeitung in großen Mengen zur Verfügung, wenn sich die Klassifizierungskriterien ändern.

Jede Architekturentscheidung sollte von den geschäftlichen Anforderungen bestimmt werden. In Ihrem Fall sollten Sie eine genauere Vorstellung davon haben, welche Informationen Sie von Ihrem Protokollsystem erhalten möchten und wie diese Informationen gespeichert werden sollen, wie oft Sie sie benötigen und wie lange Sie auf das Ergebnis warten können . Dies ist die Grundlage für das Design von Protokollkollektoren, Ereigniskorrelatoren und ähnlichen Anwendungen.

Anstatt Ihnen meine Meinung mitzuteilen, schlage ich vor, dass Sie sich einige Anwendungen ansehen, die denen ähneln, die Sie zu entwickeln versuchen. Einige von ihnen sind möglicherweise viel leistungsfähiger als das, was Sie vorgeben zu entwickeln, aber es schadet nicht, wenn Sie sich die Architektur und die Speicherrichtlinien ansehen, die befolgt werden. Auf der professionellen Seite haben Sie SIEM-Anwendungen wie RSA und Arcsight und auf der Open Source-Seite Initiativen wie Kiwi oder OSSIM (die auch eine professionelle Appliance-basierte Version haben).

Wenn Sie mit der Verwendung der mit dem Tool erzielten Ergebnisse beginnen, erhalten Sie mit hoher Wahrscheinlichkeit viele Anfragen Ihres Managements nach mehr und detaillierteren Informationen. Also ... benutze es vorsichtig und plane mit deinem Blick in den Horizont. Es kann Ihnen mehr Arbeit geben, aber auf jeden Fall erhalten Sie viel Unterstützung und Sichtbarkeit (Druck ist im Paket enthalten) ....