Betrieb & Monitoring
Checkmk
Checkmk ist eine Monitoring-Plattform mit automatischer Service-Erkennung und regelbasierter Konfiguration; die Raw Edition ist quelloffen (GPL).
- Automatische Service-Erkennung
- Regelbasierte Konfiguration
- Über 2.000 mitgelieferte Check-Plugins
- Deutscher Anbieter (München)
- Raw Edition Open Source (GPL)
Checkmk ist eine Monitoring-Plattform eines deutschen Anbieters, die aus dem Nagios-Umfeld hervorging (ursprünglich „Check_MK“). Ihr Markenzeichen ist die automatische Service-Erkennung: Wird ein Host aufgenommen, schlägt Checkmk die überwachbaren Dienste selbst vor. Konfiguriert wird nicht pro Host, sondern über Regeln, die auf Gruppen von Hosts wirken.
Dieser Artikel erklärt die Service Discovery, das regelbasierte Konfigurationsmodell, die Erfassungswege (Agent, SNMP, Special Agents, Active Checks), den Unterschied zwischen dem freien Nagios-Core der Raw Edition und dem eigenen Checkmk Micro Core, Business Intelligence und Event Console, das verteilte Monitoring sowie die Editionen. Eine sachliche Einordnung gegenüber Zabbix gehört dazu.
1. Automatische Service-Erkennung
Checkmk trennt sauber zwischen „was überwacht wird“ (automatisch erkannt) und „wie es überwacht wird“ (per Regel konfiguriert). Beim Hinzufügen eines Hosts erkennt es die vorhandenen Dienste und zeigt sie zunächst als noch nicht überwacht an; der Admin übernimmt sie gesammelt. Ein eingebauter Discovery-Dienst prüft laufend auf neue oder verschwundene Services. Ein Dienst wird über Host, Check-Plugin und Item identifiziert (etwa Dateisystem-Check für /var).
2. Regelbasierte Konfiguration
Statt jeden Host einzeln einzustellen, definiert Checkmk Regeln, die auf Ordner, Tags, Labels oder explizite Hosts wirken. Regeln werden von oben nach unten ausgewertet, in der Regel gewinnt die erste passende. Ein einziger Schwellwert-Change (etwa „Festplatte voll ab 90 %“) gilt damit automatisch für alle passenden Hosts. Änderungen landen zunächst in einem Zwischenstand und werden erst mit „Activate pending changes“ produktiv.
Die automatische Erkennung plus regelbasierte Konfiguration ist der eigentliche Zeitgewinn: Wer Monitoring noch pro Host und pro Service von Hand pflegt, skaliert nicht und hat in wachsenden Umgebungen ständig blinde Flecken.
3. Erfassung: Agent, SNMP, Special Agents
Der Checkmk-Agent (Linux, Windows, Unix) liefert detaillierte Systemdaten über Port 6556 (Pull); ein registrierungsbasierter Push-Modus, bei dem der Agent aktiv sendet, ist der Edition Checkmk Ultimate vorbehalten. Netzwerkgeräte werden agentlos per SNMP überwacht. Für Systeme ohne Agent oder SNMP greifen Special Agents auf Management-APIs zu (VMware vSphere, AWS, Azure, Kubernetes und weitere). Active Checks prüfen Netzwerkdienste direkt (HTTP, SMTP, DNS). Die Agent Bakery (maßgeschneiderte Agent-Pakete mit Auto-Update) ist den kommerziellen Editionen vorbehalten.
4. Core, Business Intelligence und Event Console
Die Raw Edition ist vollständig Open Source (GPL) und nutzt den klassischen Nagios-Core; die kommerziellen Editionen setzen den eigenentwickelten Checkmk Micro Core (CMC) ein, der laut Hersteller deutlich höhere Skalierung erreicht. Business Intelligence (BI) aggregiert einzelne Host- und Service-Zustände zu einem Gesamtstatus für geschäftskritische Anwendungen. Die Event Console verarbeitet ereignisbasierte Meldungen wie Syslog und SNMP-Traps, ergänzend zum zustandsbasierten Polling.
5. Verteiltes Monitoring und Editionen
Mehrere Checkmk-Sites lassen sich zu einem verteilten System verbinden; eine zentrale Site fragt Remote-Sites bei Bedarf über Livestatus ab, und Remote-Sites arbeiten bei Verbindungsausfall autonom weiter. Die Editionen sind die freie Community/Raw Edition (GPL) sowie kommerziell Pro, Ultimate und Checkmk Cloud (SaaS); abgerechnet wird nach Anzahl der Services. Nur kommerzielle Editionen bringen CMC, Agent Bakery, Reporting und weitere Skalierungsfunktionen mit.
Was die Raw Edition nicht kann
Die Raw Edition ist voll funktionsfähig und frei, aber bewusst funktional begrenzt: kein Checkmk Micro Core, keine Agent Bakery, kein PDF-Reporting, kein Notification Spooler. Für größere oder stark dynamische Umgebungen (Cloud, Kubernetes, häufige Änderungen) zielen die kommerziellen Editionen.
6. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Automatische Service-Erkennung senkt den Pflegeaufwand stark | Leistungsbestimmender CMC nur in kommerziellen Editionen |
| Regelbasierte Konfiguration statt pro Host | Agent Bakery, Reporting, Notification Spooler kommerziell |
| Über 2.000 mitgelieferte Check-Plugins | Umfangreiches Regelwerk mit Einarbeitung verbunden |
| Deutscher Anbieter, eigener Core, aktive Weiterentwicklung | Livestatus ohne TLS nur in sicheren Netzen einsetzbar |
| Raw Edition vollständig Open Source (GPL), ohne Host-Limit | Abrechnung kommerzieller Editionen nach Service-Zahl |
Häufige Fragen zu Checkmk
Nein, aber verwandt. Checkmk entstand als Erweiterung von Nagios und die Raw Edition nutzt weiterhin den Nagios-Core. Die kommerziellen Editionen setzen jedoch einen komplett eigenentwickelten Core (CMC) ein und gehen in Automatisierung und Skalierung deutlich über klassisches Nagios hinaus.
Für kleinere, relativ statische Umgebungen oft ja. Sobald viele Hosts, Cloud/Kubernetes oder häufige Änderungen ins Spiel kommen, werden der schnellere CMC, die Agent Bakery und Reporting relevant, und das sind kommerzielle Funktionen.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
Checkmk im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.