Microsoft Azure überwachen

Registrieren Sie zunächst eine App in Azure. Über diese App wird Checkmk die gewünschten Daten aus Azure auslesen. Sie finden die Option dafür im Azure-Portal unter (All services > Identity > Identity management > ) App registrations. Alternativ können Sie hier die Suche des Portals verwenden und dort App registrations eingeben. Auf der Seite angekommen, müssen Sie nun auf New registration klicken.

Vergeben Sie einen Namen Ihrer Wahl. Im Beispiel verwenden wir my-checkmk-app. Der Name ist jedoch nur informativ. Der Bezug auf die App wird stattdessen über eine UUID hergestellt, die Sie in einem nächsten Schritt angezeigt bekommen. Im Abschnitt Supported account types müssen Sie nichts ändern und das Feld Redirect URI muss leer bleiben. Bestätigen Sie Ihre Eingaben mit einem Klick auf Register.

Nachdem Sie die App angelegt haben, sollten Sie in einer Übersicht zu dieser neuen App landen. Ist dem nicht so, finden Sie die neue App in der oben beschriebenen Liste aller App registrations im Reiter All applications. In den Details der App finden Sie nun sowohl die Application (client) ID als auch die Directory (tenant) ID, welche Sie später in Checkmk eintragen müssen.

Nun brauchen Sie noch einen geheimen Client-Schlüssel (im Englischen schlicht client secret genannt), mit dem sich Checkmk bei der API von Azure anmelden kann. Um einen solchen Schlüssel zu erzeugen, klicken Sie in der Übersicht der App auf Certificates & secrets, dann auf den Reiter Client secrets und schließlich auf New client secret.

Dadurch öffnet sich der Dialog Add a client secret. Vergeben Sie einen beliebigen Namen und wählen Sie aus, wie lange der Schlüssel gültig sein soll. Wenn Sie später, in der Regel für den Spezialagenten, die Option App Registrations aktiveren, bekommen Sie einen praktischen Service, der Sie daran erinnert, wenn sich diese Gültigkeitsdauer dem Ende nähert. Bestätigen Sie den Dialog mit einem Klick auf Add.

Jetzt ist es wichtig, dass Sie den Value dieses neuen Schlüssel umgehend kopieren. Nach einer gewissen Zeit werden im Azure-Portal nur noch die ersten drei Zeichen solcher Schlüssel angezeigt.

Sie müssen der App zusätzliche API-Berechtigungen erteilen, wenn Sie die folgenden Services mit Checkmk überwachen möchten:

Die Vergabe der Berechtigungen starten Sie in der Übersicht Ihrer neuen App, die Sie noch vom vorherigen Abschnitt geöffnet haben sollten.

Klicken Sie auf API permissions und anschließend auf Add a permission. In dem Dialog, der sich öffnet, müssen Sie den Punkt Microsoft Graph finden und anklicken. Wählen Sie anschließend Application permissions und tippen Sie Directory.Read.All in die Suche ein. Aktivieren Sie die zugehörige Checkbox und klicken Sie auf Add permissions. Für diese Berechtigung wird eine zusätzliche Zustimmung durch einen Administrator Ihrer Azure-Umgebung benötigt (Admin consent required.) Wenn Sie über der Liste der erteilten Berechtigungen nicht den Knopf Grant admin consent sehen, müssen Sie sich an einen solchen Admin wenden.

Damit Checkmk über die neue App an die Monitoring-Daten kommen kann, müssen Sie der App noch eine Rolle auf Ebene der Subskription zuweisen. Wählen Sie dazu in der Hauptnavigation auf der linken Seite den Punkt All services und dann unter General den Punkt Subscriptions. Auch hier können Sie wieder die Suche im Portal bemühen, wenn sich der entsprechende Knopf nicht finden lässt.

Eventuell müssen Sie nun noch den Namen der Subskription anklicken, den Sie überwachen möchten. In der folgenden Übersicht finden Sie auch die Subscription ID, die Sie später in die Regel des Spezialagenten eintragen müssen. Sobald diese notiert ist, klicken Sie auf Access Control (IAM) und dort auf Add und dann auf Add role assignment:

Wählen Sie jetzt die Rolle aus, die Reader heißt und den Type BuiltInRole hat. Da es insgesamt über 100 Rollen gibt, die das Wort Reader im Namen tragen, gilt es hier aufmerksam zu sein. Klicken Sie anschließend auf Next, um zum Reiter Members zu kommen.

Klicken Sie hier auf + Select members.

Im Dialog Select members geben Sie im Suchfeld den Namen der App ein, wie Sie ihn vorhin angelegt haben, wählen die App aus und klicken auf Select. Nach zwei weiteren Klicks auf Review + assign ist die Einrichtung im Azure-Portal abgeschlossen.

Sie sollten jetzt über die folgenden vier Informationen verfügen:

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 Ziel-Host 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:

Wenn Sie über Azure virtuelle Maschinen überwachen, welche Sie gleichzeitig als normale Hosts 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.