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
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.
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.
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.
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.
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!
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
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?
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.
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
Da hat vermutlich so jeder Admin und jedes Umfeld seine eigenen Gepflogenheiten
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” - 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.
@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.
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.