Checkmk vs Nagios vs Icinga: Open-Source Infrastructure-Monitoring im Vergleich 2026
Prometheus und Grafana haben das Monitoring-Landscape für Cloud-native Umgebungen revolutioniert. Aber für klassische Server-Infrastruktur, Windows-Hosts und komplexe Netzwerkmonitoring-Anforderungen sind Checkmk, Nagios und Icinga immer noch die meistgenutzten Lösungen. Alle drei haben eine gemeinsame Herkunft – und alle drei haben sich seither sehr unterschiedlich entwickelt.
Warum nicht einfach Prometheus?
Prometheus ist excellent für Metriken aus containerisierten Anwendungen und Kubernetes. Aber für klassische On-Premise-Infrastruktur hat es Lücken: keine einfache Windows-Integration, kein Agent-basiertes Monitoring für traditionelle Services, keine eingebaute Alerting-History, kein Network-Device-Monitoring (SNMP). Nagios-basierte Systeme schließen genau diese Lücken.
Nagios: Der Urvater des Open-Source-Monitoring
Nagios (ursprünglich "NetSaint", seit 1999, heute Nagios Core) ist das älteste der drei Systeme und der gemeinsame Vorfahre von Icinga und (indirekt) Checkmk. Nagios Core ist Open Source, funktional stabil – und in seiner Basisform stark veraltet.
Nagios Core-Architektur: Nagios Core prüft Hosts und Services über Plugins (Shell-Scripts oder externe Programme, die Exit-Codes und Performance-Daten zurückgeben). NRPE (Nagios Remote Plugin Executor) ermöglicht Remote-Checks auf Linux-Hosts. NSClient++ für Windows. Die Konfiguration erfolgt über statische Text-Dateien – alles manuell, kein Auto-Discovery.
Nagios Core-Stärken:
- Riesiges Plugin-Ökosystem (10.000+ Plugins auf Nagios Exchange)
- Sehr stabil, gut dokumentiert, läuft seit 25 Jahren produktiv
- Vollständig Open Source (GPLv2)
- Minimale Ressourcen (läuft auf sehr kleinen Servern)
- Breites Know-how in der Sysadmin-Community
- Basis für viele andere Tools (Icinga, Check_MK, Shinken)
Nagios Core-Schwächen:
- Veraltetes UI (1990er-Optik, kein modernes Dashboard)
- Konfiguration ausschließlich über Text-Dateien (mühsam für große Umgebungen)
- Kein Auto-Discovery (jeder Host muss manuell eingetragen werden)
- Schlechte Performance bei vielen Hosts (Single-Threaded Check-Engine)
- Keine eingebauten Graphing-Features (externe Tools nötig)
- Nagios XI (kommerziell) hat gute Features, ist aber teuer
- Kaum Weiterentwicklung am Open-Source-Core
Konfiguration (Beispiel):
# /etc/nagios/objects/hosts.cfg
define host {
host_name webserver01
address 192.168.1.10
check_command check-host-alive
max_check_attempts 3
notification_interval 60
contact_groups admins
}
define service {
host_name webserver01
service_description HTTP
check_command check_http
check_interval 5
retry_interval 1
}
Icinga: Der modernisierte Nagios-Fork
Icinga (gegründet 2009 als Fork von Nagios, komplett neu geschrieben als Icinga 2 ab 2014) ist der direkte Nagios-Nachfolger mit modernerem Stack. Icinga 2 teilt die Plugin-Kompatibilität mit Nagios, hat aber eine vollständig neu geschriebene Core-Engine.
Icinga 2-Architektur: Icinga 2 verwendet eine DSL-basierte Konfiguration (Icinga-eigene Sprache statt flacher Text-Dateien), unterstützt Cluster-Setups für High Availability und hat eine REST-API für externe Integrationen. Icinga Web 2 ist das moderne Frontend. Icinga Director ermöglicht Konfiguration über die Web-Oberfläche.
Icinga 2-Stärken:
- Modernes, reaktives UI (Icinga Web 2) mit gutem Dashboard
- Icinga Director: Web-UI für Konfiguration ohne Textdateien
- Cluster-Support für HA-Setup (aktiv-aktiv)
- REST-API für alle Konfigurationsoperationen
- Vollständige Nagios-Plugin-Kompatibilität
- Grafana-Integration für Metriken-Visualisierung
- Business-Process-Monitoring (komplexe Abhängigkeiten)
- Sehr aktive Community und Entwicklung
- Gute Dokumentation
- Vollständig Open Source (GPLv2)
Icinga 2-Schwächen:
- Konfigurationssprache hat Lernkurve (Icinga DSL)
- Installation und Setup komplexer als Nagios oder Checkmk
- Kein Auto-Discovery ohne externe Tools
- Performance besser als Nagios, aber schlechter als Checkmk bei sehr vielen Hosts
- Icinga Director erfordert MySQL/MariaDB (zusätzliche Abhängigkeit)
Konfiguration (Icinga DSL):
# /etc/icinga2/conf.d/hosts.conf
object Host "webserver01" {
address = "192.168.1.10"
check_command = "hostalive"
vars.os = "Linux"
}
object Service "http" {
host_name = "webserver01"
check_command = "http"
vars.http_vhost = "webserver01.example.com"
}
apply Service "disk" {
check_command = "disk"
command_endpoint = host.name
assign where host.vars.os == "Linux"
}
Checkmk: Der moderne All-in-One-Ansatz
Checkmk (ursprünglich "Check_MK", seit 2008, heute von Checkmk GmbH) ist der am weitesten von Nagios entfernte Nachfahre. Es hat eine eigene Agent-Technologie, Auto-Discovery, eingebautes Graphing mit RRDtool und eine moderne Web-Oberfläche – und ist damit das feature-reichste der drei Systeme.
Checkmk-Architektur: Checkmk verwendet einen eigenen Agent (checkmk_agent), der auf überwachten Hosts läuft und strukturierte Daten zurückliefert. Die Service-Discovery erkennt automatisch, was auf einem Host läuft (Prozesse, Netzwerk-Interfaces, Disks, Log-Dateien) und erstellt Services automatisch. Graphing ist mit RRDtool eingebaut.
Checkmk-Stärken:
- Automatische Service-Discovery (Hosts hinzufügen, Auto-Discovery starten)
- Eingebautes Graphing für alle Metriken (kein Grafana nötig)
- Modernes, reaktives Web-UI mit sehr guter UX
- Sehr gute Performance (bis zu 100.000+ Services auf einem Server)
- Kubernetes-Monitoring: Checkmk kann K8s-Cluster nativ überwachen
- Cloud-Monitoring: AWS, Azure, GCP Integration
- SNMP-Monitoring für Netzwerk-Devices out-of-the-box
- Windows-Monitoring deutlich besser als Nagios/Icinga
- Agent-basiertes Push-Monitoring (kein NRPE nötig)
- Nagios-Plugin-Kompatibilität (die meisten Nagios-Plugins funktionieren)
- Checkmk Cloud (SaaS-Option verfügbar)
Checkmk-Schwächen:
- Enterprise Edition (viele Features nur bezahlt): Distributed Monitoring, LDAP, HW/SW-Inventory in vollem Umfang
- Free Edition ("Raw Edition") hat wichtige Features nicht oder nur begrenzt
- Weniger Flexibilität als Nagios für Custom-Checks (eigene Agent-Architektur)
- Steile Lernkurve durch eigene Konzepte (WATO, Ruleset-System)
- Community Edition hat keinen kommerziellen Support
- Setup komplexer als einfaches Nagios
Checkmk-Editionen:
- Raw Edition (CEE-Free): Vollständig Open Source, für kleine Umgebungen
- Enterprise Edition: Kommerziell, Distributed Monitoring, LDAP, Report-Features
- Cloud Edition: SaaS, gehostet von Checkmk GmbH
Konfiguration (über WATO-UI): Checkmk wird hauptsächlich über das Web-Interface konfiguriert. Hosts werden über die WATO-Oberfläche angelegt, Services werden automatisch erkannt.
Direktvergleich
| Merkmal | Nagios Core | Icinga 2 | Checkmk |
|---|---|---|---|
| Auto-Discovery | ✗ | ✗ | ✓ (Killer-Feature) |
| Eingebautes Graphing | ✗ | ✗ | ✓ (RRDtool) |
| Web-UI-Qualität | Veraltet | Modern | Sehr modern |
| Konfigurationsmethode | Textdateien | DSL + Web | Web-UI (WATO) |
| Plugin-Kompatibilität | ✓ (native) | ✓ (kompatibel) | ✓ (kompatibel) |
| Kubernetes-Support | ✗ | Basis | ✓ (nativ) |
| Windows-Monitoring | NSClient++ | NSClient++ | Eigener Agent |
| SNMP | Plugins | Plugins | ✓ (eingebaut) |
| Performance | Niedrig | Mittel | Sehr hoch |
| HA-Cluster | ✗ | ✓ | ✓ (Enterprise) |
| Kosten | Kostenlos | Kostenlos | Freemium |
| Lernkurve | Mittel | Hoch | Mittel-Hoch |
Welche Lösung für welchen Use Case?
Nagios Core ist ideal für:
- Einfache, kleine Umgebungen (< 50 Hosts)
- Situations, wo bereits viel Nagios-Know-how vorhanden ist
- Projekte, die maximale Plugin-Kompatibilität brauchen
- Teams, die kein Budget für neue Tools haben und stabile Systeme bevorzugen
Icinga 2 ist ideal für:
- Umgebungen, die eine Nagios-Migration planen aber modernere Features wollen
- Teams, die HA-Setup und Cluster-Monitoring brauchen
- Environments mit komplexen Business-Process-Abhängigkeiten
- Open-Source-first Teams, die keine kommerziellen Aspekte wollen
Checkmk ist ideal für:
- Größere Infrastrukturen (100+ Hosts, viele Services)
- Environments mit heterogenem Mix (Linux + Windows + SNMP-Devices)
- Teams ohne Zeit für manuelle Konfiguration (Auto-Discovery spart Stunden)
- Kubernetes-Infrastrukturen, die in das Monitoring integriert werden sollen
- Firmen mit Budget für Enterprise-Features (Distributed Monitoring, LDAP)
Integration mit Prometheus und Grafana
Alle drei können mit modernen Stacks integriert werden:
- Prometheus Alertmanager: Nagios/Icinga/Checkmk können Alerts an Alertmanager weiterleiten
- Grafana: Icinga und Checkmk haben offizielle Grafana-Dashboards
- Checkmk + Prometheus: Checkmk kann Prometheus-Metriken einbinden (ab Enterprise)
Fazit
Alle drei Systeme haben ihre Daseinsberechtigung:
- Nagios Core ist für Neuinstallationen kaum noch empfehlenswert – das Ökosystem ist wertvoll, aber der Core ist veraltet. Nur wenn bestehendes Nagios-Wissen und vorhandene Konfigurationen migriert werden sollen.
- Icinga 2 ist der beste Open-Source-Only-Ersatz für Nagios mit moderner Architektur, gutem UI und aktiver Entwicklung. Ideal für Teams, die volle Kontrolle und keine kommerziellen Komponenten wollen.
- Checkmk gewinnt für größere, heterogene Infrastrukturen durch Auto-Discovery, eingebautes Graphing und moderne UX. Die Free Edition reicht für viele Umgebungen; Enterprise lohnt sich ab mittlerer Unternehmensgröße.
Für Kubernetes-first Environments bleibt Prometheus + Grafana die bessere Wahl – Checkmk kann sie ergänzen, aber nicht ersetzen.