Checkmk
to checkmk.com

1. Einleitung

logo aws

Checkmk enthält ein umfangreiches Monitoring von Amazon Web Services (AWS), welches aus einem Konnektor zu AWS und einer stattlichen Sammlung von Check-Plugins besteht, die für Sie verschiedenste Metriken und Zustände abrufen und auswerten.

Neben den allgemeinen Informationen zu den Kosten Ihrer AWS-Umgebung und dem aktuellen Status der AWS-Dienste in Ihrer Region, können Sie mit allen Editionen von Checkmk die folgenden AWS-Produkte überwachen:

Mit der CSE Checkmk Cloud Edition können Sie darüber hinaus noch die folgenden Produkte in Ihr Monitoring aufnehmen:

Eine vollständige Auflistung aller verfügbaren Check-Plugins für die Überwachung von Amazon Web Services finden Sie in unserem Katalog der Check-Plugins und wie Sie Ihre Amazon-EKS-Cluster (Amazon Elastic Kubernetes Service) ins Monitoring aufnehmen, beschreiben wir im Artikel Kubernetes überwachen.

2. Konkrete Umsetzung der AWS-Überwachung

2.1. Hosts und Services

In Checkmk ordnen sich alle zu überwachenden Objekte in eine hierarchische Struktur von Hosts und Services ein. Nun gibt es bei Cloud-basierten Diensten das Konzept von Hosts nicht. Um die Einfachheit und Konsistenz von Checkmk zu bewahren, bilden wir dennoch AWS-Objekte auf das Schema Host/Service ab.

Wie das geht, zeigt am besten ein Beispiel: In einer Region sind mehrere EC2-Instanzen konfiguriert. Einer EC2 sind üblicherweise EBS zugeordnet. Diese Konstellation sieht in Checkmk wie folgt aus:

  • Es gibt einen Host, der dem AWS-Account entspricht. Dieser gibt eine Übersicht aller EC2-Instanzen und deren Status als Service.

  • Die EC2-Instanzen selbst sind wiederum eigene Hosts.

  • Auf diesen EC2-Hosts finden Sie Services mit den eigentlichen Metriken.

  • Die EBS werden als eine Art Festplatten interpretiert und liefern dementsprechend Metriken zu I/O (z.B. gelesene oder geschriebene Anzahl an Bytes). Dazu existieren in Checkmk eigene Services mit dem Namen AWS/EBS Disk IO pro EBS, die der EC2-Instanz zugeordnet werden.

2.2. Zugriff auf AWS

AWS stellt eine HTTP-basierte API bereit, über die auch Monitoring-Daten abrufbar sind. Checkmk greift auf diese API über den Spezialagenten agent_aws zu, welcher an die Stelle des Checkmk-Agenten tritt, aber anders als dieser lokal auf dem Checkmk-Server ausgeführt wird.

3. AWS für Checkmk vorbereiten

3.1. Benutzer anlegen

Um die Überwachung per Checkmk zu ermöglichen, legen Sie am besten dafür einen speziellen AWS-Benutzer unterhalb Ihres Root-Accounts an. Loggen Sie sich dafür bei AWS als Root-Benutzer ein und navigieren Sie unter All services zu Security, Identity, & Compliance > IAM (Identity and Access Management). Gehen Sie hier auf Users und legen Sie mit Add user einen neuen Benutzer an. Als Benutzername wählen Sie z.B. check-mk. Wichtig ist, dass Sie bei Select AWS credential type den Access key - Programmatic access auswählen.

aws create user

3.2. Berechtigungen

Der soeben angelegte Benutzer sollte nur für das Monitoring durch Checkmk verwendet werden und benötigt ausschließlich lesenden Zugriff auf AWS. Wir empfehlen diesem Benutzer ausschließlich die Policy ReadOnlyAccess zuzuweisen. Um diese Policy zu finden, klicken Sie zuerst auf Attach existing policies directly und geben anschließend readonlyaccess in das Suchfeld ein. In der Liste unter dem Suchfeld müssen Sie dennoch weit nach unten scrollen, da es eine ganze Reihe Policies gibt, die diesen String enthalten:

aws create user policies

3.3. Schlüssel

Nach dem Abschluss des Anlegens des Benutzers wird für Sie automatisch ein Zugangsschlüssel erzeugt. Achtung: Das Secret des Schlüssels wird nur ein einziges Mal — direkt nach dem Erzeugen — angezeigt. Kopieren Sie daher unbedingt den Schlüssel und legen ihn z.B. im Checkmk-Passwortspeicher ab. Alternativ geben Sie ihn im Klartext in der Regel an (siehe unten). Für Checkmk benötigen Sie neben dem Secret noch die Access key ID. Der Name des Benutzers (bei uns check-mk) spielt hier keine Rolle.

aws create user key

Falls Sie das Secret trotzdem einmal verlieren sollten, können Sie für den Benutzer einen neuen Access Key anlegen und bekommen ein neues Secret:

aws create access key

3.4. Zugriff auf Billing-Informationen

Wenn Sie möchten, dass Checkmk auch Lesezugriff auf die Abrechnungsinformationen bekommt (um den globalen Check Costs and Usage ausführen zu können), benötigen Sie für Ihren AWS-Benutzer eine weitere Richtlinie (policy), die Sie allerdings erst selbst definieren müssen.

Wählen Sie dazu unter Security, Identity, & Compliance > IAM > Policies den Knopf Create Policy. Wählen Sie unter Select a Service > Service > Choose a Service den Service Billing aus. Unter Actions kreuzen Sie die Checkbox Read an. Sie müssen noch eine weitere Berechtigung setzen. Fügen Sie diese mit dem Knopf Add additional permissions hinzu. Wählen Sie in der neuen Box unter Select a Service > Service > Choose a Service den Service Cost Explorer Service aus. Unter Actions kreuzen Sie die Checkbox Read an.

aws policies

Mit dem Knopf Review geht es zum Schritt zwei. Legen Sie dort als Name BillingViewAccess an und speichern Sie mit dem Knopf Create policy.

Diese neue Richtlinie müssen Sie jetzt noch dem Benutzer hinzufügen. Dazu gehen Sie wieder zu Security, Identity, & Compliance > IAM > Policies, suchen im Suchfeld Filter Policies nach BillingViewAccess, wählen diese durch Klick in den Kreis link aus und gehen dann auf Policy actions > Attach. Hier finden Sie Ihren check-mk-Benutzer, den Sie auswählen und mit Attach policy bestätigen.

4. Monitoring in Checkmk konfigurieren

4.1. Host für AWS anlegen

Legen Sie für die Überwachung von AWS nun einen Host in Checkmk an. Den Host-Namen können Sie nach Belieben vergeben. Wichtig: Da AWS als Dienst 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.

monitoring aws add host no ip

4.2. Den AWS-Agenten konfigurieren

AWS kann nicht über den normalen Checkmk-Agenten abgefragt werden. Richten Sie daher jetzt den Spezialagenten für AWS ein. Dazu legen Sie unter Setup > Agents > VM, Cloud, Container > Amazon Web Services (AWS) eine Regel an, deren Bedingungen ausschließlich auf den gerade angelegten AWS-Host greifen.

Beim eigentlichen Inhalt der Regel finden Sie zunächst die Angaben für den Login. Hier tragen Sie die „Access Key ID“ des angelegten AWS-Benutzers check-mk ein. Auch wählen Sie hier, ob Sie einen Proxy benötigen, um auf die Daten zuzugreifen und welche globalen Daten Sie überwachen möchten. Das sind solche, die unabhängig von einer Region sind. Aktuell sind hier lediglich die Daten über die Kosten auswählbar:

aws rule 1

Im obigen Bild sehen Sie außerdem die Option Use STS AssumeRole to assume a different IAM role. Sollten Sie einen oder mehrere weitere Accounts bei AWS haben, können Sie mit einem einzigen Monitoring-Benutzer alle anderen ebenfalls überwachen.

Die eigentlich interessanten Daten aber sind einzelnen Regionen zugeordnet. Wählen Sie also hier Ihre AWS-Region(en) aus:

aws rule 2

Unter Services per region to monitor legen Sie nun fest, welche Informationen Sie in diesen Regionen abrufen möchten. In der Standardkonfiguration sind alle AWS-Dienste und die Überwachung derer Limits uneingeschränkt aktiviert. Der Übersichtlichkeit halber wurden im folgenden Bild aber alle bis auf einen deaktiviert:

aws rule 3

Diese können Sie dann pro Webdienst oder global mit Restrict monitoring services by one of these AWS tags wieder einschränken. Wenn Sie pro Webdienst einschränken, wird damit immer die globale Option überschrieben. Ihnen steht hier zusätzlich zu den AWS Tags auch noch die Möglichkeit zur Verfügung, explizite Namen anzugeben:

aws rule 4

Letztendlich müssen Sie noch den Spezialagenten dem vorher erstellten Host zuordnen, indem Sie den Host-Namen in Conditions > Explicit hosts eintragen.

4.3. Services auf dem AWS-Host selbst

Wechseln Sie nun in Checkmk zur Service-Erkennung des neu angelegten AWS-Hosts, wo Checkmk nun etliche Services finden sollte. Nachdem Sie die Services hinzugefügt haben, sieht das nach einem Aktivieren der Änderungen etwa so im Monitoring aus:

aws services ec

4.4. Hosts für die EC2-Instanzen anlegen

Services, die EC2-Instanzen zugeordnet sind, werden nicht dem AWS-Host zugeordnet, sondern sogenannten Piggyback-Hosts. Dies funktioniert so, dass Daten, die vom AWS-Host abgerufen wurden, an diese Piggyback-Hosts, die ohne eigene Monitoring-Agenten arbeiten, verteilt werden. Dabei wird jeder EC2-Instanz ein Piggyback-Host zugeordnet.

Für die Benamsung dieser Piggyback-Hosts haben Sie bei der Konfiguration des Spezialagenten die Wahl zwischen zwei Schemata. Zum einen können Sie die Hosts nach ihrem privaten IP DNS-Namen benennen lassen oder Sie wählen die etwas längere aber dafür eindeutige Benamsung nach IP, Region und Instanz-ID. Letztere Variante ist ab Checkmk 2.2.0 unsere Standardeinstellung. Die Variante ohne Region und Instanz-ID wird nur aus Gründen der Kompatibilität weiterhin angeboten. Ein solcher Piggyback-Host könnte also bspw. 172.23.1.123-ap-northeast-2-i-0b16121900a32960c heißen. Legen Sie diese Hosts entweder von Hand an oder - falls möglich - überlassen Sie diese Aufgabe der dynamischen Host-Verwaltung.

Dynamische Host-Verwaltung einrichten

CEE Als Nutzer einer unserer kommerziellen Editionen können Sie die Erstellung und Löschung von Hosts für Ihre EC2-Instanzen einfach der dynamischen Host-Verwaltung überlassen. Der Menüeintrag Setup > Hosts > Dynamic host management bringt Sie zur Übersichtsseite aller bereits konfigurierten Verbindungen. Klicken Sie hier auf icon new Add connection und geben Sie der Verbindung anschließend eine ID und einen Title.

Im Folgenden werden nicht alle Optionen der Connection properties behandelt. Konsultieren Sie bei Fragen die Inline-Hilfe und den oben verlinkten Hauptartikel.

Stellen Sie zuerst sicher, dass für den Kasten Connection properties der Show-more-Modus aktiviert ist, damit alle verfügbaren Optionen angezeigt werden.

Klicken Sie als nächstes unter Piggyback creation options auf Add new element. Passen Sie den Ordner an, in dem die Hosts Ihrer VM-Instanzen erstellt werden sollen. Die vorausgewählten Host attributes sind für Piggyback-Hosts im Grunde korrekt und bedürfen eher nicht der Anpassung.

Mit dem Aktivieren der Option Delete vanished hosts können Sie dafür sorgen, dass Piggyback-Hosts, für die über einen bestimmten Zeitraum keine frischen Daten mehr kommen, automatisch wieder gelöscht werden.

Im Rahmen der Überwachung Ihrer AWS-Umgebung sollte die Option Restrict source hosts aktiviert werden. Tragen Sie hier Ihren AWS-Host aus dem Abschnitt Host für AWS anlegen ein.

Eine exemplarische Konfiguration der Verbindung könnte dann so aussehen:

Exemplarische Konfiguration der Connection Properties.

Hosts für EC2-Instanzen manuell anlegen

Alternativ können Sie Hosts für die Piggyback-Daten auch manuell anlegen. Dabei ist es wichtig, dass die Namen der Hosts exakt dem oben beschriebenen Schema entsprechen.

Tipp: Mit dem Skript find_piggy_orphans aus dem treasures-Verzeichnis finden Sie alle Piggyback-Hosts, für die es zwar Daten gibt, die aber noch nicht als Hosts in Checkmk angelegt sind:

OMD[mysite]:~$ share/doc/check_mk/treasures/find_piggy_orphans
172.23.1.123-ap-northeast-2-i-0b16121900a32960c
172.23.1.124-ap-northeast-2-i-0b32960a16121900c

Konfigurieren Sie die Hosts für diese EC2-Instanzen ohne IP-Adresse (analog zum AWS-Host) und wählen Sie als Monitoring-Agent No API integrations, no Checkmk agent aus. Wenn Sie unter Piggyback auch noch die Option Always use and expect piggyback data wählen, werden Sie beim Ausbleiben der Daten entsprechend gewarnt.

monitoring aws add host for piggyback data

4.5. Hosts für ELB (Classic Load Balancer)

Auch die Services für die ELB werden Piggyback-Hosts zugeordnet. Die Namen dafür entsprechen deren DNS-Namen.

4.6. Traffic-Statistiken von S3 Buckets überwachen

Mit Checkmk können Sie den Traffic jedes einzelnen S3 Buckets überwachen. In Checkmk müssen Sie dazu lediglich die Option Request metrics unterhalb von Simple Storage Service (S3) aktivieren.

Option für S3-Buckets mit aktivierten Request Metrics.

In AWS ist ein wenig mehr Arbeit erforderlich. Hier müssen Sie eben diese Request metrics noch für die gewünschten Buckets einrichten. Wie das funktioniert beschreibt AWS detailliert in dem Artikel Erstellen einer CloudWatch-Metrik-Konfiguration für alle Objekte in Ihrem Bucket. Während der Einrichtung in AWS müssen Sie einen Filter erzeugen. Diesen Filter müssen Sie EntireBucket nennen, damit dieser von Checkmk erkannt wird. Filter mit anderen Namen wird Checkmk ignorieren. Es steht Ihnen also frei, weitere Filter für diesen Bucket zu definieren, ohne die Funktionalität in Checkmk zu beeinflussen.

Einrichtung eines Filters für die Request Metrics.

Wie Sie den sogenannten (Filter) Scope in AWS wählen, steht Ihnen ebenfalls frei. In den meisten Fällen wird es allerdings sinnvoll sein, alle Objekte des Buckets in den Filter aufzunehmen.

Nach der Einrichtung der Request metrics wird es noch einige Minuten dauern, bis überhaupt Metriken gespeichert sind. AWS gibt diese Zeit mit 15 Minuten an.

Wichtig: Solange die Graphen innerhalb der S3-Konsole noch leer sind, wird auch über den Spezialagenten nichts in Checkmk ankommen. Erst wenn auch Metriken aufgezeichnet wurden, kann Checkmk die entsprechenden Services anlegen. Führen Sie also gegebenenfalls erneut eine Service-Erkennung auf dem AWS-Host durch.

4.7. Limits überwachen

Einige Webdienste von AWS bringen Limits mit und Checkmk kann diese auch überwachen. Dazu gehören zum Beispiel diese:

Sobald ein solches Check-Plugin Services erzeugt und diese später prüft, werden immer alle Elemente des Webdienstes geholt. Nur so kann Checkmk sinnvoll die aktuelle Auslastung zu diesen Limits berechnen und entsprechend Schwellwerte prüfen. Das gilt auch dann, wenn Sie in der Konfiguration die Daten auf bestimmte Namen oder Tags einschränken.

In der Grundkonfiguration sind die Limits automatisch aktiviert. Wenn Sie also die zu holenden Daten in der Regel zum Spezialagenten einschränken, weil Sie die zu übertragenden Daten reduzieren wollen, schalten Sie ebenfalls die Limits ab.

4.8. Weitere Services

Die weiteren Services von AWS werden wie folgt zugeordnet:

Service Zuordnung

CE

Costs & Usage

Beim AWS-Host

EBS

Block Storages

Werden der EC2-Instanz angefügt, sofern diese der Instanz gehören, ansonsten dem AWS-Host

S3

Simple Storages

Beim AWS-Host

RDS

Relational Databases

Beim AWS-Host

5. Dashboards

CEE Zum komfortablen Einstieg in die Überwachung von AWS liefert die Cloud Edition von Checkmk die beiden eingebauten Dashboards AWS EC2 instances und AWS S3 mit aus. Beide finden Sie im Monitoring als Menüeinträge unter Monitor > Cloud.

Damit Sie einen direkten Eindruck bekommen, finden Sie nachfolgend zwei Beispiele, wie diese Dashboards aufgebaut sind. Zuerst das Dashboard zu den EC2-Instanzen, bei der Sie auf der linken Seite den aktuellen Zustand und auf der rechten Seite den zeitlichen Verlauf der wichtigsten Metriken vergleichen können:

Dashboard zu den AWS EC2-Instanzen.

Das Dashboard zu den S3 Buckets ist ganz ähnlich aufgebaut. Auf der linken Seite finden Sie die aktuelle Speicherauslastung der jeweiligen Buckets. Auf der rechten werden wieder die wichtigsten Metriken im zeitlichen Verlauf dargestellt:

Dashboard zu den AWS S3 Buckets.
Auf dieser Seite