Mk_oracle und Custom Queries

Hallo,

mit mk_oracle sind ja auch Custom Queries möglich welche das Plugin gegen die Instanzen ausführt und das Ergebnis über den Agent an die cmk Instanz abliefert.

Die Doku dazu ist leider übersichtlich, die manpage verweist auf das Plugin und dort sind nur die Optionen beschrieben, da komme ich aber irgendwie nicht klar. Ist nur ein SQL möglich oder gehen mehrere?
Hat hier jemand ein funktionierendes Beispiel?
Wir verwenden die Agent Bakery, welches ja mk_oracle.cfg erzeugt. In WATO lässt sich das nicht konfigurieren, wie bekomme ich die Inhalte rein ohne das sie überschrieben werden?

Edit: Hier stehen im Abschnitt 6 einige Infos. In bin durch den Link Custom SQLs for Oracle DBs in der Intoducion direkt falsch abgebogen.
Verbesserungsvorschlag 1: Der Link in der Introduction sollte nicht auf die manpage sondern auf Kapitel 6 verweisen - sonst übersieht man das evtl.
Verbesserungsvorschlag 2: Die Beispiele enthalten kein SQL. Wo genau wird das query jetzt festgelegt?
Verbesserungsvorschlag 3: Die Dateinamen im Beispiel heißen mysql.sql, hier geht es aber um Oracle.

Und es bleibt die Frage wie das über WATO mit der Agent Bakery konfiguriert werden kann.
Die Queries kann man ja durchaus lokal festlegen, in der Bakery müsste aber zumindest SQLS_DIR gesetzt werden können. Wenn man die Inhalte gleich mit verteilen kann wäre das natürlich besser.

1 Like

Hi,
die custom SQLs sind sehr flexibel und - leider - nicht sonderlich gut dokumentiert, wie Du ja bereits fest gestellt hast.

Daher mal ein kurzes Beispiel:
/etc/check_mk/mk_oracle.cfg

SQLS_SECTIONS=my_custom_sql
SQLS_DIR=/etc/check_mk/sql
SQLS_MAX_CACHE_AGE=120
 
my_custom_sql () {
SQLS_SIDS=testdb1
SQLS_SQL=name.sql
}

/etc/check_mk/sql/name.sql

select ‘details:’||ltrim(count(1))||’ users in dba_users’
from dba_users;
PROMPT exit:0

Agentausgabe:

[[[testdb1|test1234]]]

Checkname:

ORA TESTDB1 SQL NAME.SQL WARN - 25 users in dba_users(!),

Mein letzter Stand ist, das es keinen Support für die Bakery geben wird, weil die Variationsmöglichkeiten zu groß sind. Du kannst allerdings die Bakery parallel verwenden, wenn Du die Konfigrationen in /etc/check_mk/mk_oracle.d speicherst.

4 Likes

Vielen Dank für deine hilfreiche Antwort!

Auch von mir danke für dieses Beispiel!

Wenn ich die Konfiguration in die mk_oracle.cfg schreibt, dann klappt es. Wenn ich im gleichen Verzeichnis ein Verzeichnis mk_oracle.d anlege und darin meine test.cfg mit den gleichen Einstellungen - dann wird kein Service gefunden. So überschreibt mir ein neuer Agent aus der Bakery die Config wieder.

Muss ich das directory mk_oracle.d noch irgendwo angeben?
Die Variable MK_CONFDIR zeigt auf das Verzeichnis welches die mk_oracle.cfg und mk_oracle.d enthält. Der cmk Benutzer ist natürlich der Owner.

Hi,
die Funktion wurde erst nach dem Release von 1.6 implementiert.
https://checkmk.de/check_mk-werks.php?werk_id=10848

Da es sich um eine funktionalie Erweiterung handelt, diese nur in Ausnahme auf besehende stable-Releases übernommen werden, wird es in der 1.6.0 noch fehlen. Leider wird Dir da nichts anderes übrig bleiben als bei den Jungs von Tribe29 zu fragen, ob sie das portieren können oder Du muß Dir ein eigenes Plugin mergen und per MKP bereit stellen.

Ich verwende bei uns intern immer ein selbst zusammengeselltes Plugin, weil ich nicht so lange auf die Bereitstellung im stable warten möchte.

Gruß
Thorsten

1 Like

Hi Thorsten,

vielen Dank, das erklärt wieso es in meiner 1.6er Site noch nicht klappt.

Für andere hier mal noch die “Übersetzung” des Beispiels zur Doku.

Doku:

/*details:Text to display in the service detail output*/
prompt details: Some details for the service output;

/*perfdata:METRIKNAME=CURRENTVALUE;WARN;CRIT;MAX METRIKNAME=CURRENTVALUE2;WARN;CRIT;MAX*/
prompt perfdata:MyMetricName1=10;15;20;30 MyMetricName2=16;15;20;30;
prompt perfdata:MyMetricName3=21;15;20;30 MyMetricName4=15;15;20;30;

/*long:Text to display in the long output of the service*/
prompt long: Here comes some long output for the service;
prompt long: Here comes some more long output for the service;

/*exit:Status of the service as a number*/
prompt exit:2;

Hier angepasst an das Beispiel von Thorsten mit der Anzahl der User (ja, macht fachlich keinen Sinn, aber als Beispiel ok). Die erste zeile liefert den Service Output, die zweite Zeile einen Performance Graph und die dritte Zeile definiert den Status des Service.
Long Output habe ich jetzt mal weggelassen, das Prinzip ist aber wie bei den anderen.

select 'details: ' || ltrim(count(1)) || ' users in dba_users' from dba_users;
select 'perfdata: user=' || ltrim(count(1)) || ';80;90;' from dba_users;
select 'exit: ' || case when ltrim(count(1)) >= 80 then 1 when ltrim(count(1)) >= 90 then 2 else 0 end status from dba_users;