Logserver Logs ausrechnen
Hallo Zusammen,
Ich bin gerade dabei einen zentralen Logserver für meine Firma einzurichten (würde sagen kleines bis mittleres Unternehmen). 200 Server, 300 Netzwerkkomponenten. Alle gerade genannten Komponenten sollen an den zentralen Logserver gehangen werden. Die Logs sollen für 6 Monate vorgehalten werden. Ich mache es mir glaube ich gerade zu kompliziert wie ich das ausrechnen kann. Bei den Windows Servern gibt es eine Ereignisanzeige. Dort würde ich alle Files nach den letzten 24 Stunden filtern und mir dann die Größe des Ordners anschauen. Ein Kollege sagte mir ich sollte den ganzen Logordner über Tage beobachten und dann den Durchschnitt davon nehmen, jedoch ist das meiner Meinung nach für einen Zeitraum von 6 Monaten nicht aussagekräftig. Nun kommen wir zum schwierigen Teil. Nämlich den Linux Servern. Würdet ihr dort ebenfalls in den Logordner schauen und den Durchschnitt nehmen? Bin noch in der Ausbildung und bekomme von meinem Chef und meinen Kollegen nicht wirklich Hilfe was das Thema anbelangt.
Mit freundlichen Grüßen
Leonie
Ich bin gerade dabei einen zentralen Logserver für meine Firma einzurichten (würde sagen kleines bis mittleres Unternehmen). 200 Server, 300 Netzwerkkomponenten. Alle gerade genannten Komponenten sollen an den zentralen Logserver gehangen werden. Die Logs sollen für 6 Monate vorgehalten werden. Ich mache es mir glaube ich gerade zu kompliziert wie ich das ausrechnen kann. Bei den Windows Servern gibt es eine Ereignisanzeige. Dort würde ich alle Files nach den letzten 24 Stunden filtern und mir dann die Größe des Ordners anschauen. Ein Kollege sagte mir ich sollte den ganzen Logordner über Tage beobachten und dann den Durchschnitt davon nehmen, jedoch ist das meiner Meinung nach für einen Zeitraum von 6 Monaten nicht aussagekräftig. Nun kommen wir zum schwierigen Teil. Nämlich den Linux Servern. Würdet ihr dort ebenfalls in den Logordner schauen und den Durchschnitt nehmen? Bin noch in der Ausbildung und bekomme von meinem Chef und meinen Kollegen nicht wirklich Hilfe was das Thema anbelangt.
Mit freundlichen Grüßen
Leonie
Please also mark the comments that contributed to the solution of the article
Content-ID: 5011716800
Url: https://administrator.de/contentid/5011716800
Printed on: December 3, 2024 at 08:12 o'clock
17 Comments
Latest comment
Du wirst es nicht anders können als deine Server anzusehen. Dabei solltest du aber - zumindest bei Linux als Logserver - im Kopf haben das man via Logrotate natürlich die Files auch automatisch kompremieren kann. Und das ist bei Text-Files natülich recht effektiv.
Die andere Sache wäre für mich: In Zeiten von TByte-Platten würde mich das beim reinen Logserver weniger sorgen ;)
Die andere Sache wäre für mich: In Zeiten von TByte-Platten würde mich das beim reinen Logserver weniger sorgen ;)
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
Ja, denn Logs unter Linux sind in 99% aller Fälle reine Textdateien.
z.B. /var/log/syslog
Dec 18 00:00:11 server2201 systemd[1]: logrotate.service: Deactivated successfully.
Dec 18 00:00:11 server2201 systemd[1]: Finished Rotate log files.
Dec 18 00:00:11 server2201 systemd[1]: logrotate.service: Consumed 3.370s CPU time.
Dec 18 00:00:12 server2201 postfix/smtpd[2133839]: disconnect from unknown[141.98.0.0] ehlo=1 auth=0/1 quit=1 commands=2/3
Dec 18 00:00:17 server2201 postfix/smtpd[2134088]: warning: hostname poppopprision.com does not resolve to address 141.98.0.0
Dec 18 00:00:17 server2201 postfix/smtpd[2134088]: connect from unknown[141.98.0.0]
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
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
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...
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
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.
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.
Zitat von @Linux09:
Das ganze soll als Projekt dienen, damit wir mal eines unserer offenen Sicherheitsziele erfüllen können und dementsprechend die Stadtverwaltung sicherer wird.
Das ganze soll als Projekt dienen, damit wir mal eines unserer offenen Sicherheitsziele erfüllen können und dementsprechend die Stadtverwaltung sicherer wird.
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
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
Zitat von @Dirmhirn:
Mein Hosting ist primär für Linux-Webserver. Dort nutze ich StatusCake, Site24x7 und eine eigene Software.Dazu gibt es ein aktives Monitoring was bei Störungen und Auffälligkeiten sofort Alarm schläge.
Mit was machst du das?Beim IT Bereich das RMM von N-Able (ex Solarwinds, ex GFI MAXX) und eine eigene Software.
Stefan