Frage zur Benennung von Hostobjekten und FQDN

Hallo, ich habe Fragen zu der Benennung von Hostobjekten und der Verfügbarkeit des FQDNs eines Hosts. Aktuell haben wir Linux + AIX Systeme mit FQDN als Objekt in checkmk angelegt, dies führt aber dazu, dass wir die Objekte umbenennen müssen, wenn sie die Domäne wechseln und piggyback zwischen VCenter und checkmk funktioniert nicht, da die Systeme im VCenter mit Shortnames gepflegt werden. Da wir nachgelagert zu checkmk noch ein Event-Management-System nutzen, brauchen wir von checkmk aber die Info, welchen FQDN ein Host hat. Wir hatten die Hoffnung, dass der FQDN als Parameter mit im Notify-Environment steht, tut er aber nicht. Aktuell wäre die einzige Lösung die uns einfällt folgende:
Der Host wird im checkmk mit shortname angelegt und im Feld IPv4 Address tragen wir den FQDN ein. So funktioniert dann das piggiback und wir haben den FQDN im Notify-Environment im IPv4 Feld stehen. Zieht ein Host in eine andere Domäne, muss natürlich das IPv4 Feld angepasst werden, was ja aber nicht so tragisch ist, wie ein ganzes Hostobjekt umzubenennen.

Gibt es vielleicht noch bessere oder andere Möglichkeiten das zu lösen?
Danke vorab.
Christian

Hallo Christian,

bei mir ist der Hostname immer der FQDN und der Alias ist der Host Part

Die Domain kannst du über “Hostname Translation for piggybacked hosts” abschneiden.
Ich transformiere auch die ESX namen in Lowercase über diese Regel.

Jörg

Hi Jörg,
danke für den Tipp.
Das heisst, wenn ich diese Rule hier aktiviere:
Convert FQHN

Drop domain part (host123.foobar.de → host123)

wird der Domain-Part des checkmk-Host-Objekts ignoriert und somit passt es zum Shortname der vom VCenter kommt, richtig?

VG

bei mir ist es umgekeht.

alle meine Hosts sind im Wato mit FQDN definiert.
Das vcenter liefert nur den Hostname.

Also transformiere ich alle vCenter namen in LowerCase und dann hänge ich via Regex den Domain Part dran.

Regex -> (.*)
Replace \1.fq.dn

Jörg

2 Likes

Wenn ein Hostname oder FQDN im Adressfeld steht, muss bei jeder Agentenabfrage und anderen aktiven Checks eine DNS-Auslösung ausgeführt werden. Das ist nicht so günstig, weil zusätzlicher Netzwerktraffic und Abhängigkeit zum DNS während des Monitorings.

Es kam ja schon der Vorschlag mit dem Host-Alias, da ließe sich der FQDN prima unterbringen.

Hi Robert,

das stimmt so nicht ganz , beim anlegen des Hots ohne IP wird eine einmalige dns abfrage gestartet die IP wird dann gecached bis du den DNS cache erneuerst (eigener Button) in Wato wenn du den Host editierst.

3 Likes

Hi Robert,

um die Erklärung von Manfred zu ergänzen: Um eine dynamische DNS Auflösung überhaupt erst einzuschalten, gibt es in Host & Service Parameter die Regel “Hosts with dynamic DNS lookup during monitoring”.

Praktisch z.B. um dynamische DNS Namen mit wechselnden IPs wie z.B. www.google.de überhaupt erst sinnvoll monitoren zu können.

Gruß
Alex

1 Like

Hi Robert,

oder meintest du mit Adressfeld das Feld IPv4 Address bzw. IPv6 Address und nicht das Hostnamens-Feld? Dann hast du selbstverständlich Recht, bei jeder Anfrage würde ein DNS Lookup ausgeführt werden und der Cache umgangen. An dieser Stelle Danke an @MarsellusWallace für den Hinweis!

1 Like

Genau das meinte ich, sonst hätte ich ja vom Hostnamen-Feld geschrieben.

1 Like

Hi Robert, danke dir für diese Info. Das Problem ist, dass wir gerne den fqdn in einem nachgelagerten Eventmanagement-System verwenden möchten und soweit ich das sehe, wird der Host-Alias auch nicht in das notfy_ Environment übergeben oder?
Wir könnten natürlich im Eventmanagement-System anhand der durch checkmk mitgelieferten IP wieder eine DNS Auflösung machen, jedoch hätten wir dann an dieser Stelle den Aufwand.
VG

Der Host Alias ist im Notification System verfügbar.
Also sollte deinem Vorhaben mit dem EventSystem nix entgegen stehen.

2 Likes

Hi @andreas-doehler,
stimmt, du hast Recht. Hab ich übersehen :slightly_smiling_face:
Danke!

NOTIFY_HOSTALIAS wollte ich noch schreiben, aber da war @andreas-doehler schneller. :slight_smile:

2 Likes

Hi,
ich habe nochmal eine Frage zu dem Thema. Wir hatten uns jetzt folgendes überlegt:

Hostname: short-name -> z.B. sapt1300
Alias: Description -> z.B. SAP Test 1300
IPv4 Feld: IP des Systems -> z.b. 192.168.21.21
Custom Host-Attribute: host-fqdn z.B. sapt1300.rewe.test

Konkrete Frage wäre nun, spricht etwas dagegen, bei jedem System die IP in das IPv4 Feld zu schreiben? Ich hatte gelesen, man müsse aufpassen wegen des checkmk-internen-DNS-Caches?!
Aber wenn im IPv4 Feld direkt die IP drin steht, sollte man doch diesbezüglich keine Probleme bekommen oder?

VG

Beim Hostname achte ich immer darauf, dass der Hostname dem Namen der VM in der VMware entspricht. Grund dafür sind die Piggyback Informationen die ich somit für jeden Host aus der VMware erhalte. Das gleiche gilt auch für weitere Plugins wie z.B. das Veeam Plugin.

Ich wüsste nicht was dagegen sprechen sollte. Ich bin kein Fan davon Hosts nur per DNS Auflösung zu erreichen. Grund dafür ist, dass ich so wenige Abhängigkeiten wie möglich haben möchte. Bedeutet, falls mal eine DNS Auflösung nicht möglich ist, aber der Hosts noch per IP erreichbar ist, dann bekommt mein Monitoring weiterhin alles ohne Probleme mit.
Daher pflege ich immer die IP Adressen der einzelnen Hosts.

Falls das jemand anders sieht, bin ich offen für andere Ansätze. :grinning:

Genau, den Hostnamen müssen wir short machen, damit er zu den Konventionen im VMWare-Umfeld und Kubernetes passt.
Meine Kollegen sagen halt, ich soll den FQDN einfach in das IPv4 Feld eintragen (statt in ein Custom-Feld). Selbst wenn checkmk dann jedes mal versucht den Namen aufzulösen, könnte das ja kaum Performanceprobleme verursachen, da zig andere Anwendungen auch einfach nur den DNS Cache vom Linux-System nutzen. Das wäre halt jetzt noch die spannende Frage… FQDN oder IP im IPv4 Feld :smiley:

Da hat vermutlich so jeder Admin und jedes Umfeld seine eigenen Gepflogenheiten :slight_smile:

Ich tendiere meist grad zum Gegenteil: Die Zuordnung Hostname zu IP-Adresse wird möglichst nur an einer Stelle gepflegt, und das ist dann üblicherweise direkt im DNS. Wenn sich eine IP-Adresse ändert, muss das dann nicht an zig Stellen überall nachgezogen werden. DNS-Resolver müssen ohnehin eine ziemlich hohe Verfügbarkeit haben. Außerdem hat Checkmk ja auch noch selbst einen DNS-Cache, so dass dort nicht sofort alles wegfallen würde.

Und der fully-qualified hostname (FQDN) ist dann auch gleich der eindeutige Schlüssel für das System. Im Monitoring, im Wiki, im Config-Management, im Backup, im vCenter, … überall.
Ohne angehängte Domain ist der Name nicht unbedingt eindeutig. “ping www” :wink: - je nach Searchdomain. Oder sorgt auch mal für Verwirrung, wenn der Kunde intern die Subdomain nyc.kunde.tld (für New York City) verwendet, aber dann hostname.nyc auch im öffentlichen DNS für die “neue” TLD .nyc eingetragen ist.

1 Like

@martin.schwarz
Eigentlich würden wir auch am liebsten den FQDN im Hostname-Feld nutzen, aber leider passt das nicht zu den Namen im VMWare und Kubernetis-Umfeld. Dort haben sich die Kollegen für Shortnames entschieden. Und soweit ich das sehe, kann man in dem Fall nicht mit einer checkmk-Regel mappen. Daher müssen wir den Shortname verwenden.

Das lässt sich glaube ich via Regel umsetzen.
Es gibt die Regel “Hostname translation for piggybacked hosts”

Da kannst du die FQDN entfernen damit das Piggyback funktioniert. Vielleicht hilft das ja. Habe es selbst aber noch nicht angewendet. :wink:

Für kurze Hostnamen aus VMware geht das auf jeden Fall mit “Hostname translation for piggybacked hosts”. Ich hab z.B. bei einem Kunden, der seine VM-Objekte teilweise (!) mit Kurznamen anlegt, folgende Regel:

Multiple regular expressions
Regular expression: ([a-zA-Z0-9\-]+)$
Replacement: \1.kundendomain.tld
(und noch ein “Convert hostnames to lower case” damit es einheitlich ist)

Wenn also der gelieferte komplette VM-Name nur aus Buchstaben, Zahlen oder Minus besteht, wird die Kundendomain angehängt. Alternativ könnte man wohl auch mit ([^\.]+)$ auf beliebige Zeichen außer Punkt matchen.

Wenn die Kubernetes-Checks auch via piggyback reinkommen, sollte die hostname translation dafür genauso greifen.

3 Likes