Wer AWS produktiv betreibt, kennt das Muster: In der Konsole sieht „alles grün“ aus, aber im Betrieb tauchen Fragen auf, die nur Monitoring beantwortet. Steigen die Kosten gerade ungewöhnlich? Läuft ein Auto-Scaling-Setup wirklich so, wie es soll? Warum sind die S3-Request-Metriken plötzlich leer? Und vor allem: Wie bringt man all das in ein zentrales Monitoring, ohne auf jeder Instanz Agenten auszurollen?
Checkmk löst das AWS-Thema über API-Abfragen mit einem Spezialagenten und ordnet die Ergebnisse sauber in Hosts und Services ein. In diesem Beitrag bekommen Sie eine kurze, aber praxisnahe Zusammenfassung der offiziellen Doku sowie ein klares Bild davon, wie die Einrichtung abläuft und welche Möglichkeiten das Checkmk AWS Monitoring bietet. Grundlage ist die Checkmk-Dokumentation „Monitoring Amazon Web Services (AWS)“.
Wie Checkmk AWS technisch abfragt (und warum das wichtig ist)
AWS ist aus Sicht von Checkmk kein klassischer Host mit IP-Adresse. Stattdessen nutzt Checkmk einen Spezialagenten, der lokal auf dem Checkmk-Server läuft und die AWS-HTTP-API abfragt. Das ersetzt für AWS-Ressourcen den normalen Checkmk-Agenten auf Zielsystemen.
Das hat zwei praktische Konsequenzen:
- Sie brauchen für viele AWS-Objekte keine Agent-Installation in den Ressourcen.
- Das Datenmodell ist zweistufig: ein „AWS-Host“ als Abfragepunkt und je nach Ressource zusätzliche „Piggyback-Hosts“, denen Checkmk die Daten zuordnet.
Gerade diese Piggyback-Logik ist der Schlüssel, damit EC2-Instanzen oder Load Balancer im Monitoring wie „normale“ Hosts aussehen, obwohl Checkmk die Daten über den zentralen AWS-Abfragehost einsammelt.
Einrichtung: der kurze Weg über Quick Setup
Wenn Sie schnell zu belastbaren Ergebnissen kommen möchten, nutzen Sie in Checkmk die geführte Einrichtung:
- Setup → Quick Setup → Amazon Web Services (AWS)
- dort Add configuration
Die Doku nennt als großen Vorteil, dass Checkmk Konfigurationsfehler während des Assistenten sofort anzeigt, statt dass Sie erst nach einem Aktivieren der Änderungen merken, dass irgendetwas nicht passt. Die Quick-Setup-Konfiguration können Sie später im gleichen Menü wieder öffnen und gezielt anpassen.
In der Praxis ist Quick Setup ideal, wenn Sie mit einem Account anfangen und erst einmal „Breite“ wollen (mehrere Services, mehrere Regionen), um anschließend gezielt zu reduzieren.
Einrichtung: die klassischen Schritte (wenn Sie mehr Kontrolle brauchen)
Der manuelle Aufbau hat sich in der Praxis bewährt, wenn Sie komplexere Umgebungen, mehrere Accounts oder sehr klare Vorgaben für Scope/Tags haben.
AWS vorbereiten: IAM-User anlegen
Es empfiehlt sich, im Root-Account einen dedizierten IAM-User nur fürs Monitoring anzulegen (Beispielname: check-mk). Für diesen User aktivieren Sie Programmatic access (Access Key).
Das ist aus Admin-Sicht sinnvoll, weil Sie:
- Zugriff und Rotation des Keys separat verwalten können,
- Audit/CloudTrail-Einträge sauber zuordnen,
- im Zweifel den Monitoring-Zugriff abschalten, ohne andere Automationen zu stören.
Berechtigungen: Read-only reicht in der Regel
Laut Doku benötigt der User nur Lesezugriff; als einfache Empfehlung nennt Checkmk die IAM-Policy ReadOnlyAccess.
Aus Betriebssicht lohnt es sich trotzdem, vor dem Rollout kurz zu entscheiden, ob Sie mit der pauschalen ReadOnlyAccess-Policy starten (schnell) oder später auf eine enger gefasste Policy umstellen (präziser, aber mehr Pflege).
Checkmk: AWS-Host anlegen (ohne IP)
In Checkmk legen Sie zunächst einen Host an, der AWS als „Service“ repräsentiert. Wichtig:
- IP address family = No IP, weil AWS selbst keine IP/DNS wie ein klassischer Host hat.
Das ist ein typischer Stolperstein: Wenn hier noch IPv4/IPv6 erwartet wird, wirkt der Host „kaputt“, obwohl die API-Abfrage eigentlich separat läuft.
AWS-Spezialagent konfigurieren (Regelwerk)
Danach konfigurieren Sie den Spezialagenten über eine Regel:
- Setup → Agents → VM, cloud, container → Amazon Web Services (AWS)
- Regel auf den AWS-Host einschränken (Conditions → Explicit hosts)
- Zugangsdaten (Access Key ID etc.) eintragen
In der Regel können Sie außerdem festlegen:
- Proxy-Nutzung (falls nötig)
- welche „globalen“ Daten ohne Regionsbezug abgefragt werden (die Doku nennt hier aktuell die Kostendaten)
Regionen und Services auswählen
Der Hauptteil passiert pro Region:
- Sie wählen eine oder mehrere AWS-Regionen aus.
- Sie definieren, welche Services pro Region Checkmk abfragt.
Es sind standardmäßig „alle AWS-Services und auch das Monitoring ihrer Limits“ aktiv, Sie können das aber sehr granular reduzieren.
Scope reduzieren: per Tags oder explizite Namen
Sehr praxisrelevant ist die Filterung, damit Sie nicht „alles“ monitoren, sondern genau das, was Sie verantworten:
- global oder pro Service können Sie die Abfrage auf AWS-Tags einschränken
- alternativ (oder zusätzlich) können Sie explizite Ressourcennamen angeben
Eine globale Einschränkung kann durch service-spezifische Einschränkungen überschrieben werden.
Typischer Anwendungsfall: Sie taggen produktive Ressourcen mit Environment=prod und lassen Checkmk nur dieses Tag sehen. Für Tests/PoCs bleibt das Monitoring dann bewusst schlank.
Was landet als Service auf dem AWS-Host?
Nach der Regelkonfiguration gehen Sie in die Service Discovery des AWS-Hosts. Checkmk findet dort mehrere Services, die direkt dem AWS-Host zugeordnet sind. Nach „Add services“ und „Activate changes“ sehen Sie diese als normale Checkmk-Services im Monitoring.
Dahinter steckt ein einfaches Prinzip: Alles, was nicht sinnvoll einer einzelnen Ressource (wie einer bestimmten EC2-Instanz) zugeordnet wird, bleibt am AWS-Host.
Piggyback in AWS: EC2-Instanzen erscheinen als eigene Hosts
EC2 ist das klassische Beispiel: Viele Informationen gehören zu einer Instanz, aber Checkmk fragt sie zentral über AWS ab. Dafür nutzt Checkmk Piggyback.
Das heißt:
- Daten, die am AWS-Host eingesammelt werden, verteilt Checkmk an „piggybacked hosts“.
- Jeder EC2-Instanz wird ein eigener Piggyback-Host zugeordnet.
- Diese Hosts laufen ohne eigenen Agenten und können ebenfalls ohne IP konfiguriert werden.
Checkmk kann bei der Benennung der Piggyback-Hosts zwischen Schemata wählen. Als Default verwendet CheckMK ein eindeutiges Schema, das IP/Region/Instance-ID enthält (Beispielname: 172.23.1.123-ap-northeast-2-i-0b16121900a32960c).
Das wirkt zunächst sperrig, spart aber später Diskussionen, wenn private DNS-Namen oder IPs recycelt werden.
Piggyback verstehen: warum Checkmk so arbeitet
Piggyback bedeutet: Host A liefert bei der Abfrage nicht nur eigene Daten, sondern auch Daten zu B, C, … Checkmk legt diese Daten serverseitig ab und kann sie beim nächsten Check für B/C direkt verarbeiten, ohne B/C aktiv abzufragen. Zusätzlich besteht die Kombinationsmöglichkeit mit einem „echten“ Agenten, falls Sie auf der VM zusätzlich lokale Checks ausführen möchten.
Das ist im Cloud-Kontext praktisch, weil Sie „API-Sicht“ und „OS-Sicht“ kombinieren können:
- API-Sicht (via Piggyback): Instanzstatus, CloudWatch-nahe Metriken, AWS-seitige Zustände
- OS-Sicht (via Agent, optional): Prozesse, Filesysteme, Applikationschecks
Dynamische Host-Verwaltung: Hosts automatisch anlegen und löschen
Wenn Sie nicht ständig EC2-Hosts manuell in Checkmk nachpflegen möchten, nutzen Sie die dynamische Host-Verwaltung (DCD). Checkmk kann Piggyback-Hosts automatisch erzeugen und auch wieder entfernen, wenn keine frischen Daten mehr kommen.
Gehen Sie folgendermaßen vor:
- Setup → Hosts → Dynamic host management
- pro Verbindung definieren Sie Eigenschaften und „Piggyback creation options“
- Option „Delete vanished hosts“, um verschwundene Ressourcen automatisch aufzuräumen
Die Piggyback-Daten liegen dann auf dem Checkmk-Server unter (~/tmp/check_mk/piggyback/), was beim Troubleshooting hilfreich ist.
Gerade in Auto-Scaling-Setups reduziert DCD spürbar den Pflegeaufwand, weil Ihr Monitoring nicht an „Hostlisten“ scheitert, die in der Cloud naturgemäß ständig veralten.
ELB/Load Balancer: ebenfalls Piggyback-Hosts
Auch für ELB (Classic Load Balancer) ordnet Checkmk die Services nicht dem AWS-Host zu, sondern Piggyback-Hosts. Der Hostname entspricht dabei dem DNS-Namen des Load Balancers.
Das ist in der Praxis angenehm, weil Sie die Ressourcen in Checkmk genauso wiederfinden, wie Sie sie in AWS ohnehin identifizieren.
S3-Request-Metriken: nur da, wenn AWS sie wirklich liefert
Ein Punkt, der in Projekten regelmäßig für Verwirrung sorgt: Traffic-/Request-Statistiken pro S3-Bucket sind nicht automatisch verfügbar.
In Checkmk aktivieren Sie zwar die Option „Request metrics“ im Bereich Simple Storage Service (S3). In AWS müssen Sie die Request Metrics aber zusätzlich am Bucket konfigurieren.
Wichtig laut Checkmk-Doku:
- Beim Anlegen der CloudWatch-Metrics-Konfiguration in AWS müssen Sie einen Filter anlegen.
- Dieser Filter muss
EntireBucketheißen, sonst ignoriert Checkmk ihn. - AWS benötigt nach Einrichtung Zeit, bis Metriken vorhanden sind; etwa 15 Minuten.
- Solange die Graphen in der S3-Konsole leer sind, kommt in Checkmk ebenfalls nichts an.
Das ist ein gutes Beispiel dafür, wie Checkmk korrekt „leer“ bleibt, weil AWS (noch) keine Daten liefert. Dann hilft kein Re-Discovery-Marathon, sondern nur: AWS-Seite prüfen, warten, dann Discovery erneut laufen lassen.
Limits/Quotas überwachen
AWS kennt bei einigen Services Limits. Checkmk kann diese ebenfalls überwachen („Monitoring limits“).
In der Praxis ist das vor allem dann nützlich, wenn Teams neue Umgebungen ausrollen und dabei unauffällig gegen Quotas laufen: Das Problem taucht sonst oft erst auf, wenn Deployments scheitern oder Auto-Scaling nicht mehr erweitert.
Praxis-Setup, wie wir es bei Kunden oft aufbauen
Ein solides „Start-Design“ sieht meist so aus:
1) Ein AWS-Host pro Account (oder pro Organisationseinheit), sauber in Ordnern getrennt.
2) Regionen nur dort aktivieren, wo Sie wirklich Workloads haben.
3) Services zuerst breit aktivieren, dann über Tags reduzieren (z. B. Environment, Owner, CostCenter).
4) Dynamische Host-Verwaltung für EC2/ELB-Piggyback-Hosts einschalten, damit Auto-Scaling nicht zum Monitoring-Problem wird.
Wenn Sie Checkmk ohnehin als zentrale Plattform für Infrastruktur-Monitoring nutzen, lohnt sich außerdem der Blick auf die generelle Arbeitsweise mit Piggyback, weil Sie das Prinzip später auch bei anderen Plattformen wiederfinden.
Wer Checkmk als System einordnet oder intern erklären muss, findet dazu bei ADMIN INTELLIGENCE auch den Grundlagenbeitrag Was ist Checkmk?.
Fehlersuche: zwei typische Stolperstellen
„AWS-Host ist DOWN“ obwohl die API erreichbar ist
Wenn der AWS-Host wie ein klassischer Host mit IP konfiguriert ist, kann das zu einem DOWN-Zustand führen, obwohl der Spezialagent korrekt arbeitet. Daher muss gesetzt sein: IP address family = No IP. Prüfen Sie das als erstes.
Piggyback-Daten sind da, aber Hosts fehlen
Wenn Sie Piggyback-Daten bekommen, aber die Hosts nicht existieren (oder falsch heißen), passt meist die Benennung nicht oder die dynamische Host-Verwaltung ist nicht aktiv.
Für das Verständnis hilft die offizielle CheckMK Piggyback-Doku, die erklärt, wie Checkmk Daten von Host A an B/C „mitliefert“ und serverseitig ablegt.
Wenn Sie Checkmk im Alltag stärker automatisieren, sind außerdem saubere Benachrichtigungen Pflicht. Für Microsoft-Teams-Setups passt thematisch unser Beitrag Checkmk Teams Notifications: Fehlermeldungen direkt in Microsoft Teams senden, weil Cloud-Alarme oft schneller im Chat als im Postfach landen.
Wenn Sie Ihre Cloud- und On-Prem-Welt gemeinsam monitoren (z. B. Firewall plus AWS), kann ein sauberer Checkmk-Stack viel Reibung sparen. Ein Beispiel aus der Praxis ist die Integration bei Security-Gateways, siehe Sophos Firewall mit Checkmk überwachen.
Wann externe Hilfe sinnvoll ist
AWS-Monitoring steht und fällt mit Scope, Rollenmodell und einem sinnvollen Tagging. Wenn Sie mehrere Accounts, viele Regionen oder strikte Compliance-Vorgaben haben, lohnt sich ein kurzer Architektur-Check, bevor Sie hunderte Services „blind“ erzeugen.
Wenn Sie Unterstützung beim Aufbau oder bei der Konsolidierung Ihrer Checkmk-Umgebung benötigen, finden Sie bei ADMIN INTELLIGENCE unsere Checkmk-Leistungen unter admin-intelligence.de/checkmk. Weitere Praxisartikel rund um Monitoring und Betrieb veröffentlichen wir fortlaufend auf https://blog.admin-intelligence.de/ – bei konkreten Fragen erreichen Sie uns auch über https://www.admin-intelligence.de/kontakt/.
IT-Fachinformatiker bei ADMIN INTELLIGENCE GmbH