Ich versuche das ganze hier mal in Form von Screenshots irgendwie nachvollziehbar zu machen:
-
Filtern der Events mit leerem Host und mit meiner “catchall syslog” regel, die greift wenn vorher nichts anderes erkannt wurde:
-
Aus irgendeinem Grund sind es 3 Commands (möglicherweise wegen mehrerer Slaves vom Distributed Monitoring):
-
Die Anzahl der Gesamt-Events geht von 1xxx auf 44 runter:
-
Die Events tauchen wieder sukzessive aus dem nichts auf:
Der hätte ja definitiv von dem Filter oben mitarchiviert werden müssen! -
Der nächste erscheint:
-
Einer geht noch…
In ~/var/log/mkeventd.log:
2023-10-12 19:13:33,042 [20] [cmk.mkeventd.StatusServer] Executing command: DELETE;181036,181034,181035,54520;simonmueller
2023-10-12 19:19:37,892 [20] [cmk.mkeventd.StatusServer] Executing command: DELETE;55297,55296,55268,55267,182855,182856,182857,182858;simonmueller
2023-10-12 19:20:08,376 [20] [cmk.mkeventd.StatusServer] Executing command: DELETE;55273,55274,55391,55388;simonmueller
2023-10-12 19:20:24,794 [20] [cmk.mkeventd.StatusServer] Executing command: DELETE;55903;simonmueller
2023-10-12 19:20:40,674 [20] [cmk.mkeventd.EventServer] Successfully forwarded notification for event 55925 to Check_MK
2023-10-12 19:23:41,044 [20] [cmk.mkeventd.EventServer] Successfully forwarded notification for event 55926 to Check_MK
2023-10-12 19:26:41,410 [20] [cmk.mkeventd.EventServer] Successfully forwarded notification for event 55927 to Check_MK
Die Events sind ja alle (Schnee) von gestern und sollten sowieso nicht mehr eintreffen. Möglicherweise weiß die Event Console durch diese unhandled exception bestimmte Dinge nicht, weil sie eben schon vor dem Moment aussteigt, bevor weitere Dinge passieren.
Sorry für die laxe Beschreibung, aber es ist natürlich viel einfacher nachzuvollziehen wenn man direkt an der Site administriert.
Jedenfalls wenn ich morgen Abend wieder reinschauen würde, dann wären vermutlich wieder alle anderen 1000 Events von diesem (nicht-existenten) Host (^$) da und die EC geht in ihre 1000er Schranke.