Microsoft Azure überwachen

Um Azure mit Checkmk zu überwachen, benötigen Sie Ihre Subskriptions-ID und Ihre Tenant-ID (auch bekannt als „Directory-ID“).

Registrieren Sie zunächst das Checkmk-Monitoring als App, damit Sie mit der API von Azure arbeiten können. Sie finden die Option dafür im Azure-Portal unter Microsoft Entra ID > Manage > App registrations > New registration:

Vergeben Sie einen Namen Ihrer Wahl. Im Beispiel verwenden wir my-check-mk-app. Der Name ist jedoch nur informativ. Der Bezug auf die App wird stattdessen über eine UUID hergestellt, die Sie in einem späteren Schritt angezeigt bekommen. Im Abschnitt Supported account types müssen Sie nichts ändern. Die Redirect URI können Sie optional setzen.

Wählen Sie nach dem Anlegen die neue App in der Liste der Apps aus. Wenn diese in der Liste nicht angezeigt wird, dann stellen Sie die Auswahl My apps auf All apps um. In den Details der App finden Sie auch die Application (client) ID, welche Sie später benötigen. Die Object-ID ist nicht notwendig.

Damit Ihre neue App Zugriffsrechte auf die Monitoring-Daten bekommt, müssen Sie diese hier vergeben. Wählen Sie dazu in der Hauptnavigation auf der linken Seite den Punkt All resources und hierin den Punkt Subscriptions:

In der Navigation dieser Seite gehen Sie auf Access Control (IAM) und dort auf Add und Add role assignment:

Tragen Sie nun die Rolle Reader, bei Assign access to den Wert Azure AD user, group, or service principal und bei Select den Namen Ihrer neuen App ein:

Nun brauchen Sie noch einen Schlüssel (ein Secret), mit dem sich Checkmk bei der API anmelden kann. Diesen legen Sie bei den Eigenschaften der App unter Certificates & secrets an. Der Eintrag dazu heißt Client secrets. Wir wählen hier New client secret.

Microsoft möchte im folgenden Fenster, dass Sie in das Feld Description einen Namen Ihrer Wahl eintragen. Wir wählen hier my-check-mk-key. Vergessen Sie nicht, bei Expires eine für Sie passende Wahl zu treffen.

Die Einrichtung unter Azure ist nun abgeschlossen und Sie sollten jetzt über die folgenden vier Informationen verfügen:

Falls Sie Ihre Tenant-ID nicht zur Hand haben, finden Sie diese, wenn Sie mit der Maus über Ihren Login-Namen fahren, im Tooltipp unter Directory:

Die Subskriptions-ID können Sie z.B. auf der Seite Cost Management + Billing unter My subscriptions einsehen. Hinweis: Microsoft zeigt inzwischen nicht mehr einen Hash, sondern einen von Menschen lesbaren Namen als ID an. Sie können diesen ganz normal nutzen.

Auch wenn Sie es bei Azure nicht mit einem physikalischen Host zu tun haben, legen Sie in Checkmk für Ihr Azure-Directory einen Host an. Den Host-Namen können Sie nach Belieben vergeben. Wichtig: Da Azure ein Dienst ist und daher keine IP-Adresse oder DNS-Namen hat (den Zugriff macht der Spezialagent von selbst), müssen Sie die IP address family auf No IP einstellen.

Speichern Sie am besten mit Save & Finish, da die Service-Erkennung natürlich noch nicht funktionieren kann.

Da Azure nicht über den normalen Checkmk-Agenten abgefragt werden kann, richten Sie jetzt den Spezialagenten für Azure ein, welcher auch als Datenquellenprogramm bezeichnet wird. Hierbei kontaktiert Checkmk den Zielhost nicht wie üblich über TCP Port 6556, sondern ruft stattdessen ein Hilfsprogramm auf, welches mit dem Zielsystem über ein die anwendungsspezifische API von Azure kommuniziert.

Dazu legen Sie unter Setup > Agents > VM, Cloud, Container > Microsoft Azure eine Regel an, deren Bedingungen ausschließlich auf den gerade angelegten Azure-Host greifen. Dort finden Sie die Eingabefelder für die IDs und das Secret:

Hier können Sie auch die Ressourcengruppen oder Ressourcen auswählen, die Sie überwachen möchten. Wenn Sie explicitly specified groups nicht angekreuzt haben, werden automatisch alle Ressourcengruppen überwacht.

Wenn Sie jetzt eine Service-Erkennung auf dem Azure-Host machen, sollte auf diesem ein einziger Service mit dem Namen Azure Agent Info erkannt werden:

Falls der Zugriff auf die API nicht klappt (z.B. wegen einer falschen ID oder fehlerhaften Berechtigungen), erscheint im Statustext von Azure Agent Info eine Fehlermeldung der Azure-API:

Aus Gründen der Übersichtlichkeit ist das Azure-Monitoring von Checkmk so aufgebaut, dass jede Azure-Ressourcengruppe durch einen (sozusagen logischen) Host im Checkmk repräsentiert wird. Dies geschieht mit Hilfe des Piggyback-Verfahrens. Dabei werden Daten, die vom Azure-Host per Spezialagenten abgerufen werden, innerhalb von Checkmk an diese Ressourcengruppen-Hosts umgeleitet.

Die Ressourcengruppen-Hosts erscheinen nicht automatisch im Checkmk. Legen Sie diese Hosts entweder von Hand an oder optional mit dem Dynamic Configuration Daemon (DCD). Wichtig dabei ist, dass die Namen der Hosts exakt mit den Namen der Ressourcengruppen übereinstimmen — und zwar auch die Groß-/Kleinschreibung! Wenn Sie sich über die genaue Schreibung der Gruppen unsicher sind, können Sie diese direkt aus dem Service Azure Agent Info auf dem Azure-Host ablesen.

Übrigens: mit dem Hilfsskript find_piggy_orphans aus dem treasures-Verzeichnis finden Sie alle Piggyback Hosts, für es Daten gibt, die aber noch nicht als Host im Checkmk angelegt sind:

Konfigurieren Sie die Ressourcengruppen-Hosts ohne IP-Adresse (analog zum Azure-Host) und wählen Sie als Agent No API integrations, no Checkmk agent und als Piggyback Always use and expect piggyback data aus.

Wenn Sie jetzt die Service-Erkennung zu einem dieser Ressourcengruppen-Hosts machen, finden Sie dort weitere Services, welche speziell diese Ressourcengruppe betreffen:

Tipp: Wenn Sie die Namen der Ressourcengruppen-Hosts frei wählen möchten, können Sie mit der Regel Setup > Agents > Access to Agents > Hostname translation for piggybacked hosts eine Umrechnung von Ressourcengruppen zu Hosts definieren.

Wenn Sie über Azure virtuelle Maschinen überwachen, welche Sie gleichzeitig als normale Host in Checkmk haben, können Sie die Azure-Services, welche sich auf diese VMs beziehen, anstelle zu den Ressourcengruppen-Hosts direkt zu den VM-Hosts in Checkmk zuordnen lassen.

Wählen Sie dazu in der Azure-Regel bei der Option Map data relating to VMs die Einstellung Map data to the VM itself. Damit dies funktioniert, muss der Checkmk-Host der VM im Monitoring den exakt gleichen Namen haben wie die entsprechende VM in Azure.

Die Regel Microsoft Azure ist so voreingestellt, dass Checkmk auch alle Kosten, die in Ihrer Azure-Umgebung anfallen, überwacht. Konkret zeigen die Services die Kosten an, welche am Vortag angefallen sind. Auf diese Weise erkennen Sie schnell, wenn es hier zu Veränderungen gekommen ist.

Um eine bessere Übersicht zu erhalten, wo genau Kosten entstanden sind und um gezielt Schwellwerte setzen zu können, werden mehrere Services erzeugt. Die Gesamtkosten auf Ebene Ihres Azure-Directorys, werden bei dem Azure-Host angezeigt, den sie zuerst angelegt haben. Zusätzlich werden Services für jeden Host erzeugt, der eine Ressourcengruppe repräsentiert. Auf beiden Ebenen erzeugt Checkmk pro sogenanntem „Resource Provider“ (bspw. microsoft.compute and microsoft.network) einen Service für die Kosten. Die Gesamtsumme für die Ressourcengruppe bzw. das gesamte Azure-Directory zeigt dann der Service Costs Summary.

Für all diese Services können Sie mit der Regel Azure Usage Details (Costs) individuelle Schwellwerte festlegen.

Sollten Sie keine Kostenüberwachung wünschen, müssen Sie in der Regel Microsoft Azure die Option Usage Details deaktivieren.

Stand heute sind die API-Abfragen, die Checkmk zum Monitoring benötigt, bei Azure kostenlos (im Gegensatz zu AWS). Allerdings gibt es eine Begrenzung in der Anzahl der Abfragen pro Zeit („Rate-Limit“). Pro Application-ID liegt die Grenze bei 12.000 Leseabfragen pro Stunde.

Aufgrund der Bauart der API benötigt Checkmk pro abgefragte Ressource mindestens eine oder mehrere Abfragen. Daher skaliert die Gesamtzahl der benötigten Abfragen linear mit der Anzahl der überwachten Ressourcen. Wird das Rate-Limit erreicht oder überschritten, scheitert die Abfrage mit einem HTTP-Code 429 (Too many requests) und der Check_MK Service des Azure-Hosts geht auf CRIT.

Das Rate-Limit ist von Azure als sogenannter „Token Bucket“ Algorithmus realisiert. Alles beginnt damit, dass Sie ein „Guthaben“ von 12.000 verbleibenden Abfragen haben. Jede Abfrage verbraucht davon einen. Gleichzeitig kommen 3,33 Abfragen pro Sekunde zum Guthaben dazu. In der Ausgabe des Services Azure Agent Info sehen Sie, wie viele Abfragen aktuell noch übrig sind.

Konkret bedeutet das:

In diesem Fall können Sie die Abfragerate reduzieren, indem Sie weniger Ressourcengruppen oder Ressourcen abfragen oder indem Sie das Check-Intervall des aktiven Checks Check_MK auf dem Azure-Host reduzieren. Dies geht mit der Regel Normal check interval for service checks.

Damit Sie rechtzeitig reagieren können, überwacht der Service Azure Agent Info die Anzahl der verbleibenden Abfragen und warnt Sie rechtzeitig vorher. Per Default ist die Warnschwelle bei 50 % und die kritische Schwelle bei 25 % verbleibender Abfragen.