Der Check_MK Micro Core
1. Der Monitoring-Kern
An zentraler Stelle im Check_MK-System arbeitet der Monitoring-Kern. Seine Aufgaben sind
- das regelmäßige Anstoßen von Checks und Sammeln der Ergebnisse,
- das Bereitstellen des aktuellen Zustands für die GUI und
- das Erkennen von Zustandsänderungen und darauf basierend Alarmierung.
Folgendes Architekturbild zeigt den Kern im Zusammenhang mit den wichtigsten
Komponenten der 
Check_MK
1.1. Nagios und Icinga
Die Check_MK
Alternativ kann auch der Core von Icinga eingesetzt werden. Dieser ist vor allem in Deutschland verbreitet und basiert auf dem gleichen Programmcode, wird aber seit einigen Jahren unabhängig weiterentwickelt.
Auch wenn Nagios bzw. Icinga hervorragende Dienste leistet, flexibel, stabil und gut erprobt ist, so gibt es doch Situationen, in denen man damit an Grenzen stößt. Bei einer größeren Zahl von überwachten Hosts und Services treten vor allem drei Probleme auf:
- Der hohe CPU-Verbrauch beim Ausführen von Checks.
- Die lange Dauer eines Neustarts nach einer Konfigurationsänderung.
- Die Tatsache, dass das System während dieser Zeit nicht verfügbar ist.
2. Der Check_MK Micro Core
Da Check_MK in immer größeren Umgebungen eingesetzt wird und um die
oben genannten Limitierungen von Nagios zu überwinden, haben wir im Jahr
2013 mit der Neuentwicklung eines eigenen Kerns speziell für die Check_MK
| Hohe Effizienz beim Ausführen von Checks | Das betrifft sowohl aktive Checks als auch Check_MK-basierte Checks. In Benchmarks wurden auf einem Desktop-PC (Core i7) mehr als 600.000 Checks pro Minute erreicht. |
| Schnelles Aktivieren von Änderungen | Eine Konfiguration mit 20.000 Hosts und 600.000 Services kann in 0,5 Sekunden geladen werden. |
| Konfigurationsänderungen im laufenden Betrieb | Aktuell laufende Checks und Livestatus-Verbindungen werden nicht unterbrochen. Für die Nutzer des Monitorings ist der Vorgang nicht spürbar. |
| Schnelle Availability-Abfragen | Durch einen speziellen Cache können Verfügbarkeitsanalysen auch über lange Zeiträume ohne spürbare Wartezeit berechnet werden. |
| Zusätzliche Features | Der CMC verfügt über mehrere nützliche Zusatzfunktionen wie z. B. wiederkehrende Downtimes und Quittierungen mit automatischer Ablaufzeit. |
Auch an anderen Stellen wurde optimiert. So werden z. B. Messwerte jetzt ohne Umwege direkt vom Core an den RRD-Cache übergeben, Notifikationen in einem „Keepalive“-Modus erzeugt und Hostchecks mit einem eingebauten ICMP-Helper ausgeführt. Das alles vermeidet kostspielige Prozesserzeugungen und spart CPU-Ressourcen.
Diese Eigenschaften bringen zahlreiche Vorteile – auch in kleineren Installationen:
- Der geringe Verbrauch an CPU ermöglicht in vielen Fällen Virtualisierung anstelle echter Hardware.
- Das stoßfreie Aktivieren von Änderungen ermöglicht häufige Konfigurationsänderungen.
- Dadurch sind auch Problemstellungen wie z. B. Cloud-Monitoring möglich, bei denen in kurzer Abfolge Server hinzugefügt und entfernt werden.
Die folgende Grafik zeigt die CPU-Last auf einem Check_MK-Server vor und nach der Umstellung von Nagios auf CMC. Diese wurde uns freundlicherweise vom Flughafen München bereitgestellt, welcher mit diesem Server 730 Hosts und 18.000 Services überwacht.
In einem anderen Projekt zeigen sich ähnliche Effekte. Folgende Graphen zeigen eine Umstellung vom Nagios-Core auf CMC , in einer Umgebung mit 56.602 Service auf 2.230 überwachten Hosts auf einer virtuellen Maschine mit zwei Cores:
Wie groß der Unterschied im Einzelfall ist, hängt natürlich von vielen Rahmenbedingungen ab. Im obigen Fall läuft auf dem gleichen Server noch eine kleinere Instanz, die nicht umgestellt wurde. Ohne diese wäre der Unterschied in der Last noch deutlicher zu erkennen.
Weitere Artikel über den CMC:
- Migration auf den CMCUmstellen von Nagios/Icinga auf den CMC.
- Besonderheiten des CMCWorin sich der CMC von Nagios/Icinga unterscheidet.
- Dateien und Verzeichnisse des CMCWas liegt wo? Logdateien, Konfiguration, etc.
3. Häufig gestellte Fragen (FAQ)
3.1. Kann der CMC auch normale Nagios-Plugins ausführen?
Selbstverständlich kann der CMC auch klassische aktive und passive Nagios-Checks ausführen.
3.2. Wird Check_MK weiterhin Nagios unterstützen?
Check_MK ist und bleibt kompatibel zu Nagios und wird auch den Nagios-Core weiterhin voll
unterstützen. Auch die Check_MK
3.3. Wie kann ich zwischen Nagios und CMC wechseln?
Ein Umschalten zwischen den beiden Kernen ist einfach, sofern Ihre Konfiguration
rein mit WATO erstellt wurde. Einzelheiten finden Sie im Artikel
Migration auf den CMC. Die Check_MK
3.4. Ist der CMC frei verfügbar?
Der CMC ist nur als Teil der Check_MK