seit unserem Update von Check_MK 2.0.0p31 auf 2.1.0p21 haben wir bei der Überwachung der Oracle-Datenbanken das Problem, dass alle asynchron ausgeführten Sektionen von mk_oracle keine Daten mehr liefern.
Im Verzeichnis /var/lib/check_mk_agent/cache werden die entsprechenden Cache-Files zwar angelegt, jedoch bleiben sie leer:
/var/lib/check_mk_agent/cache # ls -la oracle_d*
-rw-r--r-- 1 root root 0 Mar 1 11:29 oracle_dbname.cache.new.166750
-rw-r--r-- 1 root root 0 Mar 1 11:29 oracle_dbname.cache.new.166881
In der Gui bleiben die entsprechenden Checks dann stale.
Es scheint, als ob die Cache-Files nicht sauber angelegt werden. Wenn ich die betroffenen Sektionen synchron aufrufe (./mk_oracle -s “tablespaces,rman”) werden die Daten sauber angezeigt. Wenn ich das alte mk_oracle Version 2.0.0p31 nach /usr/lib/check_mk_agent/plugins kopiere funktioniert es auch wieder sauber.
Hat jemand eine Idee, wo hier das Problem liegen könnte?
Wir hatten dazu ja schon geschrieben, für alle anderen mitlesenden:
Das Werk beschreibt eigtl. nur einen Workaround, wir haben aktuell einen Support-Case offen um zu klären, ob es eine elegantere Variante gibt, wie Plugins doch noch ihren eigenen Cache-Mechanismus nutzen dürfen und trotzdem Synchron laufen können.
Super, vielen Dank. Für die kritischen und verfügbarkeitsrelevanten Checks sind wir vorerst wieder zu check_oracle-health gewechselt. Das läuft nach wie vor sehr gut
Ich würde sagen ist definitiv Gerhards Meisterwerk
Uns in unseren Landschaften allerdings viel zu umständlich und zu viel gefrickel - auch wenn es eine Hand voll Punkte/Details gibt, welche das mk_oracle so nicht kann.
Primär stört uns aber nur der Agent in Kombination mit mk_oracle und entstehende timeouts, weil der Agent leider immer noch nicht Sektionen parallel Sektionen ausführen kann
Auf alle Fälle. Und läuft störungsfrei seit Jahren.
Wir haben uns von check_oracle_health nie wirklich verabschiedet. Wir hatten uns vor ein paar Jahren mal mit Erweiterungswünschen fürs mk_oracle über Tribe29 an den Autor von mk_oracle gewandt, allerdings wurden diese abgeschmettert weswegen wir bei vielen Checks bei der altbewährten Lösung geblieben sind.
Der asynchrone Lauf von mk_oracle ist bei vielen unserer Oracle-Server nur eine Krücke, gerade dort, wo die Abarbeitung der synchron ausgeführten Sektionen schon deutlich mehr als eine Minute dauert…
Wir haben teilweise 30 DBs auf einem Server.
Man kann im mk_oracle eine Parallelisierung einstellen. Dann läuft das ganze Plugin so langsam wie die langsamste DB. Das geht bei uns sehr gut.
Allerdings müssen wir auf Tablespace verzichten da teilweise bis zu 30k+ Services pro Host.
Was grundsätzlich OK ist, aber da kann die GUI von CMK nicht mithalten, bzw der Browser nicht, weil jede Spalte in der CMK GUI einzeln gerendert wird. (grau/weiss/grau/weiss - pro Service)
Das waren 3 oder 4 Sachen, ich müßte mal in meinen alten Mails stöbern. In Erinnerung ist mir jedoch geblieben, dass unser Wunsch nach der Prüfung, ob Flashback für die DB eingeschaltet ist, als nicht sinnvoll abgetan wurde.
