Seite 2 - Installation und Betrieb von Check_MK (1)

Lesezeit
2 Minuten
Bis jetzt gelesen

Seite 2 - Installation und Betrieb von Check_MK (1)

05.03.2018 - 00:00
Veröffentlicht in:
Installation und Konfiguration
Die Installation des Check_MK-Servers gestaltet sich sehr einfach, da Sie nur ein einzelnes RPM- oder DEB-Paket installieren müssen. Um das Auflösen der Abhängigkeiten kümmern sich Werkzeuge wie gdebi (Debian/Ubuntu), yum (RHEL/CentOS) oder zypper (SLES) – je nach Distribution. Damit dieses Auflösen der Abhängigkeiten auch klappt, muss bei SLES das SDK-1-Repository und bei RHEL/CentOS das EPEL-Repository eingebunden sein.

Unter [1] stehen für sämtliche unterstützten Distributionen (Debian, Ubuntu, SLES, RHEL/CentOS) die entsprechenden 32-Bit- und 64-Bit-Pakete als "Check_MK RAW Edition" oder als "Check_MK Enterprise Edition" (für Inhaber einer Subskription) zum Download bereit. Für diesen Artikel installieren wir die RAW-Edition auf einem Debian-System. Nach dem Download des Debian-Paketes setzen wir als root in einem Terminalfenster so fort:
gdebi check-mk-raw-1.2.6p4_0.jessie_amd64.deb
Das Check_MK-Paket wird vollständig im Verzeichnis "/opt/omd" eingerichtet. Dabei wird für jede installierte Version eine eigenständige Verzeichnisstruktur angelegt. Ob die Installation geklappt hat, fragen Sie an der Konsole mit den Befehlen omd version beziehungsweise omd versions ab. Der erste Befehl zeigt die installierte Version an, der zweite Befehl listet alle vorhandenen Check_MK-Versionen auf.


Bild 2: Check_MK liefert eine Übersicht der Dienst-Verfügbarkeit, hier für die letzte Woche.

Das Besondere von Check_MK sind Sites (Instanzen). Eine Site ist eine in sich geschlossene vollständige Monitoring-Umgebung mit Hosts, Services und Benutzern. Sie können mehrere Check_MK-Versionen parallel installieren und vorhandene Sites in verschiedenen Check_MK-Versionen betreiben. Nach der Installation legen wir unsere erste Site als root in einem Terminalfenster mit dem Befehl omd create Site (zum Beispiel "itadm") an.

Bei diesem Vorgang wird auf unserem System auch der neue Linux-Benutzer "itadm" angelegt, der kein Passwort bekommt. Mit omd sites zeigen Sie alle angelegten Sites an. Im nächsten Schritt wechseln Sie vom Benutzer root zu itadm mit dem Befehl su -itadm und starten danach die Site mit omd start.

Nachdem Sie die Site gestartet haben, verbinden Sie sich mit der Weboberfläche über die URL "http://Server/itadm". Der Standardbenutzer "omdadmin" hat das Passwort "omd". Auf der linken Seite finden Sie die Sidebar, die dynamische Elemente (Snap-ins) enthält. Diese Elemente können Sie beliebig verschieben, ein- und ausblenden (durch Anfassen beziehungsweise Anklicken mit der Maus im Titelfeld des Snap-ins). Am unteren Bildschirmrand finden Sie ein Symbol, das Ihnen alle Snap-ins anzeigt. Von dieser Übersicht aus übernehmen Sie Snap-ins in die Sidebar. In der Sidebar befindet sich auch das Bookmark-Snap-in. Aktionen und Filter, die Sie häufig benötigen legen Sie als Lesezeichen in diesem Snapin ab. Alle angezeigten Listen und Dashboards lassen sich vom Benutzer interaktiv verändern.


Bild 3: Das Check_MK-Dashboard stellt dem Administrator alle wichtigen Ereignisse auf einen Blick bereit.

Da das Monitoring-System noch keine Hosts enthält, installieren Sie jetzt Agenten auf den Systemen im Netz. Check_ MK bringt zahlreiche Agenten für unterschiedliche Systeme wie Linux, Windows, Unix, EMC VNX, Fritzbox, vSphere und andere mit. Diese finden Sie im Menüpunkt "Monitoring Agents" in "Multisite" und im Site-Verzeichnis "/opt/omd/sites/ itadm/share/check_mk/agents". Nach dem Download der benötigten RPM-, DEB- und MSI-Pakete installieren Sie die Software auf den Zielsystemen – auch auf dem Monitoring-Server. In der Default-Konfiguration lauschen Agenten auf dem TCP-Port 6556. Es gibt zahlreiche Möglichkeiten, dieses Verhalten zu verändern, etwa Abfragen über den SSH, Push- und Pull-Mechanismus.

Jedem Host in einem Monitoring-System werden im Produktivbetrieb Eigenschaften sogenannter Host-Tags zugewiesen. Host-Tags verwenden Sie, um Systeme zu gruppieren und um Regeln anzuwenden. Für unser Beispiel legen wir die Host-Tags "Linux" und "Windows" an: Über "WATO / Host Tags / New Aux Tag" erzeugen wir das Tag "Betriebssystem" mit den Choices "Linux" und "Windows". Achtung: Die zuerst angelegte Auswahl wird allen Systemen als Standardwert zugewiesen. Sind bei Ihnen Systeme im Einsatz, die weder Linux noch Windows sind, dann sollten Sie als erste Auswahl beispielsweise "nicht definiert" anlegen. Folder bilden die Struktur unseres Monitorings ab und entsprechen echten Ordnern in der /opt/omd-Verzeichnisstruktur. Folder nehmen Hosts und weitere Folder auf. Sie dienen dazu, Host-Tags, Benutzer, SNMP-Communities, Rechte und Rollen zuzuordnen. Folder-Einstellungen werden an enthaltene Objekte vererbt. Legen Sie die Folder "Berlin" (mit dem Host-Tag "Windows") und "München" (mit dem Host-Tag "Linux") über "WATO / Hosts / New Folder" an. Ein Host kann nur einem Folder zugewiesen werden.

Seite 1: Besonderheiten von Check_MK
Seite 2: Installation und Konfiguration


Im zweiten Teil des Workshops nehmen wir Hosts in das Monitoring auf, sehen uns die regelbasierte Konfiguration an, richten Benachrichtigungen ein und kümmern uns um System-Updates. Im Im dritten Teil zeigen wir anhand von zwei Anwenderberichten, wie die Nagios-Migration mit Check_MK in der Praxis verläuft und was Sie beim SPS-Monitoring beachten sollten.

<< Vorherige Seite Seite 2 von 2


jp/ln/Karl Deutsch, Mathias Kettner und Sven Rueß

[1] http://mathias-kettner.de/check_mk_download.php

Ähnliche Beiträge

Netzwerkverwaltung an der Medizinischen Universität Wien

Die IT-Abteilung der Medizinischen Universität Wien betreibt das Netzwerk der Universität, wozu die Betreuung von rund 10.000 Anschlüssen sowie Hunderten Endgeräten und Servern gehört. Für diese Aufgabe wurde eine neue Informations- und Planungssoftware für Kabelmanagement und Netzwerkdokumentation implementiert. Das neue Werkzeug ist flexibel, skalierbar und deckt die steigenden Sicherheitsanforderungen voll ab.

Zero-Touch-Provisionierung von aktiven Netzwerkkomponenten (3)

Zero-Touch-Provisionierungsprozesse sind im Rollout von Client-PCs und Servern bereits lange Zeit Standard. Im Gegensatz dazu kommen diese Prozesse bei aktiven Netzwerkkomponenten wie Routern und Switches nur selten zum Einsatz. Im dritten und letzten Teil gehen wir auf weitere Varianten ein, etwa die ZTP-Provisionierung ohne proprietären Server, die Boot-Loader-Variante iPXE oder das alte Verfahren AutoInstall.

Zero-Touch-Provisionierung von aktiven Netzwerkkomponenten (2)

Zero-Touch-Provisionierungsprozesse sind im Rollout von Client-PCs und Servern bereits lange Zeit Standard. Im Gegensatz dazu kommen diese Prozesse bei aktiven Netzwerkkomponenten wie Routern und Switches nur selten zum Einsatz. Im zweiten Teil der Workshopserie schildern wir den proprietären Cisco-Ansatz "Network-Plug-and-Play", der über eine GUI erfolgt und bei dem sich die ausgerollten Komponenten an die Gegebenheiten im Netzwerk anpassen lassen.