VMware-Monitoring mit Checkmk

Die Monitoring-Hosts für Ihre virtuellen Maschinen (VMs) kann Checkmk automatisch erstellen. Als Host-Namen übernimmt es die Display-Namen aus VMware vCenter. Deshalb ist ein konsistentes Namenskonzept mit DNS-Namen eine wichtige Grundlage für dieses Tutorial. Sie sollten dieser Anleitung über Namenskonzepte folgen. Sie erläutert die Kriterien, die Sie bei der Benennung Ihrer Systeme beachten sollten. Ändern Sie aber die Display-Namen Ihrer Systeme in VMware nicht, ohne zuvor den verlinkten Artikel komplett gelesen zu haben.

Um Monitoring-Daten über die VMware-API abrufen zu können, braucht Checkmk für das vCenter und jeden ESXi-Host ein Zugangskonto mit ausschließlich Leserechten. Sie sollten den Benutzerkonten für das Monitoring aus Sicherheitsgründen niemals Schreibrechte einräumen.

Für vCenter müssen Sie dem Nutzerkonto Read-only-Rechte auf höchster Ebene und für das gesamte Inventory zuweisen. Aktivieren Sie daher im vSphere Client in der Konfiguration die Checkbox “Propagate to children”. In meinem Fall habe ich als vCenter-Benutzernamen "monitoring" gewählt. Da die Domain in vSphere standardmäßig “.vsphere.local” heißt, werde ich später den Zugang in Checkmk mit “monitoring@vsphere.local” einrichten, der Nutzername allein reicht in Checkmk nicht aus. Sie könnten hier als Alternative auch ein Konto nutzen, das Sie über Active Directory eingerichtet haben.

Auf jedem meiner ESXi-Hypervisoren habe ich ein Read-only-Konto mit dem Namen “checkmk” erstellt. Für alle erstellten ESXi-Zugänge nutze ich das gleiche Passwort. Die Nutzung der gleichen Zugangsdaten für alle ESXi-Hosts ist kein Muss, erleichtert später aber die Konfiguration.

Als ersten Schritt erstellen Sie in Checkmk einen Ordner für die Verwaltung Ihrer VMs im Monitoring.

• Unter Setup -> All hosts klicken Sie auf Add folder und geben unter Title einen Namen Ihrer Wahl ein. Ich habe den Ordner “vm” genannt.
• Aktivieren Sie die Checkbox bei Checkmk agent / API integrations und wählen Sie die Option “Configured API integrations and Checkmk agent”.
• Klicken Sie auf Save.

Damit haben Sie einen Ordner in Checkmk erstellt und definiert, dass Checkmk für alle Hosts in diesem Ordner die Daten über APIs und den Checkmk Agenten erwartet. Dadurch können Sie später auf den VMs noch den Checkmk Agenten installieren und so zusätzliche Monitoring-Daten abrufen.

Fügen Sie diesem Ordner nun vCenter als ersten Host hinzu.

• Öffnen Sie den eben erstellten Ordner, indem Sie auf ihn klicken.
• Klicken Sie auf Add host.
• Geben Sie den Display-Namen von vCenter unter Hostname ein. In meinem Fall “muc-vm-vcenter-001.lan.domain.net”.
• Da die Display-Namen nach DNS auflösbar sind, können Sie alle anderen Einstellungen wie gehabt lassen und klicken auf “Save & go to folder”.

Haben Sie mehrere vCenter-Server im Einsatz, können Sie diesen Schritt wiederholen und so sämtliche vCenter-Server als Hosts in das Monitoring aufnehmen. Abhängig von der Verteilung und dem Aufbau Ihrer IT-Umgebung kann es aber auch sinnvoll sein, die Ordnerstruktur in Checkmk granularer aufzubauen und zum Beispiel zuerst einen Ordner für jeden Standort zu erstellen. Dann sollten Sie für jeden Standort wiederum einen eigenen Ordner mit VMs nutzen und nicht sämtliche VMs von allen Standorten in einem Ordner erstellen.

Sind Ihre Display-Namen in VMware nicht nach DNS auflösbar, müssten Sie unter IPv4 address die IP-Adresse Ihres vCenter-Servers in Checkmk hinterlegen, bevor Sie fortfahren. Ein nicht-stringentes Namenskonzept führt langfristig immer zu Problemen und erschwert später beispielsweise die richtige Zuordnung von Monitoring-Daten. Ich empfehle daher, Ihr Namenskonzept entsprechend der anfangs verlinkten Anleitung anzupassen.

Jetzt müssen Sie Checkmk Zugang zu vCenter gewähren und entscheiden, welche Daten es von dort abrufen soll.

• Klicken Sie erneut auf Setup und suchen Sie nach “vmware”.
• Anschließend klicken Sie auf die Regel ”VMWare ESX via vSphere”.
• Klicken Sie auf Add rule.
• Unter VMWare ESX via vSphere passen Sie die Punkte der Reihe nach an: Unter vSphere User name tragen Sie Ihr vorbereitetes Benutzerkonto für vCenter ein. In meinem Fall ist das “monitoring@vsphere.local”, gefolgt vom Passwort unter vSphere secret.
• Da Sie VMware vCenter nutzen, müssen Sie bei Type of query die Auswahl auf “Queried host is the vCenter” stellen.
• Die Checkbox vor TCP Port number müssen Sie nur aktivieren, wenn Sie den Port für HTTPS auf einen anderen Port gelegt haben. Das ist aber in den meisten Umgebungen nicht erforderlich.
• Bei SSL certificate checking können Sie bei der Default-Einstellung “Use hostname” bleiben, wenn Sie für vCenter eines von einer Zertifizierungsstelle ausgestelltes Zertifikat nutzen. Ist dies nicht der Fall, müssten Sie unter SSL certificate checking die Option “Deactivated” wählen. Bedenken Sie dabei, dass VMware vCenter standardmäßig mit HTTPS und einem selbst signierten Zertifikat startet.
• Mit der Option Connect Timeout können Sie Checkmk sagen, dass es bei langen Antwortzeiten abbrechen soll. Im Normalfall brauchen Sie diese Option nicht, daher setzen Sie keinen Haken.
• Unter Retrieve information about entscheiden Sie, für welche Systeme Checkmk Daten von vCenter abrufen soll. Deaktivieren Sie die Option “Host Systems”, damit die ESXi-Hosts nicht in Ihrem Ordner für VMs landen. Sie erstellen die Hosts später separat. Mit “Licence Usage” können Sie den Gesamtstatus der genutzten Lizenzen von vCenter abrufen. Dies ist nur bei sehr großen Rechenzentren mit überprovisionierten Lizenzen erforderlich, ich nutze diese Option nicht.
• Lassen Sie die Optionen zur Überwachung von Placeholder VMs und Display ESX Host power state on deaktiviert. Sie sollten hier aber die Option VM snapshot summary aktivieren, denn vergessene Snapshots können mitunter zu dramatischen Problemen führen.
• Checkmk übernimmt standardmäßig die in vCenter konfigurierten Display-Namen als Host-Namen. Unter Piggyback name of virtual machines können Sie Checkmk sagen, dass es auf die Namen, wie sie in den ESXi-Hosts hinterlegt sind, zurückgreifen soll. Ich brauche diese Option in diesem Tutorial nicht und kann die Anwendung auch nicht empfehlen. Die VMware-Schnittstelle neigt hierbei in der Praxis zu Fehlern.
• Checkmk erlaubt keine Leerzeichen in Host-Namen, Display-Namen in VMware können theoretisch Leerzeichen haben. Wenn Sie DNS-Namen in VMware nutzen, haben Sie aber keine Leerzeichen. Wenn Sie trotzdem Leerzeichen in VMware verwenden, können Sie mit Spaces in hostnames entscheiden, wie Checkmk damit umgehen soll.

• Unter Conditions wählen Sie unter “Explicit hosts” Ihren vCenter-Server aus. Haben Sie mehrere vCenter-Server im Einsatz und nutzen für alle Read-Only-Konten die gleichen Zugangsdaten, können Sie alle vCenter-Server gemeinsam mit einer Regel abfragen. Fügen Sie die entsprechenden vCenter-Hosts einfach hier hinzu. Ansonsten müssen Sie eine neue Regel für jeden vCenter-Server konfigurieren und die Zugangsdaten an den entsprechenden Host anpassen.
• Klicken Sie auf Save und speichern Sie damit die Regel.

Checkmk kann jetzt über die VMware-API die Daten von vCenter abrufen. Dafür sollten Sie die automatische Service-Erkennung in Checkmk für Ihren vCenter-Host starten.

• Gehen Sie zu Setup -> Hosts und klicken Sie auf Ihren Ordner für die VMs. Sie sollten nun den vCenter-Host sehen.
• Klicken Sie auf das gelbe Symbol Ihres vCenter-Hosts genau in der Mitte der Symbolleiste.

• Warten Sie, bis Checkmk die automatische Service-Erkennung abgeschlossen hat und klicken Sie auf Accept all.
• Wichtig an dieser Stelle: Aktivieren Sie die “pending changes” noch nicht, sondern lesen dieses Kapitel bis zum Ende.

Sie haben jetzt sämtliche VMs als Monitoring-Services aufgenommen – und vielleicht noch mehr als das. Die VMware-API erlaubt zum Beispiel keine Unterscheidung von Templates und VMs. Wenn Sie in vCenter Templates erstellt haben, erkennt Checkmk neben den VMs daher auch Ihre Templates als Hosts im Monitoring. Checkmk hält diese für ausgeschaltete VMs und würde standardmäßig von einem Fehler ausgehen.

Sie könnten die einzelnen Services der Templates manuell nach der Service-Erkennung deaktivieren. Nutzen Sie aber ein konsistentes Namenskonzept in VMware, kommen Sie mit der Disable-Service-Regel in Checkmk schneller ans Ziel. Außerdem werden so auch Templates aus der Überwachung ausgeschlossen, die Sie erst in der Zukunft erstellen.

In meinem Fall habe ich alle Display-Namen meiner Templates in VMware mit dem Präfix “template” versehen. Damit ist die Entfernung der Templates-Services aus dem Monitoring ein Kinderspiel:

• Klicken Sie auf Setup. Suchen Sie nach “disable” und klicken Sie auf “Disabled services”.
• Klicken Sie auf Add rule.
• Unter Conditions wählen Sie die Option Explicit hosts und geben dort Ihren vCenter-Host an. Nutzen Sie mehrere vCenter-Server, können Sie hier mehrere Hosts eintragen. In meinem Fall trage ich “muc-vm-vcenter-001.lan.domain.net” ein.
• Dann aktivieren Sie die Checkbox bei Services. Anhand der Service-Namen können Sie jetzt Services deaktivieren. Ich nutze die Regex “VM template”. Dadurch werden alle Services mit dem Präfix “template” für vCenter deaktiviert. Beachten Sie, dass Checkmk vor dem Service-Namen einer VM das Kürzel “VM” anfügt.
• Speichern Sie die Regel mit Save.

• Jetzt starten Sie erneut die Service-Erkennung für den vCenter-Host wie zuvor unter Setup -> Hosts. Klicken Sie wieder auf das gelbe Symbol in der Mitte vor Ihrem vCenter-Host. Im Vergleich zu vorher sind die Services Ihrer Templates jetzt alle deaktiviert.
• Klicken Sie auf Accept all.

Checkmk nutzt den Piggyback-Mechanismus, mit dem es praktisch im Huckepack übertragene Informationen auf Basis der Host-Namen den passenden Hosts im Monitoring zuordnet. Dies können zum Beispiel die Daten zu den einzelnen VMs vom ESXi-Host oder vCenter sein.

Dafür müssen Sie jedoch zunächst die VMs als Hosts in Checkmk anlegen, da diese bisher nur als Services Ihres vCenter-Servers sichtbar sind. Dafür müssen die Host-Namen in Checkmk den Display-Namen in VMware entsprechen. Nur dann kann Checkmk die Piggyback-Daten richtig zuordnen.

Sie könnten die Hosts für die VMs manuell anlegen. Es geht aber auch einfacher: Über den anfangs erwähnten Dynamic Configuration Daemon (DCD) erstellt Checkmk die Hosts für Ihre VMs automatisch:

• Suchen Sie unter Setup nach “dynamic” und klicken Sie auf ”‘Dynamic host management”.
• Klicken Sie auf Add connection.
• Wählen Sie unter General Properties eine beliebige Unique ID und einen Title. In meinem Beispiel habe ich mich für “vmware-vcenter” und “vm” entschieden.

• Unter Connection Properties müssen Sie einmal auf “Add new element” klicken, damit Checkmk automatisch Hosts erstellen kann.
• Außerdem müssen Sie sich bei Connection Properties die erweiterten Optionen anzeigen lassen. Klicken Sie dazu auf “show more”.
• Unter Piggyback creation options wählen Sie den Zielordner für Ihre VMs. In meinem Fall “vm”.
• Bei Hosts attributes to set sind Attribute für Monitoring agents: SNMP, Monitoring Agents: Checkmk agent / API integrations, Monitoring agents: Piggyback und Network address: IP address family vordefiniert. Löschen Sie die vier Vorgaben, Sie brauchen diese für das VMware-Monitoring nicht. Klicken Sie dazu je einmal auf jedes der vier x-Symbole der einzelnen Attribute, sodass diese verschwinden.
• Aktivieren Sie die Option Only add matching hosts und nutzen Sie Regex, um nur für die VMs Hosts zu erstellen. Sind Sie der verlinkten Empfehlung für ein Namenskonzept gefolgt, können Sie hier “ .*-vm” eintragen. Belassen Sie die anderen Einstellungen wie gehabt.
• Klicken Sie auf Save.

Jetzt rufen Sie die Monitoring-Daten der ESXi-Hosts ab. Dazu erstellen Sie zunächst einen Ordner für die ESXi-Hosts.

• Unter Setup -> All hosts erstellen Sie wieder mit Add folder einen Ordner. Als Title nutze ich hier “esxi”. Sie können einen Namen Ihrer Wahl nutzen.
• Klicken Sie auf Save.

Auf den ESXi-Hosts können Sie keine Checkmk Agenten installieren, daher können Sie für diesen Ordner die Default-Einstellung behalten.

Erstellen Sie eine Regel, um über die VMware-API die Daten abrufen zu können:

• Klicken Sie wieder auf Setup und suchen erneut nach “vmware”. Klicken Sie auf “VMWare ESX via vSphere”.
• Klicken Sie auf Add rule.
• Als vSphere User name nutzen Sie Ihr Read-only-Konto. Bei mir heißt dies “checkmk” für alle ESXi-Hosts. Dazu folgt das passende Kennwort unter vSphere secret.
• Bei Type of query belassen wir die Default-Einstellungen "Queried host is a host system".
• Connect Timeout können Sie wieder lassen wie gehabt.
• Unter Retrieve information about… unterscheidet sich die Konfiguration im Vergleich zu vCenter zuvor. Sie lassen jetzt die “Host Systems” und “Performance Counters” aktiviert, entfernen aber den Haken vor “Virtual Machines” und “Datastores”. Diese Informationen bekommen Sie bereits von vCenter.
• Piggyback name of virtual machines und VM snapshot summary lassen Sie ebenfalls deaktiviert.

• Diesmal wählen Sie unter Conditions bei Folder den eben erstellten Ordner für die ESXI-Hosts aus. In meinem Beispiel ist das “esxi”. Da ich für alle ESXi-Hosts die gleichen Zugangsdaten nutze, kann ich die Regel auf den Ordner anwenden. Verwenden Sie unterschiedliche Zugangsdaten, müssen Sie für jeden ESXi-Host die Regel mit den jeweiligen Anmeldedaten definieren.
• Klicken Sie auf Save, um die Regel zu speichern.

Sie haben Ihr VMware-Monitoring nun so konfiguriert, dass Sie über vCenter die Daten zu sämtlichen VMs abrufen. Die Informationen zu den ESXi-Hosts rufen Sie aber von den Hypervisoren direkt ab. Dies ist die einzige Möglichkeit, um hardwarespezifische Daten der Cluster-Knoten, wie zum Beispiel der Zustand der Netzwerkkarten, zu überwachen.

Außerdem sind Sie so unabhängig von vCenter. Fällt es als Datenquelle aus, haben Sie trotzdem immer noch die Informationen zum Zustand Ihrer VMware-Hardware. Nutzen Sie einen ESXi-Host als Stand-alone-Hypervisor ohne vCenter, dann müssen Sie die Informationen zu Ihren VMs und Datastores von diesem direkt abrufen. Dazu müssen Sie die Optionen in Retrieve information about… aktiviert lassen.

Setzen Sie hingegen auf einen VMware-Cluster, liefert nur das vCenter den Gesamtüberblick über die VMs und die Provisionierung der Datastores für alle VMs. ESXi-Hosts sehen hingegen nur die Provisionierung der eigenen VMs. Wenn Sie die Provisionierung über vCenter und ESXi-Hosts doppelt überwachen würden, käme es zu Abweichungen der Provisionierungswerte. Ebenso lässt sich das Verschieben von VMs auf einen anderen Knoten mit den einzelnen ESXi-Host-Daten nicht sauber im Monitoring abbilden.

Sie können jetzt Ihre Hypervisoren als Host in Checkmk hinzufügen. In diesem Tutorial nehme ich diese manuell als Hosts in das Monitoring auf. Haben Sie mehr als zehn ESXi-Hosts, bietet sich der Import über eine CSV-Datei an. Folgen Sie dazu dieser Anleitung im Checkmk Handbuch.

• Gehen Sie zu Setup -> Hosts und wählen den Ordner, auf den Sie die Regel für die ESXi-Hosts angewendet haben. In meinem Fall “esxi”.
• Klicken Sie auf Add host.
• Als Hostname geben Sie den Display-Namen des ersten ESXi-Hosts ein. In meinem Fall “muc-sr1-esxi-001.lan.domain.net”.
• Klicken Sie auf Save & go to service configuration.
• Warten Sie, bis Checkmk die automatische Service-Erkennung abgeschlossen hat.
• Klicken Sie auf Accept All, schließen Sie aber die Ansicht noch nicht.

Für alle ESXi-Hosts sollten Sie die Monitoring-Services für “Hardware Sensors” an dieser Stelle deaktivieren. Da Sie später die Server-Hardware über das Management-Board des Servers überwachen, benötigen Sie die Hardware-Überwachung von VMware nicht. Diese arbeitet zudem nicht immer zuverlässig und liefert häufig Fehlalarme.

• Entfernen Sie den Monitoring-Service “Hardware Sensors” wieder. Klicken Sie dazu einfach auf das rote X-Symbol vor dem Monitoring-Service “Hardware Sensors”. Dieser wird daraufhin in den Bereich Disabled services verschoben.
• Dort klicken Sie auf das Aktionsmenü, das dritte Symbol des Services “Hardware Sensors”.

Sie sehen jetzt die deaktivierten Services für diesen Host. Diese werden über die Regel “Disabled services” gesteuert.

• Klicken Sie auf das vorderste Symbol unter Action bei Ihrer Monitoring-Regel für die Hardware Sensors. Sie erkennen die passende Regel am Text unter Conditons. In meinem Fall steht dort “Host name is muc-sr1-esxi-001.lan.domain.net Service name is Hardware Sensors”.

• Jetzt passen Sie die Regel an. Scrollen Sie nach unten und legen Sie unter Conditions fest, dass Checkmk diese Regel nicht nur auf diesen einen ESXi-Host anwendet, sondern auf alle Hosts in Ihrem ESXi-Ordner.
  • Bei Folder wählen Sie Ihren Ordner für die ESXi-Hosts, in meinem Fall “esxi”.
  • Deaktivieren Sie die Checkbox bei Explicit hosts.
• Klicken Sie auf Save.

Sie haben jetzt ein Monitoring für Ihre VMs und ESXi-Hosts eingerichtet. Checkmk verfügt jedoch noch über weitere Monitoring-Regeln, die Ihnen das VMware-Monitoring im Alltag erleichtern. Auf zwei davon möchte ich eingehen.

Im zuvor erwähnten Blog zu Namenskonzepten nutze ich einen Unterstrich als Präfix in den Display-Namen in VMware für VMs, die nicht mehr in Betrieb sind und bald gelöscht werden. Möchten Sie zum Beispiel das Testsystem “muc-vm-test-01.lan.domain.net” bald löschen, fügen Sie einen Unterstrich hinzu und der neue Display-Name wäre “_muc-vm-test-01.lan.domain.net”.

Dies ist dann auch ein Zeichen, dass diese VM ausgeschaltet sein sollte. Standardmäßig geht Checkmk davon aus, dass eine VM online ist. Mit der Regel “ESX host and virtual machine states” können Sie für ausgewählte Services die Vorgaben für Warnungen und kritische Zustände anpassen. Ich zeige Ihnen hier, wie Sie mit der Regel “ESX host and virtual machine states” die Konfiguration für alle Systeme mit einem Unterstrich anpassen.

• Klicken Sie auf Setup und suchen Sie nach “esx”. Klicken Sie auf “ESX host and virtual machine states”.
• Anschließend klicken Sie auf Add rule.
• Passen Sie bei Target states folgende Punkte an:
  • Bei Powered ON wählen Sie die Option “WARN”.
  • Bei Powered OFF wählen Sie die Option “OK”.

• Unter Conditions aktivieren Sie die Checkbox bei Name of the VM/HostSystem.
• Geben Sie im Eingabefeld “VM _” als Kondition an.
• Klicken Sie auf Save.

Durch die Regex “VM _” passt Checkmk für alle VM-Services mit dem Präfix “_” die Status-Konfiguration an. Diese sollten jetzt offline sein und Sie bekommen keine falschen Alerts in Checkmk.

In Zukunft brauchen Sie im VMware Client dann nur einen Unterstrich vor dem Display-Namen anfügen und in Checkmk eine erneute Service Discovery durchführen, wenn Sie eine VM dauerhaft offline nehmen möchten. Checkmk weiß dann Bescheid, dass der Monitoring-Service dieser VM offline sein sollte.

Dies ist natürlich nur ein Beispiel zur Anwendung dieser Regel. Genauso könnten Sie auch den Status von Replica-Servern aus VMware anpassen. Über die Option Enable timespecific parameters haben Sie außerdem die Möglichkeit, in Checkmk spezifische Zeiträume für Ihre VMs/Hosts festzulegen, etwa wenn diese im Rahmen von Wartungsfenstern geplant DOWN sind.

Die Disable-Service-Regel haben Sie bereits zuvor für den Ausschluss des Services “Hardware Sensors” eingesetzt. Ich möchte Ihnen zudem zeigen, wie Sie ungewollte Services mit nur einer Regel dauerhaft aus dem Monitoring entfernen. Der Schlüssel ist wieder ein konsistentes Namenskonzept. Bei mir sind das zum Beispiel alle VMs mit dem Präfix "#".

• Klicken Sie auf Setup. Suchen Sie nach “disable” und klicken Sie auf “Disabled services”
• Klicken Sie auf Add rule.
• Unter Conditions aktivieren Sie die Checkbox bei Services. Ich nutze die Regex “VM #”.
• Speichern Sie die Regel mit Save.

Sie haben jetzt alle VMs und ESXi-Hosts in zwei getrennten Ordnern in Ihrem Monitoring angelegt. Zu einem vollumfänglichen VMware-Monitoring gehört auch das Überwachen der Server-Hardware. Ich empfehle, die entsprechenden Informationen über das Management-Board des Servers abzufragen und für jeden Hardware-Server einen einzelnen Host zu erstellen. In meinem Fall frage ich die Daten über SNMP ab. Checkmk unterstützt aber auch die Abfrage über IPMI.

• Erstellen Sie wieder einen Ordner unter Setup und benennen ihn nach Wunsch. In meinem Beispiel nutze ich HPE-Server, daher nenne ich den Ordner “ilo”. Bei Dell heißen die Management-Boards zum Beispiel “iDRAC”.
• Unter Monitoring agents aktivieren Sie Checkmk agent / API integrations und wählen “No API integrations, no Checkmk agent”.
• Zudem aktivieren Sie die Checkbox vor SNMP und wählen Ihre SNMP-Version. Bei mir ist das “SNMP v2 or v3”.
• Speichern Sie den Ordner mit Save.

Ich nutze kein SNMPv3, sondern v2c und die Default-SNMP-Community “public” für alle meine Management-Boards. Für Checkmk ist das die standardmäßige Konfiguration. Deshalb muss ich keine weiteren Daten bei der Erstellung der Hosts mehr eingeben. Haben Sie eine andere SNMP-Community und/oder nutzen Sie SNMPv3, dann aktivieren Sie die Checkbox bei SNMP credentials und fügen die passenden Informationen hinzu.

• Klicken Sie unter Setup wieder auf Hosts und klicken Sie auf den eben erstellten Ordner.
• Jetzt klicken Sie auf Add Host, um den Host für Ihr erstes Management-Board zu erstellen.
• Fügen Sie unter Hostname den Namen Ihres Management-Boards ein. In meinem Fall “muc-sr1-esxi-001-ilo.lan.domain.net".
• Klicken Sie Save & go to service configuration, warten Sie die Service-Erkennung ab.
• Klicken Sie auf Accept all.
• Wiederholen Sie den Vorgang für jeden Hardware-Server mit einem Management-Board.

Da Sie die passende Konfiguration im Ordner bereits hinterlegt haben, erben alle Hosts die passenden Einstellungen. Nutzen Sie verschiedene SNMP-Communities für Ihre Management-Boards, müssen Sie diese bei der Aufnahme der einzeln Hosts hingegen individuell konfigurieren. Eine Konfiguration über den Ordner spart Zeit.

Sie sehen, dass sich einige Änderungen im Monitoring angesammelt haben. Sie sollten die Änderungen in Checkmk akzeptieren:

• Gehen Sie wieder auf das gelbe Symbol oben in der rechten Ecke, um dann erneut die “pending changes” mit einem Klick auf Activate on selected sites zu aktivieren.

Die Host-Ansicht des Hardware-Servers sieht in meinem Monitoring zum Beispiel so aus:

An dieser Stelle möchte ich Ihnen außerdem noch zeigen, wie Sie sämtliche Backups Ihrer VMs überwachen können. Ich nutze Veeam als Backup-Lösung und habe einen Hardware-Backup-Server mit dem Namen “muc-sr2-veeam-001.lan.domain.net” aufgesetzt. Ich nutze das Checkmk Agentenplugin für Veeam:

• Fügen Sie Ihren Backup-Server als Host zum Monitoring hinzu. Gehen Sie dazu auf Setup und klicken Sie auf Add host.
• Geben Sie als Hostname Ihren Backup-Server-Namen ein. In meinem Fall “muc-sr2-veeam-001.lan.domain.net”.
• Klicken Sie Save & go to folder.
• Klicken Sie wieder auf Setup. Suchen Sie nach “veeam”. Klicken Sie auf “Veeam Backup Status (Windows)”.
• Unter Conditions sollten Sie diese Regel an Ihren Backup-Server binden, in meinem Fall wähle ich unter Explicit hosts daher “muc-sr2-veeam-001.lan.domain.net”. Sie können sonst alle Einstellungen belassen.
• Speichern Sie die Regel mit Save.

• Jetzt gehen Sie auf Setup -> Agents -> Windows, Linux, Solaris, AIX.
• Sie sehen an dem orangen Knopf, dass die Agentenbäckerei von Checkmk bereit ist, einen Agenten für Sie zu backen. Klicken Sie auf “Bake agents”.

• Warten Sie, bis der Agent fertig gebacken ist und als Auswahlmöglichkeit erscheint. Laden Sie dann den Windows-Agenten mit dem konfigurierten Veeam-Plugin herunter.

• Installieren Sie den Agenten auf Ihrem Veeam-Server.
• Sobald der Agent installiert ist, gehen Sie zu Setup -> Hosts und wählen den Host Ihres Veeam-Servers. Starten Sie die automatische Service-Erkennung für Ihren Veeam-Server.
• Klicken Sie auf Accept all.

Das Veeam-Plugin überwacht nicht nur die Veeam-Jobs auf dem Veeam-Server, sondern überträgt auch Services als Piggyback-Daten zu den passenden VM-Hosts. Damit Checkmk den Service “Veeam Client” für jeden VM-Host in die Überwachung aufnimmt, müssen Sie für alle VM-Hosts die Service-Erkennung starten. Das geht am einfachsten mit einer “Bulk Discovery” für Ihren VM-Ordner.

• Gehen Sie zu Setup -> Hosts und öffnen Sie Ihren VM-Ordner. In meinem Fall heißt der “vm”.
• Klicken Sie in der oberen Menüleiste auf Hosts. Wählen Sie “Discover services”.

• Im Fenster Bulk discovery können Sie sämtliche Default-Werte übernehmen und klicken auf “Start”.
• Nach der Service-Erkennung sehen Sie eine Zusammenfassung im Fenster Background job details. Checkmk sollte einige neue Services für Ihre VMs erkannt haben.
• Nehmen Sie wieder die “pending changes” an.

Checkmk überwacht jetzt die Funktion von Veeam, aber erfasst zudem auch die passenden Piggyback-Daten vom Veeam-Host und verteilt diese an die VM-Hosts in Checkmk.

In der Host-Ansicht meines vCenter-Servers taucht jetzt zum Beispiel der Backup-Service auf. Checkmk erkennt, dass Veeam seit 40 Stunden keine Sicherungskopie gemacht hat.