Checkmk
English
master1.6.0
to checkmk.com

1. Umstellung von Nagios auf CMC

Neue Instanzen werden von den CEE Checkmk Enterprise Editions automatisch mit 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 Cores (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 alarmiert. Wenn Sie das nicht wünschen, dann schalten Sie bitte vor der Umstellung über das Element Master Control die Alarmierung ab. Kommentare und Downtimes werden aber übernommen, ebenso wie historische Messdaten (RRD-Dateien).

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 Availability) wünschen, so kopieren Sie die nötigen Dateien auf der Kommandozeile:

OMD[mysite]:~$ cp var/nagios/nagios.log var/check_mk/core/archive
OMD[mysite]:~$ 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 (Hinweise siehe unten), dann können Sie analog wie beschrieben auf Nagios zurückschalten mit:

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

Eine Übernahme von Downtimes 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 WATO gearbeitet haben, ist keine Anpassung notwendig. Hier ist eine Aufstellung aller Dinge, die Sie eventuell von Hand in Nagios konfiguriert haben und die beim CMC nicht oder anders umgesetzt sind:

2.1. Event-Handler

Der CMC unterstützt keine klassischen Nagios-Event-Handler. Die CEE Checkmk Enterprise Editions haben aber dafür die sogenannten Alert Handler. Diese sind deutlich flexibler und können über das WATO-Modul icon alert handlers Alert Handlers konfiguriert werden.

2.2. Service Dependencies

Service Dependencies werden vom CMC aktuell nicht unterstützt. Es ist möglich, dass das später noch implementiert wird. 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.3. Event-Brokermodule

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

2.4. obsess_over_services

Verteiltes Monitoring mit NSCA wird nur in der Funktion als Server unterstützt. Das bedeutet, dass ein System mit CMC als Core passive Checks per NSCA empfangen, nicht aber versenden kann. Diese veraltete Art des verteilten Monitorings bietet so viele Nachteile, dass sie vom CMC nicht unterstützt wird.

2.5. Eskalationen

Die Eskalation von Alarmen wird nicht mehr im Core gesteuert, sondern über die Rule Based Notifications.

2.6. status.dat

Addons, welche Datei die Datei status.dat auslesen, werden Sie nicht finden. Unter ~/share/doc/check_mk/treasures/webapps gibt es jedoch ein Skript, welches eine kompatible status.dat per HTTP-Aufruf erzeugen kann.

2.7. Timeperiods

Bei den Zeitperioden sind einige der Ausnahmedefinitionen, welche in Nagios funktionieren, nicht möglich. Aktuell wird nur das Format 1970-12-18 unterstützt. Dinge wie february -2 gehen aktuell noch nicht. Im WATO-Modul icon timeperiods Timeperiods gibt es aber die Möglichkeit eines iCal-Imports.

2.8. 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. Sie verwalten sie bequem über WATO mit der Regel Active Checks > Classical Active and Passive Monitoring Checks (übrigens auch ohne CMC). Folgendes Beispiel zeigt, wie Sie einen bestehenden Legacy-Check auf das neue Format umstellen:

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 ),
]

Für den CMC stellen Sie auf das modernere custom_checks wie folgt um:

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 Core, so dass Sie nach der Umstellung problemlos zwischen beiden Cores hin- und herschalten können.

2.9. Performancedaten von Host-Checks

Der CMC verwendet für Host-Checks als Standard Smart-Ping, welches an anderer Stelle ausführlich beschrieben wird. Das bedeutet, dass nach einer Umstellung vom Nagios-Core,

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

  • die künstlich erzeugten PING-Checks auf Hosts ohne sonstige Checks per Default Performancedatenerzeugen.

Wenn Sie die PING-Performancedaten für einzelne oder alle Hosts benötigen, dann empfehlen wir, über WATO > Active Checks > Check hosts with PING (ICMP Echo Request) explizit PING-Checks für die gewünschten Hosts hinzuzufügen.

Wenn Sie die bestehenden RRD-Datenbanken weiterführen möchten, können Sie einfach — während der Core angehalten ist — die Dateien in var/pnp4nagios/perfdata/`HOSTNAME von `HOST* nach PING* umbenennen.

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

Auf dieser Seite