Überwachen von Amazon Web Services

1. Einleitung

Nach einer Umfrage unter unseren Anwendern ist Amazon Web Services aktuell der wichtigste Anbieter von Cloud-basierten Services. Und dass Check_MK hier eine exzellente Überwachung bereitstellen muss, versteht sich von selbst.

Ab Version 1.5.0p12 enthält Check_MK ein umfangreiches Monitoring von AWS, welches aus einem Konnektor zu AWS und einer stattlichen Sammlung von Checkplugins besteht, die für Sie verschiedenste Metriken und Zustände abrufen und auswerten. Diese Sammlung wird in den nächsten Versionen stetig weiter wachen. Folgende Plugins werden zum Start mitgeliefert:

Eine vollständige aktuelle Liste aller Plugins finden Sie im Katalog der Checkplugins.

2. Konkrete Umsetzung der AWS-Überwachung

2.1. Hosts und Services

In Check_MK ordnen sich alle zu überwachenden Objekte in eine hierachische Struktur von Hosts und Services ein. Nun gibt es bei Cloud-basierten Diensten das Konzept von Hosts nicht. Um die Einfachheit und Konsistenz von Check_MK 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 Check_MK 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 Check_MK eigene Services mit dem Namen AWS/EBS Disk IO pro EBS, die der EC2-Instanz zugeordnet werden.

2.2. Zugriff auf AWS

Natürlich erlaubt AWS keine Installation eines Check_MK-Agenten und dies ist auch nicht notwendig, da es eine HTTP-basierte API bereitstellt, über die auch Monitoringdaten abrufbar sind.

Check_MK greift über auf diese API über den „Spezialagenten“ agent_aws zu, welcher an die Stelle des Check_MK-Agenten tritt, aber anders als dieser lokal auf dem Check_MK-Server ausgeführt wird.

3. AWS vorbereiten

3.1. Benutzer anlegen

Um die Überwachung per Check_MK zu ermöglichen, legen Sie am besten dafür einen speziellen AWS-User unterhalb Ihres Root-Accounts an. Loggen Sie sich dafür bei AWS als Root-User ein und navigieren Sie 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 Access Type den Programmatic Access auswählen.

3.2. Berechtigungen

Für das Monitoring sollte der Benutzer auf keinen Fall irgendwelche Änderungsrechte bekommen. Sie können dem Benutzer check-mk einfach die einizige Policy ReadOnlyAccess zuordnen (oder Sie machen sich die Mühe, den Account mit detaillierteren Policies genauer einzuschränken):

3.3. Zugriff auf Billing-Informationen

Wenn Sie möchten, dass Check_MK 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-User eine weitere 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. Mit dem Knopf Review geht es zum Schritt zwei. Legen Sie dort als Name den Namen BillingViewAccess aus und speichern Sie mit dem Knopf Create policy.

Diese neue Policy 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-User, den Sie auswählen und mit Attache policy bestätigen. Das müsste dann mit folgender Meldung erfolgreich ausgeführt werden:

3.4. 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 Check_MK-Passwortspeicher ab. Alternativ geben Sie ihn im Klartext in der Regel an (siehe unten). Für Check_MK benötigen Sie neben dem Secret noch die Access Key ID. Der Name des Benutzers (bei uns check-mk) spielt hier keine Rolle.

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:

4. Monitoring in Check_MK konfigurieren

4.1. Host für AWS in Check_MK anlegen

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

4.2. Regel für AWS-Agenten anlegen

AWS kann nicht über den normalen Check_MK-Agenten abgefragt werden. Richten Sie daher jetzt den AWS-Spezialagenten ein. Dazu legen Sie unter Host & Service Parameters ➳ Datasource Programs ➳ 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 Access Key ID des angelegten AWS-User check-mk ein. Auch wählen Sie hier, welche globalen Daten Sie überwachen möchten, also solche die unabhängig von einer Region sind. Das sind aktuell nur die Daten über die Kosten:

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

Unter Services per region to monitor legen Sie nun fest, welche Informationen Sie in diesen Regionen abrufen möchten. Diese können Sie dann mit Restrict monitoring services by one of these tags wieder einschränken auf solche, welche mindestens eins der aufgeführen Tags haben.

4.3. Services auf dem AWS-Host selbst

Gehen Sie nun zu der Serviceerkennung des neu angelegten AWS-Host, wo WATO nun etliche Services finden sollte. Nachdem Sie die Services hinzugefügt haben, sieht das nach einem Activate Changes etwa so aus:

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 Hosts verteilt werden und diese ohne eigene Monitoringagenten arbeiten. Dabei wird jeder EC2-Instanz ein Piggy-Host zugeordnet, welche nach dem privaten DNS-Namen er EC2-Instanz benannt sind.

Die Piggy-Hosts werden von Check_MK nicht automatisch angelegt. 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 privaten DNS-Namen der EC2-Instanz übereinstimmen – und zwar auch die Groß-/Kleinschreibung!

Ü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
ip-172-31-44-50.eu-central-1.compute.internal
ip-172-31-44-51.eu-central-1.compute.internal

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

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

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

4.6. Die weiteren 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
RD Relational Databases Beim AWS-Host