[Errno 28] No space left on device

Moin Community,

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.

Dazu folgendes:

4.0K    sites/instanz/var/check_mk/acknowledged_bp_tests.mk
4.0K    sites/instanz/var/check_mk/acknowledged_werks.mk
8.0K    sites/instanz/var/check_mk/agent_deployment
231M    sites/instanz/var/check_mk/agents
1.5M    sites/instanz/var/check_mk/autochecks
456K    sites/instanz/var/check_mk/background_jobs
4.0K    sites/instanz/var/check_mk/backup
813M    sites/instanz/var/check_mk/core
1.5M    sites/instanz/var/check_mk/crashes
4.0K    sites/instanz/var/check_mk/disabled_packages
16K     sites/instanz/var/check_mk/discovered_host_labels
1.8M    sites/instanz/var/check_mk/inventory
27M     sites/instanz/var/check_mk/inventory_archive
188K    sites/instanz/var/check_mk/inventory_delta_cache
8.0K    sites/instanz/var/check_mk/ipaddresses.cache
76K     sites/instanz/var/check_mk/license_usage
1.6M    sites/instanz/var/check_mk/logwatch
56K     sites/instanz/var/check_mk/notify
12K     sites/instanz/var/check_mk/packages
12K     sites/instanz/var/check_mk/persisted
24K     sites/instanz/var/check_mk/persisted_sections
4.0K    sites/instanz/var/check_mk/precompiled
5.5M    sites/instanz/var/check_mk/precompiled_checks
4.0K    sites/instanz/var/check_mk/report_schedule.py
8.0K    sites/instanz/var/check_mk/reports
47G     sites/instanz/var/check_mk/rrd
2.7M    sites/instanz/var/check_mk/snmp_cache
4.0K    sites/instanz/var/check_mk/snmpwalks
4.0K    sites/instanz/var/check_mk/stored_passwords
4.0K    sites/instanz/var/check_mk/update_config
6.2M    sites/instanz/var/check_mk/wato
952K    sites/instanz/var/check_mk/web
48G     total

und

12M     sites/instanz/var/mkeventd/history
43G     sites/instanz/var/mkeventd/messages
48K     sites/instanz/var/mkeventd/status
43G     total

Über Hilfe bin ich sehr dankbar.

Grüße
Nico

Hallo,
wie hast du die Appliance konfiguriert?
Per default oder hast du die Plattengrössen angepasst.
Gruß

Hey,

das hat meine Kollegin gemacht aber ich sehe das es 2 Festplatten sind, einmal mit 4Gb und 100Gb. Ich schätze mal das wäre dann default?

Grüße

Ich kenne diese Verzeichnis gar nicht. Was ist denn da drin?

Sollen von der Event Console selber direkt Mails verschickt werden und das geht aus irgendeinem Grund nicht und diese Verzeichnis füllt sich?

1 Like

Hier könntet Ihr prüfen, ob alte Daten (von nicht mehr überwachten Hosts) gelöscht werden können.

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ß

Moin,

ein kleiner Auszug:

62M     1649023200.log
70M     1649109600.log
75M     1649196000.log
61M     1649282400.log
56M     1649368800.log
33M     1649455200.log
30M     1649541600.log
68M     1649628000.log
255M    1649714400.log
385M    1649800800.log
235M    1649887200.log
188M    1649973600.log
153M    1650060000.log
162M    1650146400.log
193M    1650232800.log
289M    1650319200.log
306M    1650405600.log
287M    1650492000.log
248M    1650578400.log
211M    1650664800.log
227M    1650751200.log
258M    1650837600.log
254M    1650924000.log
240M    1651010400.log
233M    1651096800.log
197M    1651183200.log
161M    1651269600.log
70M     1651356000.log
293M    1651442400.log
393M    1651528800.log
398M    1651615200.log
412M    1651701600.log
380M    1651788000.log
319M    1651874400.log
329M    1651960800.log
391M    1652047200.log
405M    1652133600.log
424M    1652220000.log
439M    1652306400.log
420M    1652392800.log
376M    1652479200.log
378M    1652565600.log
394M    1652652000.log
378M    1652738400.log
375M    1652824800.log
379M    1652911200.log
369M    1652997600.log
345M    1653084000.log
341M    1653170400.log
356M    1653256800.log
324M    1653343200.log
333M    1653429600.log

Grüße

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?

Grüße

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.

Gruß

Michael

Ich habe dazu noch einen KB gefunden, der aber glaube ich nicht wirklich hilft:
https://kb.checkmk.com/display/KB/No+space+left+on+device+or+filesystem+full

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?

Grüße

Du hast “eine” Regel die Dir was berichtet.
Das bedeutet aber nicht, das zig Server Syslogs schicken :wink:
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 :frowning: )
In der EC würde ich mir eine “Drop any” Regel anlegen die alle Nachrichten die nicht auf eine Regel matchen gelöscht werden.

Ich hoffe das hilft

Gruß

Michael

1 Like

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. :frowning:
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.

Grüße

Holzhammer-Methode: tcpdump (oder ngrep) auf dem Monitoring-Server und schauen ob/was von der fraglichen Client-IP auf Port 514/udp (üblicherweise) reinkommt.

2 Likes

Genau.
Und mal schauen ob in omd config der mkeventd läuft und auf syslog lauscht. Für Deine Windows Maschinen brauchst Du den mkeventd garnicht.

Gruß

Michael

2 Likes

Moin,

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.

Grüße
Nico