Datenübergabe von WATO an Agent

Checkmk Exchange
1

Servus Community,

wir haben hier ein kleines Problem, bei dem sich einfach nicht die Ursache finden lässt.
Wir haben einen Special Agent, den wir aus einem mkp heraus ausgerollt haben. Die Installation verlief ohne Probleme. Der Agent kann über WATO konfiguriert werden. Ihm muß ein username, ein password und ein hostname übergeben werden. Außerdem gibt es die Möglichkeit, auszuwählen, daß keine ssl-Zertifikatprüfung erfolgen soll, indem man eine Checkbox anhakt.
Offensichtlich nimmt er den Wert aus der Checkbox nicht, weil er immer in einen ssl-timeout Fehler läuft.
Führt man den Agent direkt in der CLI aus, mit usr, pwd, hostname und der Option zum exclude der ssl-Zertifikatprüfung, wird das fehlerfrei durchgeführt und es kommen die erwarteten Resultate zurück.

Uns ist nun nicht ganz klar, wie die in WATO konfigurierten Werte an den Agent übergeben werden. Prinzipiell scheint das ja zu funktionieren, denn wenn man bspw. einen falschen username angibt, kommt auch ein Fehler wegen einem unbekannten unsername.
Die Dokus hinsichtlich der Programmierung von eigenen Checks etc. haben uns leider nicht weitergeholfen. Wir sehen programmtechnisch keine Verbindung zwischen dem wato web-plugin und dem eigentlichen special-agent unter agents/special.
Vielen Dank schon mal für eventuell weiterführende Ideen.

Uwe

2

Ich weis zwar nicht welcher Agent das ist aber im Prinzip hast du recht und zwischen WATO und dem Agent besteht erstmal keine Verbindung.

Mit den WATO Rules werden meistens die Agent vorkonfiguriert und dann “gebacken” (Agent-bakery)

dann wird der gebackene Agent (z.B. mit den Passwörtern für DB`s, etc) auf dem Client installiert.

Führst du den Agent auf der CLI aus gibst du Ihm ja manuell die Parameter alle mit.

Datenquellenprogramme - Geräte ohne Betriebssystemzugriff überwachen.

Gruß Bernd

3

Hi Uwe,

der Special Agent benötigt im Verzeichnis ~/local/share/check_mk/checks noch einen Wrapper der die Eingaben im WATO in CLI Parameter umsetzt: Hier ein Beispiel:

#!/usr/bin/env python
# -*- encoding: utf-8; py-ident-offset: 4 -*

def agent_myagent_attr(params, hostname, ipaddress):
    args = []
    if "user" in params:
        args += ["-u", params["user"]]
    if "check_ssl" in params:
        args += ["-c", params["check_ssl"]]
    if "password" in params:
        args += ["-p", passwordstore_get_cmdline("%s", params["password"])]
    args.append(ipaddress)
    return args

special_agent_info["myagent"] = agent_myagent_attr

Vielleicht hilft dir das weiter.

Viele Grüße, Christian

1 Like
4

Und nachdem du @ChristianM seine Sache überprüft hast kannst ja noch ein “cmk -D hostname” ausführen um zu sehen welchen Special Agent Aufruf das “Wrapper Script” erzeugt hat.
Ich würde mal vermuten, dass einfach in dem agent_… Script einfach die Auswertung des SSL Parameters fehlt.

1 Like
5

Dank Euch allen für Eure hilfreichen Anmerkungen. Das hat uns bereits ein Stück weiter gebracht.
Der Wrapper war zwar da, aber die übergebenen Variablen haben nicht gepaßt. Das ist jetzt korrigiert.
Jetzt wollen wir mal schauen, ob es nun paßt.

Uwe

6

Abschließend noch das Resultat. Der Agent arbeitet nun wie gewünscht, nachdem schlußendlich die zu überwachenden Hosts von unseren Storage-Kollegen auch noch in die Nameserver eingetragen wurden… womit die Namensauflösung im Check nun auch funktioniert und nicht mehr zu einem Verbindungsfehler führt.
Nochmals danke.

Uwe