vSphere Monitoring Frage

Hallo zusammen,

bin gerade mal dabei bei einer VM Umgebung das Monitoring nach https://checkmk.de/cms_monitoring_vmware.html zu konfigurieren, um mal zu sehen wie es sich damit verhält und alles etwas zu bereinigen bzw. auf die neuen Möglichkeiten (piggyback) anzupassen.
Das einzige was mir eigentlich noch fehlt ist die Hostserver Hardware zu überwachen/monitoren.
Das könnte man über SNMP auf der iLO Karte machen. Ist das eine gute Kombination?
Wie macht ihr das?

Grüße,
Oliver

Hallo,
es gibt eine Option Management Board in der Host-Config.
Die sollte dir alles liefern was du brauchst.

Gruss

Bei mir leifert der vcenter Server die Hardware Sensor Infos via Piggypack

Also wenn der Host im vCenter mit mit seinen Hardware Infos OK ist, dann ist das Monitoring auch OK

Jörg

Moin Ralf,

ja genau daran habe ich auch gedacht. Nur muss ich mal schauen, wie ich evtl. den Abfrage Interval verkleinere, da man das ja nicht ganz oft braucht und snmp ja auch nicht so die schnellste Schnittstelle ist. Hatte sehr gehofft darauf verzichten zu können.

Grüße,
Oliver

Hallo Jörg,

da bin ich noch dran, bis jetzt bekomme ich gefühlt nur eine kleine Menge an Piggyback Daten. Aber genau deswegen mache ich das ja. Aber es wäre ja zu einfach, wenn es gleich auf Anhieb ohne Probleme klappen würde :wink:

Grüße,
Oliver

So wie es aussieht, ist wohl das größte Problem, das ich noch die Zuordnung Piggyback verstehen und hinbekommen muss. Da muss ich wohl einige Hostnamen anpassen. Aber wo muss ich das machen? Auf dem vCenter, ESX Host oder VM Maschine? :upside_down_face:

Hallo Oliver,
grundsätzlich liefert die vCenter Abfrage diverse Daten zu Hosts und Guests als Piggyback. Damit Du die im Check_MK siehst ist es am Besten, wenn die Namen im vCenter identisch zu denen im Check_MK sind. Sollte das nicht möglich/gewünscht sein, gibt es die Regel “Hostname translation for piggybacked hosts” mit der Du entweder tabellarisch oder per RegEx Anpassungen vornehmen kannst.
Gruß
Udo

Alternativ geht das über regex mit den piggyback Daten; dann spart man sich das Umbenennen. Ich bin allerdings großer Freund von einheitlicher FQDN-Nutzung. Das macht das Leben häufig leichter. Die Piggyback Daten kannst du vom vCenter oder von den einzelnen Hosts bekommen. Wenn ich mich recht entsinne muss es aber bei einzelnen Hosts über Accounts mit Rootberechtigung laufen - finde ich eher unschön. Ich habe bei uns einen Extra-Account, der nur Leserechte hat und über das vCenter abfragt.

+1
wird ziehen die Namenskonventionen bis auf das Filesystem runter durch.
Wenn VMs zicken hat man eh schon Spaß und braucht nicht noch zusätzliche Spannung wenn man raten muss welcher Order den der richtige ist.
Gruss

Hallo zusammen
damit das Hardware Montoring über vSphere funktioniert, muss auf den ESXen das entsprechende VIB File installiert sein oder man nimmt gleich das angepasste Image der Hersteller.
Da wir mit dem Hardwarepart über ESX schlechte Erfahrungen gemacht haben (gerade was Netzteilredundanz betrifft), haben wir uns dazu entschlossen, die Hosts doppelt anzulegen. D.h. einmal mit OS oder Hypervisor (wo dann auch Piggyback funktioniert) und dann nochmal mit Hostname und einem R am Schluss mit der IP des Management Boards (iLO, iDRAC usw) mit SNMP.
Das kostet zwar Performance wegen SNMP und die Hosts sind doppelt, hat aber den Vorteil, dass ich nicht zwingend auf VIB Files oder das angepasste Image angewiesen bin (-> Updates) und ich kann mich unabhägig von OS/Hypervisor auf das wirklich gute Autodiscovery von Checkmk via SNMP verlassen (hier dickes Lob einfügen), welches zuverlässig alles wichtige findet und ich dann mit einer Regel auf alles wichtige beschränken kann (1 Temp, RAID, PSU, Overall Status sofern verfügbar, fertig). Und dank der Host Notes Regel https://$HOSTADDRESS$ komme ich mit einem Mausklick direkt zum Zielsystem.
Angenehme Nebeneffekte (naja wie mans sieht): Dell iDRACs neigen immer mal wieder zum Absturz. Dann geht alles auf UNKN und ich weiß dass ich das iDRAC resetten muss.
Und da Management Netz & Produktivnetz verschieden sind und an unterschiedlichen Switches hängen, weiß man bei DOWN sofort wo der Fehler ist und wer ggfs betroffen ist.
Das hat sich bei uns bewährt: ~3500 Server mit Linux/Windows, ~120 ESX Hosts.