Logserver Logs ausrechnen

Hallo,

unter Linux ist es doch einfacher.
Einfach die der Log-Dateien kopieren, auf einen 1 Woche/Tag reduzieren und die Dateigröße anschauen.

Bevor Du das Rad neu erfindest schaut mal nach ELK-Stack.

Stefan

Hallo,
Ja, denn Logs unter Linux sind in 99% aller Fälle reine Textdateien.

z.B. /var/log/syslog

Schau auch mal bei rsyslog nach

Ich würde das ganze pragmatisch angehen.
Ein Unternehmen das 200 Server betreibt ist mit sehr hoher Wahrscheinlichkeit virtualisiert und hat auch entsprechenden Storage. Also würde ich dem Logserver einfach mal bspw 100 GB Storage verpassen und die Platte ans Monitoring hängen. Wenn der Platz knapp wird dann erweitern.
Nach sechs Monaten hast du den Platzbedarf der notwendig war. Dann würde ich mir Gedanken machen ob in dem Zeitraum evtl außergewöhnlich viel oder wenig geloggt wurde und daran dann den für die Zukunft notwendigen Platz plus Reserve fest machen.

Manuel

Ich habe mal sowas ähnliches mit LogAnalytics in Azure und Windows VMs gemacht. Ich meine alleine Event Logs (Warning/Critical) hat ca. 300-400mb pro Monat und Server ausgemacht.

Je nach Menge und Art der Events deiner Server könnten diese 3-400MB deine Ausgangslage sein.

300-400M je Server? Scheint mir extrem viel zu sein für Warning, Critical, kann's sein, dass das irgendwie alles nicht ganz rund lief?

Was mir nur noch am Rande einfällt: Bevor du jetzt losrennst mit "Ey, cheffe, ich hab da ne Idee, kost auch nich viel" (is ja unter Linux wirklich kostenlos möglich) mach dir Gedanken um etwas was viel wichtiger als der Storage ist:

WOFÜR das ganze? Wer guckt da drauf (und nicht die ersten 2 Wochen wo es noch neu ist und man denkt "oh geil, was da alles für zeilen laufen" sondern eben regelmässig? Welche Informationen WILLST du wissen?

Das eine ist ja die Installation - die geht recht schnell und kost auch ausser Zeit nicht viel. Wenn du aber die Frage nach dem Wer/Was/Warum nicht vorher vollständig beantwortet hast wirst du vermutlich in dieselben Probleme rennen wie du sie bei anderen Monitoring-Systemen hast: Man neigt dazu jeden Kram überwachen zu wollen und stellt am Ende fest das keiner sich für die 10.000 Werte die da auftreten interessiert und man erst beim Ausfall drauf guckt um zu sehen dass das Monitoring schon 2+ Wochen am heulen war. Mit dem Unterschied: Das MONITORING kann noch halbwegs aktiv handeln (Mail senden,...) - der Logserver kann das nicht weils auch nicht seine Aufgabe ist (du kannst natürlich die Logfiles als Mail senden - die dann per Regel automatisch abgelegt werden und keiner reinguckt - also auch nur Platzverschwendung).

Diese Punkte sollten also ganz oben auf deiner Liste fürs klären stehen. Natürlich: die ersten 2-4 Wochen guckst du nämlich selbst drauf weils "spannend" ist. Dann kommt irgendwann ein neues Projekt und diese Server landen in der Versenkung bis irgendwann in 3-4 Jahren sich jemand fragt wofür diese VM / dieser Server eigentlich war und warum der soviel HDD-Platz reserviert bekommen hat...

Storage ist günstiger als den Aufwand den du betreibst.

Außerdem ist es schwer zu "rechnen" ohne zu wissen, wie die Datenbank (Datentypen usw) die Daten speichert.

Stichwort: Unterschied z. B. datetime und datetime2 bei massenhafter Verwendung

Habt ihr Audit events aktiv bei Windows? Unsere haupt DCs kommen auf 3-5gb pro Tag.
Bei Windows hast du standardmäßig ein Limit von 25(?) Mb pro logfile/Kategorie und dann werden die ältesten Events überschrieben. Das logfile ist dann klein, aber du siehst nur paar Stunden/Tage...
Archivierung kannst aktivieren, aber pass auf, dass dir C: nicht volläuft.

SQL Server hatte mal ein Konfig Problem und hat 500gb logs geschrieben...

Will nicht behaupten das ist normal, nur als Beispiele.

Absolut korrekt.

Das wird aber so nix. Solang du eben nicht sagen kannst wer für den Server verantwortlich ist und wer die Logs (und wie) auswertet hast du einfach nur die Sicherheit reduziert. Du hast einen weiteren Server mit offenen Ports, eine weitere Software die mit hohen Rechten läuft (der Log-Daemon) und gesammelte Daten über div. Systeme die jedem Angreifer helfen würden.

Ich frage mal andersrum: Was bringt dir das dickste Türschloss mit noch 5 weiteren Ketten vor der Tür wenn niemals jemand guckt ob noch alles heile ist? Ich bin weder Einbrecher noch handwerklich besonders geschickt - aber wenn man mir verspricht das niemals jemand guckt und ich somit unbegrenzt Zeit habe komme selbst ich dann in jedes Gebäude rein... ERST wenn eben zwischendurch (zB 1x/Tag) jemand guckt würde ja was auffallen - und DANN wirds blöd für mich ;).

Von daher: Die SICHERHEIT erhöhst du mit dem Prozess, nicht mit einem zusätzlichen Server... Oder anders: Kläre erst das organisatorische, DANN das WIE. Es kann ja am Ende sogar rauskommen das du rausfindest das deine Idee nicht schlecht ist, aber so nicht umsetzbar ist. Einfaches Beispiel: Du loggst einfach mal alles - dann KANN das eben auch in die Arbeitszeitüberwachung gehen (wenn du zB. meine Anmeldezeiten am Server protokollierst). Das ist technisch kein Problem, sollte aber durchaus mit den entsprechenden Fachleuten erstmal diskutiert werden ob das erlaubt ist. Denn eine solch kleine Sache kann dafür sorgen das am Ende DU am Ar... bist weil du illegal Daten gesammelt hast...

Moin,

ein zentrales Loggin ist die Basis für nachträgliche Auswertungen und ein Echtzeitmonitoring.
Sonst ist es nur ein Datengrab.

Ich habe für verschiedene Web-Projekte ein detailiersten Logging auf Basis eines ELK-Stacks für die letzten 14 Tage.
Damit erstelle ich wöchentlich analysen und schaue mir Auffälligkeiten an.

Dazu gibt es ein aktives Monitoring was bei Störungen und Auffälligkeiten sofort Alarm schläge.

Stefa

Mit was machst du das? Wir hatten da früher MS ATA, aber das ist am Auslaufen oder schon EoL. Außerdem waren die Alerts oft nicht so hilfreich (ev. auch zu wenig Erfahrung unsererseits...)

Sg Dirm