1. Umstellung von Nagios auf CMC
Neue Instanzen werden von den 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 Checkmk Enterprise Editions haben aber
dafür die sogenannten Alert Handler. Diese sind deutlich flexibler
und können über das WATO-Modul
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 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:
# 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:
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.