Ep. 17: Arbeiten mit Netzwerktopologien in Checkmk

Name: checkmk
Rating: 4.7 (114 reviews)

Hinweis: Alle Videos sind im deutschen Originalton und verfügen über englische Untertitel. Zudem stellen wir für alle Inhalte die Transkripte auf Englisch zur Verfügung.

[0:00:01]	In dieser Folge schauen wir uns die Parents an und die Netzwerktopologie. Willkommen zur letzten Folge in unserer 1. Staffel der Checkmk-Tutorials. Heute geht es um das Thema Parents und Netzwerktopologien.
[0:00:24]	Was es damit auf sich hat und was man damit machen kann, dass zeige ich euch gleich. Bitte keine Angst haben,es gibt natürlich in Zukunft eine 2. Staffel. Die werden wir dann mit Checkmk 2.0 und einer komplett neuen Benutzeroberfläche drehen.
[0:00:37]	Netzwerktopologie: Was kann ich damit anfangen? Schauen wir uns das am besten gleich mal im Testsystem an. Wir haben hier ein kleines Checkmk-System mit 8 Hosts. Das ist auch nicht sehr spannend, hier 5 Server, der Checkmk-Server ist auch dabei, 2 Router, ein Windows-Rechner, der momentan down ist.
[0:00:58]	Wenn ihr jetzt auf diesen Punkt "Network Topology" geht, vielleicht habt ihr das schon mal gemacht, dann seht ihr so eine lustige Wolke von Hosts. Ich ziehe das einmal in die Mitte. Was sagt das mir jetzt?
[0:01:12]	Nicht viel, ich habe eben meine Hosts, der eine hier ist down. Ich klappe die Seitenleiste ein, dann sehe ich mehr. "windows 01" ist Down, oder zum Beispiel hier dieser Datenbank-Server ist Up.
[0:01:24]	An sich ist die Grafik sonst relativ sinnlos. Wie kann ich jetzt das mit Leben erfüllen?
[0:01:30]	Wie kann ich jetzt hier eine Typologie einrichten und warum sollte ich es überhaupt tun?
[0:01:34]	In unserem Beispiel haben wir nicht nur die Server, sondern ich habe hier auch 2 Router.Jetzt nehmen wir mal an, dass die Datenbank-Server über den "router01" erreichbar sind.
[0:01:46]	Was würde denn passieren, wenn dieser Router ausfällt?
[0:01:50]	Dann wäre natürlich der Stand der, dass die Datenbank-Server für das Monitoring auch nicht mehr erreichbar sind. Deswegen würden alle auf Down gehen. Ihr würden eine ganze Menge Alarmierungen bekommen, nämlich nicht nur von dem Router, sondern auch von den Datenbank-Servern. Was eigentlich nützlicher wäre, ist das ein Alarm kommt, von dem Router, der nicht mehr erreichbar ist.
[0:02:10]	Und die Informationen, dass die dahinterliegenden Datenbank-Server nur für das Monitoring nicht erreichbar sind. Dafür gibt es in Checkmk den Status unreachable, das heißt ist nicht erreichbar.
[0:02:21]	Normalerweise gibt es dann auch keine Alarmierung, weil ja für den Router schon alarmiert wurde. Es kann übrigens sogar sein, dass die Datenbank-Server noch wunderbar funktionieren, und für die User sogar erreichbar sind, aber nur nicht für das Monitoring-System.
[0:02:33]	Damit das funktioniert, müsst ihr aber dem Checkmk-Server mitteilen, dass er die Datenbank-Server über den "router01" erreicht.
[0:02:43]	Dazu gibt es in der Konfiguration der Hosts das Feld Parents. Dazu gehe ich jetzt in die Verwaltung der Hosts, jetzt gehe ich zu meinen Servern und nehme einen der Datenbank-Server raus.
[0:02:58]	Zum Beispiel diesen Einser, und ich editiere den jetzt. Ich gehe zu dem Feld "Parents", aktiviere das, und trage hier ein "router01". Natürlich speichere ich, Änderung aktivieren.
[0:03:19]	Wenn ich jetzt wieder auf die Netzwerktopologie gehe, dann sehe ich, dass es einen kleinen Unterschied gibt. Warten wir, bis das sich eingependelt hat. Seitenleiste einklappen.
[0:03:30]	Ich schiebe es wieder auf die rechte Seite rüber, dann seht ihr, dass der "db-01-server" jetzt hinter dem "router01" steckt. Ihr seht diese wandernden Striche hier. Die zeigen an, in welche Rchtung die Monitoring-Daten fließen.
[0:03:46]	Das heißt vom "db-01-server" zum "router01", und von dort zur Checkmk-Instanz. Das Checkmk-Logo steht stellvertretend für das Gesamtsystem. Jetzt weiß Checkmk, das es, um diesen Server zu erreichen, über diesen Router muss.
[0:04:03]	Wenn der Router ausfällt, dann weiß es, dass es diesen "db-01-server" eigentlich nicht erreichen kann. Machen wir das mal für alle Datenbank-Server. Dazu gehe ich nochmal zurück in meine Host-Verwaltung, zu meinen Servern.
[0:04:19]	Jetzt mache ich Folgendes: Ich gehe erstmal wieder zu diesem ersten Datenbank-Server, nehme "Parents" wieder raus, weil es viel intelligenter ist, das beim Ordner anzugeben. Wie ihr seht, habe ich alle Server in einem Ordner.
[0:04:33]	Wenn die jetzt alle über einen Router erreichbar sind, kann ich einfach hier zu den Eigenschaften des Ordners gehen und im Ordner als Parent den "router01" eintragen.
[0:04:46]	Änderungen aktivieren. Die 5 Server hängen jetzt in der Topologie unter diesem Routers. Wie kann ich jetzt ausprobieren, ob das funktioniert?
[0:04:58]	Ich könnte jetzt einfach den "router01" abschalten. Aber nachdem ich ein Testsystem habe, und es den Router in Wirklichkeit gar nicht gibt, kann ich das nicht tun.
[0:05:07]	Aber ich kann jetzt Folgendes machen: Ich geh hier auf diesen Router im Monitoring. Ich klicke hier drauf, kann hier mit der rechten Maustaste zu "Details of Host" gehen.
[0:05:19]	Jetzt bin ich bei der Service-Liste von diesem Host. Ich gehe auf den Host selber, auf die Kommandos, und jetzt mache ich 2 Sachen: Das Eine ist, dass ich die aktiven Checks deaktiviere. Ich mache immer "disable active checks".
[0:05:35]	Damit bleibt der einfach auf dem Zustand, der er das letzte Mal hatte. Dann setzte ich diesen Zustand von Hand auf down. Das heißt, ich mache hier ein "Fake Check Results".
[0:05:47]	Ich trage hier noch "test" ein und setzte diesen von Hand auf down. Weil ich die aktiven Checks deaktiviert habe, bleibt er auch auf down, und geht nicht nach ein paar Sekunden wieder auf up, weil er eigentlich noch erreichbar ist.
[0:06:06]	Wenn ich jetzt auf die Netzwerktopologie darauf gehe, dann sehe ich Folgendes: Dieser "windows01"-Host, der vorher auf down war, ist jetzt plötzlich markiert als unreachable. Das bedeutet, Checkmk weiß jetzt, dass der zwar eigentlich nicht antwortet, aber der Grund ist wahrscheinlich der, das der Router auch nicht antwortet, der auf dem Weg dorthin liegt.
[0:06:30]	Jetzt werdet ihr euch wahrscheinlich fragen, 'wieso sind jetzt die 4 anderen Server nicht auch auf unreachable gegangen'.
[0:06:35]	In Wirklichkeit würden sie es natürlich tun, aber in meinem Testsystem sind diese Hosts anpingbar und deswegen sind sie auch Up. Das heißt, wenn Checkmk feststellt, dass er die Server trotzdem erreicht, obwohl der Router auf down steht, bleibt der Status trotzdem okay.
[0:06:53]	Checkmk versucht auf jeden Fall trotzdem diese Systeme zu erreichen. Dieser Fall, den wir hier haben, dass der Router down ist und die Hosts grün sind, kann dann eigentlich in der Praxis, wenn ihr es richtig aufsetzt, nicht passieren. Was ist eigentlich, wenn ihr ein System habt, wo es redundante Router gibt.
[0:07:11]	Wo ein Ziel über 2 Wege erreicht werden kann?
[0:07:14]	Dann ist es ja so, wenn einer der beiden Router noch funktioniert, müsste das Zielgerät auch erreichbar sein. Ihr habt dann quasi keine Baumstruktur, sondern ein vermaschtes Netz, und auch das kann man in Checkmk abbilden.
[0:07:26]	Dazu gehe ich wieder in meine Verwaltung der Hosts, wieder zu dem Ordner, den Eigenschaften. Wenn ihr vorher schon genau hingeschaut habt, habt ihr gesehen, dass es hierbei Parents mehrere Eingabefelder gibt.
[0:07:39]	Ich kann hier auch noch ein 2. Router eintragen. Kann speichern, die Änderungen aktivieren. Wenn ich jetzt zu meiner Netzwerktopologie gehe, dann schaut das etwas unübersichtlicher aus. Wir machen die Seitenleiste zu.
[0:08:00]	Wenn man genau hinschaut, sieht man, dass jeder dieser Rechner über Alternative A "route01" oder B "router02" erreichbar ist. Das heißt, jetzt dauert es nicht lang, dann wird dieser Host hier vom Zustand unknown wieder auf den Zustand critical gestuft, beziehungsweise down, weil Checkmk sagt einer der Router ist aktiv, nämlich "router02", also muss der auch erreichbar sein. Wenn er nämlich nicht antwortet, dann liegt es eben nicht an dem Router, sondern an dem Host selber. Das heißt, wenn wir kurz warten, dann wird das Ganze auf rot gehen.
[0:08:35]	Wie ihr seht, habt ihr hier im Checkmk eine Möglichkeit, um die Netzwerktopologie abzubilden, und zwar hauptsächlich, um sinnlose Alarmierungen zu vermeiden. Wenn wir von Topologie sprechen, muss man natürlich immer sehen, es geht hier um die Sicht des Monitoring-Systems: Auf dem Weg kann Checkmk einen Server erreichen, und nicht um eure Netzwerktopologie im Allgemeinen.
[0:08:59]	Im verteilten Monitoring das natürlich jede Checkmk-Instanz eine eigene Topologie hat, weil das Monitoring lokal von der Instanz aus stattfindet. Es geht nicht darum eure globale Netzwerkstruktur abzubilden.
[0:09:13]	Wenn ihr das Werkzeug richtig einsetzt, werdet ihr sinnlose Alarmierung vermeiden. Das ist es absolut zu empfehlen, vor allem, wenn ihr Standorte mit sehr vielen Host habt, die nur über wenige Router erreichbar sind.
[0:09:24]	Damit bedanke ich mich, dass ihr bei dieser 1. Staffel der Checkmk-Tutorials dabei wart. Ich hoffe, wir sehen uns dann im 2. Teil wieder.
[0:09:37]	Außerdem habe ich jetzt keine anderen Hemden mehr...