Genau so mache ich das auch! 
Hi @martin.schwarz,
ich glaube ich habe grundsätzlich die Regel “Hostname translation for piggybacked hosts” falsch verstanden. Ich dachte, wenn ich dort z.B. “Convert FQHN” auswähle, dann bezieht sich das “drop domain part” auf die Daten/Hostnamen, die vom VCenter aus ins checkmk rein kommen. Aber wenn ich dich richtig verstehe, ist es genau anders herum? Das “drop domain part” bezieht sich auf die Hostnamen im checkmk… und von denen wird die Domain abgeschnitten, damit es zu den Short-Names aus dem VCenter passt?! Hab ich das so richtig verstanden?
Noch eine Frage, wenn ich sage “drop domain part”, dann hat das nur interne Auswirkungen, damit das Mapping funktioniert - es wird nicht wirklich (sichtbar) irgendwo der FQDN in einen Shortname umgewandelt?
VG
Christian
Nö 
Deine eigentliche Vermutung ist richtig. Drop Domain Part bezieht sich auf die Daten vom vCenter.
vCenter interner Name → server.domain.de → Name im CMK → server
Daten werden ordentlich zugeordnet. Es ist wichtig zu beachten, dass die Regel auf das Objekt wirkt welches die Daten liefert nicht auf das Zielobjekt der Umbenennung.
Es ist sichtbar ob und wie die Umbenennung wirkt im Ordner “~/tmp/check_mk/piggyback/” dort besitzt jeder Host welcher Piggyback Daten erhält einen Namen. Dieser Name ist immer das Ergebnis aller angewendeten Piggyback Regeln.
ok, ich bin verwirrt…
wie mache ich denn dann das Mapping, wenn ich IM VCenter die shortnames habe und im checmk die FQDNs?
Dazu muss man auch noch sagen, dass man anhand unserer Hostnames nicht die Domäne erkennen kann und Domänen haben wir > 40.
Dann benutzt du die schon von @martin.schwarz beschriebene Variante per Regular Expression.
Genau so wie Er es beschrieben hat funktioniert das.
Ob deine Namen Lower oder Upper Case sind kannst ja selber entscheiden.
1 Like
okay, nur wenn ich viele Domänen habe und anhand der hostnamen die Domäne nicht erkennen kann, klappt das mit dem Replacement ja nicht so easy.
Ich teste mich da mal durch.
Danke auf jeden Fall!
Tja. Wenn schon der Mensch das nicht erkennen kann, wie soll dann die Maschine das anhand von Regeln automatisch festlegen können? Geht halt nicht.
In meinem Beispiel geht das deswegen noch automatisch, weil es das vCenter eines einzelnen Kunden ist und nur eine einzige Domain als Ergänzung in Frage kommt. Jede VM, die dort keinen FQDN hat (was sich durch Regexp erfassen lässt), bekommt eben hart diesen einen Domainnamen angehängt.
Du könntest natürlich jeden (vom vCenter kommenden) Kurznamen einzeln per expliziter Regel um eine Domain ergänzen - also eine 1:1 Übersetzungstabelle, eine Regel pro VM. Dann vielleicht lieber nochmal überlegen, ob man nicht doch die VMs schon im vCenter mit FQDNs benennen kann.
Du kannst die Regel doch auf die jeweiligen Kunden Vcenter festmachen und entsprechend den Domainnamen anhängen.
Wenn es getrennte vCenter sind, klar. Ich verstehe @CFriedrich so, dass er innerhalb eines vCenter VMs aus unterschiedlichen Domains hat.
Da müsste man dann schon die WATO-Regel mit weiteren Infos aus dem vCenter verknüpfen können, wie zB dem vSphere-Ordner (nicht WATO-Ordner), in dem die VM (im vCenter) einsortiert ist. Oder vielleicht ein innerhalb des vCenter vergebenes VM-Attribut oder die VM-Notizen aus dem vCenter. Ich fürchte diese Infos stehen in WATO so nicht zur Verfügung … bisher. Wäre das ein Feature Request wert? 
Hi,
genau, wir haben mehrere VCenter und in diesen, haben die VMs unterschiedliche Domains. Manche Systeme könnte man noch anhand ihres Namens zuordnen, aber viele andere nicht. Und wir sprechen von ca 5000 Linux-Systemen und mehr als 20 verschiedene Domänen. Über diesen Sachverhalt könnte man diskutieren, aber “leider” bin ich für die VM-Umgebung nicht zuständig…und die, die zuständig sind, haben bestimmt keine “Lust” das anzupacken 
Das mit dem VM-Attribut/Notizen klingt gar nicht mal so schlecht! Wenn man in der Hostname-Translation auf so etwas Zugriff hätte (im Idealfall auch mit regex)…und dementsprechend dann domains im checkmk anhängen könnte, wäre das vermutlich hilfreich.
Wir werden das jetzt erst mal so machen, wie ich es glaub ich schon mal erwähnt hatte:
- im checkmk alle Hosts mit Shortname (damit klappt dann das mapping mit den vcenter-Objekten)
- in das IPv4 Feld den fqdn des hosts (da nicht alle Linux Systeme über ihren Shortname auflösbar sind, und wir nicht 20 domains in die /etc/resolve.conf der checkmk-Hosts eintragen möchten und die IP zu statisch ist)
Inwiefern ein fqdn im IPv4 Feld zu Performanceproblemen im checkmk führen kann, müssen wir dann mal schauen. Richtig prüfen kann man die Performance-Einbußen dieser Umgehung des checkmk-DNS-Caches ja irgendwie nicht?!
In diesem Sinne, erst mal ein schönes Wochenende!
VG
Christian