Checkmk
EnglishEspañolFrançaisItaliano
master2.2.02.1.02.0.01.6.0
to checkmk.com

1. Umstellung von Nagios auf CMC

Neue Instanzen werden von den kommerziellen Editionen automatisch mit dem Checkmk Micro Core (CMC) als Kern erzeugt. Wenn Ihre Instanz von einer älteren Version stammt, können Sie diese nachträglich von Nagios auf CMC umstellen. Der Vorgang an sich ist dabei sehr einfach:

Stoppen Sie zunächst Ihre Checkmk-Instanz:

OMD[mysite]:~$ omd stop

Danach können Sie umschalten:

OMD[mysite]:~$ omd config set CORE cmc

Vergessen Sie danach nicht das Starten:

OMD[mysite]:~$ omd start

Achtung: Der aktuelle Status des Kerns (aktueller Zustand von Hosts und Services, etc.) wird dabei nicht übernommen. Sobald jeder Check einmal ausgeführt wurde, hat das System den Status aber ohnehin wieder ermittelt. Dabei werden alle Hosts und Services, die nicht UP bzw. OK sind, neu benachrichtigt. Wenn Sie das nicht wünschen, dann schalten Sie vor der Umstellung die Benachrichtigungen (notifications) ab — mit dem Snapin Master control der Seitenleiste. Wartungszeiten und Kommentare werden aber übernommen, ebenso wie historische Messdaten in den RRDs.

Die Historie der Ereignisse (Nagios-Log) wird vom CMC in einem kompatiblen Format, allerdings an einer anderen Stelle (var/check_mk/core/history) gepflegt. Das Log-Archiv befindet sich in var/check_mk/core/archive. Wenn Sie eine Übernahme der historischen Ereignisse (z.B. für die Verfügbarkeit) wünschen, so kopieren Sie die nötigen Dateien auf der Kommandozeile:

OMD[mysite]:~$ cp var/nagios/nagios.log var/check_mk/core/history
OMD[mysite]:~$ mkdir -p var/check_mk/core/archive && [[ -e var/nagios/archive/ ]] && cp var/nagios/archive/ var/check_mk/core/archive

1.1. Zurück von CMC auf Nagios

Wenn Sie feststellen, dass Ihre Konfiguration noch nicht kompatibel ist mit dem CMC (die Hinweise dazu finden siehe unten, dann können Sie analog, wie oben beschrieben, auf Nagios zurückschalten mit:

OMD[mysite]:~$ omd config set CORE nagios

Eine Übernahme von Wartungszeiten etc. von CMC in Richtung Nagios ist dabei nicht möglich. Nagios wird aber seinen alten Zustand von vor der Migration zu CMC wieder einlesen.

2. Tipps zum Umstieg auf CMC

Um den CMC so schlank und effizient wie möglich zu halten und an wichtigen Stellen zu modernisieren, wurden nicht alle Funktionen von Nagios 1:1 nachprogrammiert. Das bedeutet, dass Sie eventuell an einigen Stellen Ihre Konfiguration anpassen müssen.

Grundsätzlich kann der CMC keine Nagios-Konfigurationsdateien einlesen. Sollten Sie also Teile der Nagios-Dateien von Hand geschrieben haben oder Konstrukte wie extra_nagios_conf in der Datei main.mk verwenden, so können diese nicht verarbeitet werden. Wenn Sie immer mit dem Setup der Weboberfläche gearbeitet haben, ist keine Anpassung notwendig.

In den folgenden Abschnitten finden Sie eine Aufstellung aller Dinge, die Sie eventuell von Hand in Nagios konfiguriert haben und die beim CMC nicht oder anders umgesetzt sind.

2.1. Hilfsprozesse

Mit der Verwendung des CMC ändert sich die Art und Weise, wie Daten eingesammelt und anschließend geprüft werden, grundlegend. Deshalb ist es bei einer Umstellung auf den CMC - besonders bei Instanzen mit mehreren tausend Hosts - wahrscheinlich erforderlich, die Zahl der voreingestellten Checkmk Checker und Fetcher zu prüfen und anzupassen. Einen ersten Hinweis darauf kann schon die Funktion Analyze configuration liefern. Wir empfehlen allerdings dringend, das Kapitel Hilfsprozesse im Handbuch zu lesen.

Und für alle, die es eilig haben:

  • Maximum concurrent Checkmk checkers = Anzahl an Prozessorkernen Ihres Servers

  • Maximum concurrent Checkmk fetchers = Jeder Fetcher benötigt ungefähr 50 MB Arbeitsspeicher - also gerne hochdrehen.

2.2. Event Handler

Der CMC unterstützt keine klassischen Nagios Event Handler. Die kommerziellen Editionen haben aber dafür die sogenannten Alert Handler, die deutlich flexibler sind. Sie können über Setup > Events > icon alert handlers Alert handlers konfiguriert werden.

2.3. Service-Abhängigkeiten

Service-Abhängigkeiten (service dependencies) werden vom CMC aktuell nicht unterstützt. Da Serviceabhängigkeiten in Nagios umständlich zu konfigurieren und sehr intransparent für den Benutzer sind, ist auch nicht geplant, sie in dieser Form umzusetzen.

2.4. Event-Broker-Module

Livestatus und die Verarbeitung von Performance-Daten sind im CMC fest integriert. Andere Module können nicht geladen werden.

2.5. Eskalationen

Die Eskalation von Benachrichtigungen wird nicht mehr im Kern gesteuert, sondern über regelbasierte Benachrichtigungen.

2.6. Zeitperioden

Bei den Zeitperioden (time periods) sind einige der Ausnahmedefinitionen, welche in Nagios funktionieren, nicht möglich. Aktuell wird nur das Format YYYY-MM-DD, also z.B. 1970-12-18, unterstützt, nicht aber ein Format wie february -2. Mit Setup > General > icon timeperiods Time periods gibt es aber die Möglichkeit, Kalenderdateien im iCal-Format zu importieren.

2.7. Konfigurationsvariable legacy_checks

Die Konfigurationsvariable legacy_checks, mit der in alten Checkmk-Versionen aktive Checks konfiguriert wurden, gibt es nicht mehr. Natürlich können Sie auch mit dem CMC aktive Checks ausführen, nur in einer etwas anderen Form.

Der Grund ist, dass die legacy_checks sich auf Kommandos beziehen, die man von Hand in der Nagios-Konfiguration anlegt und die dem CMC folglich nicht bereitstehen. Anstelle dessen können Sie die moderneren custom_checks verwenden. Diese verwalten sie mit dem Regelsatz Integrate Nagios plugins, den Sie in Setup > Services > Other services finden — und übrigens auch ohne CMC nutzen können.

Folgendes Beispiel zeigt, wie Sie einen bestehenden Legacy-Check …​

main.mk (altes Format)
# Definition of the Nagios command
extra_nagios_conf += r"""

define command {
    command_name    check-my-foo
    command_line    $USER1$/check_foo -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$
}
"""

# Create service definition
legacy_checks += [
  (( "check-my-foo!20!40", "FOO", True), [ "foohost", "othertag" ], ALL_HOSTS ),
]

… auf das neue Format der custom_checks umstellen:

main.mk (neues Format)
custom_checks += [
  ({
      'command_name':        'check-my-foo',
      'service_description': 'FOO',
      'command_line':        'check_foo -H $HOSTADDRESS$ -w 20 -c 40',
      'has_perfdata':        True,
  },
  [ "foohost", "othertag" ],
  ALL_HOSTS )]

Die neue Methode funktioniert auch mit Nagios als Kern, so dass Sie nach der Umstellung problemlos zwischen beiden CMC und Nagios hin- und herschalten können.

2.8. Performance-Daten von Host-Checks

Der CMC verwendet für Host-Checks als Standard Smart Ping. Das bedeutet, dass nach einer Umstellung vom Nagios Kern,

  • die Host-Checks zunächst keine Performance-Daten mehr liefern und

  • die manuell erzeugten Ping-Checks auf Hosts ohne sonstige Checks per Default Performance-Daten erzeugen.

Wenn Sie die Ping-Performance-Daten für einzelne oder alle Hosts benötigen, dann empfehlen wir einen aktiven Check per Ping für die gewünschten Hosts hinzuzufügen mit dem Regelsatz Check hosts with PING (ICMP Echo Request).

Wenn Sie die bestehenden Round-Robin-Datenbanken (RRDs) weiterführen möchten, können Sie einfach — während der Kern angehalten ist — die Dateien in den Verzeichnissen var/pnp4nagios/perfdata/<hostname>, die mit _HOST_ beginnen umbenennen: von _HOST_* nach PING*.

Alternativ können Sie Smart Ping auch mit dem Regelsatz Host Check Command abschalten und durch einen klassischen Ping ersetzen, der intern wie gehabt mit check_icmp arbeitet. In diesem Fall müssen Sie die RRDs nicht umbenennen, verzichten aber auf die Vorzüge von Smart Ping.

Auf dieser Seite