1. Einleitung
Eine Checkmk-Instanz benötigt allerlei Dienste, allem voran den Monitoring-Kern, aber genauso einen Apache-Webserver für die Web-Oberfläche, Cron für die Planung von Aufgaben und viele andere mehr.
All diese Dienste sehen Sie beim Start einer Instanz mittels omd start im Terminal — einige in allen Editionen und standardmäßig, andere nur in bestimmten Editionen und/oder wenn entsprechende Funktionen aktiviert sind.
Der Befehl omd status könnte in einer kommerziellen Edition etwa zu folgender Ausgabe führen:
2. Dienste im Überblick
Die folgende Tabelle gibt einen kurzen Überblick und zeigt zu jedem Dienst
den angezeigten Prozessnamen,
ob er in
Checkmk Raw und/oder in den kommerziellen Editionen existiert,ob er standardmäßig, ohne explizite Konfiguration existiert sowie
eine kurze Beschreibung, was der Dienst überhaupt erledigt.
Die meisten Dienste werden in den zugehörigen verlinkten Artikeln genauer erklärt, andere sind weitgehend selbsterklärend (etwa der Apache-Dienst). Auf einige weitere Dienste, die lediglich im Hintergrund ihre Arbeit verrichten, gehen wir im folgenden Kapitel ein.
| Dienst |
Checkmk Raw
|
kommerzielle Editionen | Standardmäßig aktiv | Beschreibung |
|---|---|---|---|---|
|
Ja |
Ja |
Ja |
Endpunkt für die Kommunikation mit dem Checkmk-Agenten |
|
Ja |
Ja |
Ja |
Webserver |
|
Ja |
Ja |
Ja |
Hilfsdienst zur Performance-Steigerung bei GUI- und REST-API-Anfragen, mehr Details weiter unten |
|
Nein |
Ja |
Ja |
Checkmk Micro Core — Monitoring-Kern in den kommerziellen Editionen |
|
Ja |
Ja |
Ja |
Crontab-Datei für interne Aufgabenplanung |
|
Nein |
Ja |
Ja |
Dynamic Configuration Daemon für die dynamische Host-Verwaltung flüchtiger Hosts (etwa Container) |
|
Nein |
Ja |
Nein |
Analyse-Werkzeug für Traces, empfangen via OpenTelemetry — für internes Bug-Fixing, mehr Details weiter unten |
|
Ja |
Ja |
Ja |
Schnittstelle zum Abruf von Statusdaten über Livestatus |
|
Ja |
Ja |
Ja |
Dienst zur Verarbeitung von Ereignissen mit der Event Console |
|
Nein |
Ja |
Nein |
Benachrichtigungs-Spooler für asynchrone Zustellung und verteilte Umgebungen |
|
Ja |
Nein |
Ja |
Monitoring-Kern der Checkmk Raw und alter Installationen kommerzieller Editionen (kann dort auf den CMC migriert werden) |
|
Ja |
Nein |
Ja |
Nagios Performance C Daemon zur Verarbeitung von Nagios-Performance-Daten in Checkmk Raw |
|
Ja |
Ja |
Nein |
Piggyback-Hub im verteilten Monitoring, mehr Details weiter unten |
|
Nein |
Ja |
Nein |
Message Broker RabbitMQ, mehr Details weiter unten |
|
Ja |
Ja |
Ja |
Im-Memory-Datenbank als Zwischenspeicher (liefert beispielsweise den Index für die Suche) |
|
Ja |
Ja |
Ja |
RRD-Cache-Daemon für die Zwischenspeicherung von Messwerten |
|
Ja |
Ja |
Nein |
Baut im verteilten Monitoring einen Tunnel von einem lokalen, unverschlüsselten Livestatus-Port zu einem entfernten verschlüsselten auf |
|
Nein |
Ja |
Nein |
Planer für asynchrone Aufgaben der Weboberfläche, mehr Details weiter unten |
|
Ja |
Ja |
Nein |
Dienst zur Bereitstellung der Agentenausgabe |
Die meisten der hier aufgeführten Dienste werden übrigens im Rahmen der Checkmk-Selbstüberwachung nebst einigen weiteren automatisch ins Monitoring übernommen. Sollten Sie Performance-Probleme bemerken, kann es sich lohnen, das Monitoring des Checkmk-Servers selbst weiter auszubauen.
3. Dienste im Detail
3.1. Jaeger
Jaeger ist ein Analyse-Werkzeug, um Anfragen in einem komplexen System zu verfolgen, zu analysieren und zu visualisieren. In Checkmk könnten das etwa die einzelnen Teile eines Netzwerkscans sein, sprich Anfragen an die interne Datenbank, Pings, Dateioperationen und so weiter. All diese kleinen Segmente benötigen Zeit und Jaeger kann hier dabei helfen, Performance-Probleme zu verstehen und Flaschenhälse aufzuspüren.
Jaeger wurde primär für die Entwicklung von Checkmk eingefügt und ist nur aktiv, wenn das Senden und Empfangen von Traces in der Instanzkonfiguration per omd config explizit im Menü Addons > TRACE RECEIVE bzw. TRACE SEND aktiviert wurde.
Wenn aktiviert, erreichen Sie die Jaeger-Weboberfläche über http://mycmkserver/mysite/jaeger.
Weitere Informationen finden Sie im zugehörigen Werk 16565.
Im Regelbetrieb sollte Jaeger deaktiviert sein.
3.2. RabbitMQ und Piggyback-Hub
RabbitMQ ist ein Message Broker, grundsätzlich geeignet, um jegliche Form von Nachrichten mit Hilfe von Warteschlangen (queues) zu versenden. In Checkmk wird RabbitMQ derzeit als Funktion im Zusammenspiel mit dem Piggyback-Hub eingesetzt. Ganz kurz erklärt: Wenn im verteilten Monitoring Piggyback-Daten anfallen, sorgt RabbitMQ dafür, dass diese von den Instanzen, auf denen sie anfallen, an die Instanzen weitergeleitet werden, auf denen sie benötigt/ausgewertet werden. Eine ausführliche, technische Erklärung der Funktionsweise zeigt Ihnen der Vortrag Piggyback unleashed - a new way for intersite communication von der 11. Checkmk-Konferenz.
Wie Sie Piggyback-Hub und damit auch RabbitMQ aktivieren, steht im Artikel zum verteilten Monitoring.
3.3. ui-job-scheduler
Der Dienst ui-job-scheduler organisiert asynchrone Aufgaben, die in der Weboberfläche anfallen.
Das wohl prominenteste Beispiel: Die Aktivierung von Änderungen.
Dabei wird die Weboberfläche aktualisiert, ein animierte Fortschrittsanzeige wird eingeblendet, Änderungen werden angewendet und schlussendlich wird die Ansicht wieder aktualisiert, etwaige Statusmeldungen werden ausgegeben — während dieser Aktivitäten erscheinen und verschwinden weitere Kind-Prozesse und die Prozessorlast geht kurzzeitig nach oben.
3.4. automation-helper
Der Dienst automation-helper beschleunigt einige GUI-Interaktionen, beispielsweise die Service-Erkennung und die Aktivierung von Änderungen,
insbesondere in kleinen bis mittleren Installationen (siehe auch Werk 17678).
Der Dienst lässt sich per omd config im Menü Basic > AUTOMATION HELPER deaktivieren.