Verteiltes Monitoring: Remote-Sites in Checkmk anbinden

Das verteilte Monitoring oder auch Distributed Monitoring mit Checkmk besteht aus einer zentralen Instanz bzw. Central Site und mindestens einer Remote-Instanz bzw. Remote Site. Der Aufbau eines solchen Distributed Monitorings, insbesondere die darin beinhaltete Anbindung der Remote-Sites, ist im Wesentlichen ein klassisches Netzwerkthema. Jedoch ist es notwendig, die Eigenschaften von Checkmk dabei zu berücksichtigen.

In diesem Artikel gehe ich von einem einfachen Setup eines verteilten Monitorings aus, bestehend aus einer Central Site und mehreren Remote Sites inklusive Synchronisation der Konfiguration. Zudem beschränken wir uns in diesen Best Practices für die Anbindung von Remote-Sites auf IPv4, da Unternehmen derzeit erfahrungsgemäß entweder ein reines IPv4-Intranet oder ein Dual-Stack-Intranet mit IPv4 und IPv6 betreiben – jedoch kein reines IPv6-Intranet.

Das einfachste Fallbeispiel ist ein flaches Netzwerk, in dem das Routing zwischen den Hosts funktioniert, auf denen die Checkmk-Sites laufen. Dies ist vor allem das typische Setup in einer kleinen Organisation ohne Niederlassungen, sodass in der Regel kein verteiltes Monitoring notwendig ist.

Firmen mit Niederlassungen betreiben in der Regel ein unternehmensweites VPN, das in der Regel durch eine zentrale IT mindestens orchestriert wird. Das heißt, dass sie den einzelnen Standorten ein exklusives Subnetz zuordnet, was wiederum ein einfaches Routing erlaubt. Ein verteiltes Monitoring ist in einem solchen Netzwerk nicht zwingend nötig. Sollten die Niederlassungen über wenige Geräte verfügen (Daumenregel: einstellige Geräteanzahl) oder ohne Hypervisor auskommen, verzichtet man in der Regel auf Remote-Sites.

Site2Site-VPN

Bei einem Managed Service Provider sieht das schon wieder anders aus. Hier bestehen in der Regel mehrere unterschiedliche Anbindungen an Kundennetzwerke. Eine typische Anbindungsart ist Site2Site-VPN, das an einer dedizierten Firewall für Kundenanbindungen anlandet. Ein allgemeines Problem ist in diesem Fall, dass die Kundennetzwerke private IPv4-Bereiche haben, die sich überlappen. Ein direktes Routing in diese privaten Netzwerke ist also im Allgemeinen nicht möglich. Hilfsweise lässt sich hier mit NAT (Network Address Translation) arbeiten.

Eine weitere typische Anbindungsart ist DNAT (Destination Network Adress Translation) auf der Kunden-Firewall, also ohne VPN-Anbindung zum Kunden. Dabei leitet man dedizierte Highports auf der Kunden-Firewall zum Remote-Site-Host weiter. Die Quell-IPs werden auf ein kleinstmögliches Netz des MSPs beschränkt; nur eingehende Verbindungen werden gebraucht. Praktisch kann dies folgendermaßen aussehen:

Die Highports auf der Firewall sind in diesem Beispiel auf die für Checkmk typische Dekade 655x gelegt. Die letzte Ziffer korreliert mit dem Verbindungstyp.

Der große Vorteil dieser Variante ist, dass Überlappungen von Kundennetzen egal sind, also der Dienstleister standardisierte Intranet-Installationen ausrollen kann.

Der Host der Remote Site sollte hinreichend detailliert als Status-Host abgefragt werden, auch wenn sich bei der Nutzung von Live-Proxy auf die Konfiguration eines Status-Hosts in den Site-Einstellungen verzichten lässt. Dazu tunnelt man wie im Beispiel die Agentenausgabe über SSH – und verzichtet damit auf eine weitere DNAT-Verbindung. Das Host-Check-Command sollte entsprechend auf den Status des Checkmk-Services umgestellt werden.

Die optionale Notification Connection dient dazu, Benachrichtigungen zentral zu verarbeiten, etwa in einem zentralen Ticketsystem des MSPs. Derzeit bringt Checkmk hier keine Verschlüsselungslösung mit; dies soll sich erst zur nächsten Version ( Checkmk 2.1) ändern. In der Zwischenzeit kann jedoch beispielsweise Stunnel eine Lösung sein.

DNAT für ein robustes MSP-Monitoring

Für ein robustes und heterogenes MSP-Monitoring bietet sich an, standardmäßig DNAT einzusetzen. Sollten einzelne Kunden auf VPN mit inkompatiblen Kundennetzwerken bestehen, sind Lösungen denkbar, die zusätzlich zwischengelagerte Hosts beinhalten. Dabei kann dieser intermediäre Host, der sich im Rechenzentrum des Providers befindet, über VPN mit dem Remote-Site-Host beim Kunden kommunizieren. Diese Verbindung bietet der intermediäre Host der Zentral-Site über Port-Forwarding an.

Die bisher besprochenen Ansätze haben stets vorausgesetzt, dass ein Zugriff von einem Adressbereich des MSP, initiiert durch die zentrale Checkmk Site, möglich und erlaubt ist. Dies kann aus Sicherheitsgründen jedoch in manchen Fällen nicht erwünscht sein. Dafür bietet sich die Methode CMCDump an, die wiederum Einschränkungen mit sich bringt.

Bei dieser Methode erstellt ein CronJob im definierten Zeitintervall, etwa jede Minute, ein Archiv des aktuellen Gesamtstatus. Anschließend wird diese erstellte Archivdatei an die Central Site übermittelt und dort eingespielt. Voraussetzung für CMCDump ist jedoch, dass ausgehender Verkehr erlaubt ist und dieser zudem geeignet ist, die Archivdatei, etwa ein .tgz, zu transportieren. Die Übertragung lässt sich etwa über scp zu einem File-Host oder via E-Mail realisieren. Die individuelle Transportlösung muss man jedoch skripten.

Es lässt sich festhalten, dass je nach Rahmenbedingungen beliebig komplexe Lösungen nötig sein können. Managed Service Providern sei an dieser Stelle empfohlen, mögliche Realisierungsvarianten und -voraussetzungen vorab festzulegen sowie diese hinreichend zu dokumentieren und zu kommunizieren, um Extrawürste bei Kunden zu vermeiden.