ich habe jetzt über Wochen beobachtet wie mir cmk sagt das /omd vollläuft und heute war es soweit das nichts mehr ging. Ich habe ein paar alte Versionen gelöscht und habe jetzt wieder Platz aber das wird demnächst wieder passieren. Nun die Frage was kann ich dagegen tun und warum passiert das, ich nutze die virtuelle Appliance mit der 2.1.0p10.
du -h —max-depth= X könnte helfen zu klären wo der Platz verbraucht wird.
Ist von der info her wie das Tool Treesizen unter Windows nur auf der Konsole.
Zur Not in eine Datei umleiten.
Gruß
Das pflege und hege ich, alles unnötige fliegt sofort raus. Die Cisco Catalyst, Nexus und VSS hauen dort richtig rein und bei 9300 Services, kann ich mir schon vorstellen das die 100GB nicht reichen. Kann ich denn die Festplatte vergrößern um das ich die 400 Tage abdecken kann?
Da sammeln sich all die Events aus der Event Console die nicht archiviert wurden.
Nach dem Archivieren verbleiben die Events für die “Event history lifetime” im Archiv (sites/instanz/var/mkeventd/history).
Siehe auch:
Wenn die Events benötigt werden dann muss wohl die Partition erweitert werden. Leider habe ich keien Kenntnis darüber ob das im laufenden Betrieb geht. Zumindest sehe ich keinen LVM auf der Appliance. Wenn Du einen Cluster hast könntem man evtl. den Standby Host neu aufsetzen und spiegeln, dann einen failover machen und dann das gleiche mit dem ehemaligen active Host.
Da sammeln sich die Events aus der EC? Ich habe genau 1 Server in der EC und der berichtet mir nur ob ein User im AD gesperrt wurde. Wie können dann die anderen Server etc. dort drin stehen? Kann ich mir das irgendwo anschauen?
Du hast “eine” Regel die Dir was berichtet.
Das bedeutet aber nicht, das zig Server Syslogs schicken
Guck mal in das “default” Package rein, was das macht.
Ich verwerfe darin alles was ich nicht gemeldet haben möchte, darum hat es bei mir auch den höchsten Count. Du hast einen Count von “0”.
Also erstmal der Reihe nach:
Zunächst schickt der Windows Agent per default alles aus den System Logs zu logwatch.
Das kann man auf dem Agenten beinflussen.
Dann kommt die Regel “Logwatch Event Console Forwarding” zum Tragen.
Da kann man u.A. auch auf den Hostnamen filtern.
Dann erst kommen die Regeln in der Event Console zum Einsatz.
Also, erstmal überlegen ob wirklich alle Hosts Ihre Logs zum Monitoring schicken müssen.
Dann überlegen ob alles an die Event Console geschickt werden muss. (ich rätsel gerade was mit den Nachrichten passiert die nicht an die EC weitergeleitet werden.??? Die bleiben ja dann im Logwatch hängen )
In der EC würde ich mir eine “Drop any” Regel anlegen die alle Nachrichten die nicht auf eine Regel matchen gelöscht werden.
Ah, stimmt ja, es geht um weitergeleitete Windows Events, die “Mühe” mache ich mir nicht. In der EC habe ich nur Syslog Nachrichten.
Die Windows Events verarbeite ich direkt.
Aber trotzdem, genau wie Michael schreibt, als letztes in der Default habe ich auch eine “Drop any”. Damit ist dann alles weg was vorher nicht explizit verarbeitet wurde.
Zunächst schickt der Windows Agent per default alles aus den System Logs zu logwatch.
Das kann man auf dem Agenten beinflussen.
Das habe ich gemacht.
Dann kommt die Regel “Logwatch Event Console Forwarding” zum Tragen.
Da kann man u.A. auch auf den Hostnamen filtern.
Dann erst kommen die Regeln in der Event Console zum Einsatz.
So habe ich das auch gemacht und das funktioniert auch soweit.
Also, erstmal überlegen ob wirklich alle Hosts Ihre Logs zum Monitoring schicken müssen.
Dann überlegen ob alles an die Event Console geschickt werden muss.
Nein das machen die nicht, ich habe nur 1 Windows Server im Monitoring und 2 Linux Clients aktuell. Der Rest sind SNMP Abfragen von CIsco Catalyst, Nexus und Co. Mir ist aber aufgefallen das im mkeventd Ordner die log Dateien Syslog Messages sind, zufällig hatte ich die von der Cisco ISE und das kann ich mir nun wirklich nicht erklären da ich kein Syslog mit dem mache… Ich musste nur eben die Instanz ausschalten da der Speicher wieder voll war und keine Abfrage mehr ihren Dienst tat und mein Postfach zugespamt hat.
Wie kriege ich raus ob das Syslog an ist, obwohl ich mir sicher bin das ich es nicht aktiviert habe denn dafür nutze ich etwas anderes.
Holzhammer-Methode: tcpdump (oder ngrep) auf dem Monitoring-Server und schauen ob/was von der fraglichen Client-IP auf Port 514/udp (üblicherweise) reinkommt.
Sorry das ich mich jetzt zurückmelde aber mich hatte Corona mal kurz aus dem Leben geschossen.
Es ist tatsächlich so das ich 2 Fehler gemacht habe. Zum einen war der Empfang auf der Instanz von Syslog Meldungen aktiv und zum anderen habe ich von den Cisco Geräten irgendwann beim testen, den CheckMK als Syslog hinterlegt. Das habe ich nun korrigiert und ich empfange nur noch die Meldungen vom AD.
Was aber tatsächlich noch zu Wissen wäre, ob man nachträglich die Festplattengröße ändern kann.
Das würde mich auch interessieren wie ich eine Festplatte vergrößern kann.
Im vcenter wurde die zweite HDD für den Mountpunkt /omd erweiter, aber wie erkläre ich das der Appliance?
Vm stoppen und sichern
2)
Snapshots löschen
3)
Platte im Vsphere Center vegrössern
4)
von einer aktuellen gparted CD booten
5)
Platte resizen
6)
neu starten
Klappt eigentlich immer ausser mit LVMs in Unterbau. btrfs bisher ungetestet und verschlüsselte Platten fasse ich auch nicht an.
Gruß