Überwachen von Microsoft Azure

Check_MK Manual
Letzte Aktualisierung: 14. Februar 2019

Suche im Handbuch

1. Einleitung

Azure ist Microsofts Antwort auf die Cloud und ermöglicht Benutzern die Nutzung der Ansätze der Infrastructure as a Service (IaaS), Platform as a Service (PaaS) und Software as a Service (SaaS).

Auch wenn einem Microsoft das Betreiben der entsprechenden Hard- und Software­komponenten abnimmt, ist ein eigenes Monitoring hier trotzdem nötig und sinnvoll. Allerdings muss dies auf andere Art erfolgen als mit einem normalen Check_MK-Agenten.

Ab Version 1.5.0p12 unterstützt Check_MK das Überwachen von Azure durch einen eigenen Spezialagenten sowie eine Reihe von Checkplugins. Aktuell sind dies die folgenden:

Da wir die Unterstützung des Azure-Monitorings fortlaufend weiterentwickeln, werden weitere Plugins hinzukommen. Bitte beachten Sie auch, dass bis zur Version 1.6.0 noch strukturelle Änderungen an der Umsetzung möglich sind und Sie daher Ihre Konfiguration eventuell nocheinmal anpassen müssen.

2. Azure für Check_MK vorbereiten

2.1. App anlegen

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

Registrieren Sie zunächst das Check_MK-Monitoring als App, damit Sie mit der API von Azure arbeiten können. Sie die Option dafür im Azure-Portal unter Azure Active Directory ➳ App registration ➳ New application registration:

Vergeben Sie einen Namen Ihrer Wahl. Im Beispiel verwenden wir my-check-mk-app. Dieser ist jedoch nur informativ. Der Bezug auf die App wird stattdessen über eine UUID hergestellt, die Sie in einem späteren Schritt angezeigt bekommen. Der Application type muss auf Web app / API eingestellt bleiben. Die Home page ist wie der Name nur informativ. Geben Sie am besten die URL an, unter der man Ihren Check_MK-Server erreicht.

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-ID, welche Sie später benötigen. Die Object-ID ist nicht notwendig.

2.2. Rechtevergabe für die App

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

Wählen Sie hier in der Liste Ihre Subskription aus. In der Navigation dieser Seite gehen Sie auf Access Control (IAM) und dort auf 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:

2.3. Schlüssel für die App anlegen

Nun brauchen Sie noch einen Schlüssel (ein Secret), mit dem sich Check_MK bei der API anmelden kann. Diesen legen Sie bei den Eigenschaften der App wieder unter Settings an. Der Eintrag dazu heißt Keys. Ausnahmsweise finden Sie hier keinen Knopf zum Hinzufügen oder dergleichen. Zur Abwechslung möchte Microsoft hier von Ihnen, dass Sie in das Feld Key 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.

Der Knopf Save ist nun blau geworden. Speichern Sie damit. Jetzt bekommen Sie den Schlüssel angezeigt:

Achtung: der Hinweis Copy the key value. You won't be able to retrieve after you leave this blade. ist ernst gemeint. Dies ist der einzige Zeitpunkt, wo der Schlüssel jemals angezeigt wird! Kopieren Sie diesen also für später.

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

  1. Ihre Subskriptions-ID
  2. Ihre Tenant-ID (auch bekannt als „Directory-ID“).
  3. Die Application-ID (Client-ID) der App my-check-mk-app
  4. Das Geheimnis des Keys my-check-mk-key zu dieser App

Falls Sie Ihrer Tenant-ID nicht zur Hand haben, finden Sie diese wenn Sie mit der Maus über Ihren Loginnamen fahren im in der aufpoppenden Hilfe unter Directory: Standardverzeichnis....:

Die Subscriptions-ID können Sie z. B. auf der Seite Cost Management + Billing unter My subscriptions einsehen.

3. Überwachung in Check_MK einrichten

3.1. Azure-Host

Auch wenn Sie es bei Azure nicht mit einem physikalischen Host zu tun haben, legen Sie in Check_MK für Ihr Azure-Directory einen Host an. Den Hostnamen 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 Spezial-Agent von selbst), müssen Sie die IP Address Family auf auf No IP einstellen.

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

3.2. Den Azure-Agent konfigurieren

Da Azure nicht über den normalen Check_MK-Agenten abgefragt werden kann, richten Sie jetzt den Azure-Spezialagenten ein, welcher auch als Datenquellenprogramm bezeichnet wird. Hierbei kontaktiert Check_MK 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 Host & Service Parameters ➳ Datasource Programs ➳ 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 explicitely specified groups nicht angekreuzt haben, werden automatisch alle Ressourcegruppen überwacht.

3.3. Test

Wenn Sie jetzt eine Serviceerkennung 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:

3.4. Ressourcegruppen als Hosts verfügbar machen

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

Die Ressourcegruppen-Hosts erscheinen nicht automatisch im Check_MK. Legen Sie diese Hosts entweder von Hand an oder – ab Version 1.6.0 -- optional mit dem neuen Dynamic Configuration Daemon (DCD). Wichtig dabei ist, dass die Namen der Hosts exakt mit den Namen der Ressourcegruppen ü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 Piggyhosts, für es Daten gibt, die aber noch nicht als Host im Check_MK angelegt sind:

OMD[mysite]:~$ share/doc/check_mk/treasures/find_piggy_orphans
Glastonbury
Woodstock

Konfigurieren Sie die Ressourcegruppen-Hosts ohne IP-Adresse (analog zum Azure-Host) und wählen Sie als Agent No Agent aus.

Wenn Sie jetzt die Serviceerkennung zu einem dieser Ressourcegruppen-Hosts machen, finden Sie dort weitere Services, welche speziell diese Ressourcegruppe betreffen:

Andere Namen für die Ressourcengruppen-Hosts wählen

Tipp: Wenn Sie die Namen der Ressourcengruppen-Hosts frei wählen möchten, können Sie mit der Regel Host & Service parameters ➳ Access to agent ➳ Hostname translation for piggybacked hosts eine Umrechnung von Ressourcengruppen zu Hosts definieren.

3.5. Virtuelle Maschinen (VMs)

Wenn Sie über Azure virtuelle Maschinen überwachen, welche Sie gleichzeitig als normale Host in Check_MK haben, können Sie die Azure-Services, welche sich auf diese VMs beziehen, anstelle zu den Ressourcegruppen-Hosts direkt zu den VM-Hosts in Check_MK 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 Check_MK-Host der VM im Monitoring den exakt gleichen Namen haben wie die entsprechende VM in Azure.

3.6. Rate-Limit der API-Abfragen

Stand heute sind die API-Abfragen, die Check_MK 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 Check_MK 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 Ratelimit erreicht oder überschritten, scheitert die Abfrage mit einem HTTP-Code 429 (Too many requests) und der Check_MK-Service des Azure-Hosts geht auf kritisch.

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, wieviele Abfragen aktuell noch übrig sind.

Konkret bedeutet das:

  • Wenn Ihre Abfragerate ausreichend klein ist, sind die verfügbaren Abfragen immer knapp unter 12.000.
  • Wenn Ihre Rate zu hoch ist, sinkt das Guthaben langsam auf 0 und es werden dann sporadisch Fehler bei der Abfrage auftreten.

In diesem Fall können Sie die Abfragerate reduzieren, indem Sie weniger Ressourcegruppen oder Ressourcen abfragen oder indem Sie das Check-Intervall des aktiven Checks Check_MK auf dem Azure-Host reduzieren. Dies geht mit der Regel Monitoring Configuration ➳ 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.