Datenarchitektur für Ereignisprotokollmetriken?

17

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.

elliot42
quelle
1
Hast du Glück bei diesem Projekt?
Hiwaylon
2
@hiwaylon Am Ende haben wir ein Hybridsystem verwendet: 1) MySQL, wo immer dies möglich ist (geringes Volumen) (vereinfacht die Aggregation SELECT...GROUP BY, speichert problemlos die Ergebnisse von SELECTs), 2) Graphite für einfache Aggregation und Visualisierung in großem Maßstab und 3) Protokollieren vollständiger Ereignisse als Referenz und zum Beobachten von Details des Datenflusses in Echtzeit. Jedes war auf unterschiedliche Weise wertvoll.
Elliot42
Das klingt nach einer großartigen Lösung, ähnlich wie wir es auch tun.
Hiwaylon
1
UPDATE über ein Jahr später bauten wir ein System auf, das alles protokollierte, und iterierten in regelmäßigen Abständen über die Protokolle, um die gezählten Zahlen in einer Datenbank zu speichern (es hätte eine Zeitreihendatenbank sein können / sollen, aber MySQL reichte aus). Diese Arbeit dauerte einige Wochen, erwies sich jedoch als überraschend leistungsstarker und schneller Ansatz. Wenn nur Ihr Code über protokolliertes JSON iteriert, können Sie einfach viele Metadaten hinzufügen und Ihrem Code können flexible Regeln für genau das zugewiesen werden es will zählen.
Elliot42
1
Update 2016: Kafka kann diese Art von Dingen heutzutage zumindest für die rohe Lagerung. Dann können Sie sie entweder in einen großen MapReduce- oder Spark-Job stecken oder in ein großes Warehouse wie Vertica usw., wenn Sie sie abfragen / aggregieren möchten.
Elliot42

Antworten:

4

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!


quelle
1
Protokolldateien sollten nach Größe oder Länge gedreht werden. Ich denke nicht, dass die letzte Sorge dann ein Problem sein würde.
Hiwaylon
1

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.

hiwaylon
quelle
1

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.

TMN
quelle
msgstr "die Daten aggregieren, aber die Details in einer (komprimierten) Datei speichern". Großartiger Gedanke, insbesondere, danke!
Elliot42
Gibt es Bedenken hinsichtlich des Volumens der Protokollierung des OP und der Filterung und Aggregierung, wenn diese eingehen? Es scheint ein gefährlicher Engpass zu sein, wenn das Protokollvolumen hoch und / oder die Aggregation nicht trivial ist.
Hiwaylon
OP erwähnte Volumen von "Hunderttausenden von Ereignissen pro Tag". Eine Million Ereignisse pro Tag sind weniger als siebenhundert pro Minute oder ungefähr elf pro Sekunde. Sofern die Eingabe kein langwieriges XML ist, sollte Ihr durchschnittlicher Server in der Lage sein, dies zu verarbeiten, ohne ins Schwitzen zu geraten. Es ist jedoch definitiv etwas, das beim Entwerfen (und Bereitstellen) der Lösung berücksichtigt werden sollte.
TMN
1

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) ....

Picarus
quelle