Ep. 14: Verteiltes Monitoring mit Checkmk
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:00] | Verteiltes Monitoring, was genau dahinter steckt, dass seht ihr, wenn ihr Verteiltes Monitoring bedeutet, dass ihr mehrere Checkmk-Server zu einem großen Monitoring-System zusammenbaut. |
[0:00:23] | Das kann verschiedene Gründe haben, warum ihr das tun wollt. |
[0:00:26] | Der Eine wäre zum Beispiel Skalierung, dass ihr sagt mit einem Checkmk-Server kann ich nicht so viele Hosts monitoren, wie ich habe. |
[0:00:32] | Checkmk ist ja wirklich sehr performant, skaliert gut, aber irgendwann ist auch hier mal das erreicht, was ein physikalischer Server leisten kann, und dann kann man sagen ich nehme einfach 2-3-4, so viel ich brauche, und schaltet die dann zu einem großen System zusammen. |
[0:00:49] | Ein anderer Grund für verteiltes Monitoring wäre, dass verschiedene Server von verschiedenen Organisationen administriert werden, also organisatorische Gründe, und dass man aber trotzdem eine Gesamtsicht auf das ganze Monitoring haben möchte. |
[0:01:01] | Einen ähnlichen Fall habe ich, wenn ich mir das Thema Netzwerk anschaue. Es kann zum Beispiel sein, dass ihr ein Standort habt in München und einen, sagen wir Singapur, und es einfach nicht wollt, dass alle Monitoring-Daten von München aus nach Singapur gehen und zurück. Das heißt, dass ihr für jeden einzelnen Host, den ich abfragen möchte, immer über den Atlantik gehen muss, oder über den Pazifik genauer gesagt hier, sondern das ich vor Ort in eigene Instanz habe von Checkmk, die aber dann irgendwie so wieder verbinde, das ein großes System draus wird. |
[0:01:30] | Und bisschen ähnlich gelagert ist das Thema Verfügbarkeit. |
[0:01:33] | Vielleicht wollt ihr auch, dass das Monitoring in einem entfernten Standort auch dann weiter läuft, wenn mal die WAN-Verbindungen nicht da ist, oder es kann zum Beispiel sein, dass aus Sicherheitsgründen ein Monitoring von Standort A in Standort B hinein oder in Netzwerksegment B hinein gar nicht möglich ist, dass da eine DMZ ist, ein abgesicherter Bereich, wo eigentlich ein Monitoring-Zugriff nicht erwünscht ist. Dann kann man diesen abgesicherten Bereich eine eigene Instanz aufbauen, und die Instanz wieder einbinden, in ein großes Monitoring. |
[0:02:03] | Und wie das jetzt geht, das ich also aus mehreren Checkmk-Servern ein großes Monitoring-System aufbaue, das zeige ich euch jetzt. |
[0:02:12] | Ausgangspunkt ist ein ganz normales Monitoring-System, zum Beispiel das, was wir bei der letzten Folge verwendet haben, um die Wartungszeiten zu erklären. Ich habe hier 5 Hosts, ist alles stinknormal. |
[0:02:25] | Der nächste Schritt ist der, dass ich ein Remote-System, also ein zweites System, was ich einbinden will, anlege. Dazu wechsel ich jetzt mal auf die Kommandozeile von einem Checkmk-Server. Das muss jetzt nicht der Gleiche sein, es stinknormal. |
[0:02:40] | kann ein anderer sein. In meinem Fall ist zur Einfachheit derselbe Server, aber das spielt überhaupt keine Rolle. Auf diesem lege ich jetzt eine Instanz an, die nenne ich jetzt mal "remote1". Das ist alles wie man es kennt, alles wie gehabt. |
[0:02:58] | Ich ändere noch das Passwort. Dazu gehe ich einmal erstmal in die Instanz hinein, als Instanz-Benutzer, und verwende jetzt den Befehl von hier. Und tippe hier ein Passwort ein, was ich mir leicht merken kann. |
[0:03:13] | So, jetzt ist der erste, wichtige Schritt, dass ihr einen Zugriff von Remote aus erlaubt. Es funktioniert nämlich so, dass die Master-Site per TCP auf die Remote-Site zugreift über einen bestimmten TCP-Port, um an die Status-Daten zu kommen von dieser Instanz. |
[0:03:31] | Dazu rufe ich "omd config" auf, gehe dann auf den Punkt "Distributed Monitoring", hier schalte ich "LIVESTATUS_TCP" an. Das ist der entscheidende Punkt. |
[0:03:46] | Ich könnte hier und sollte hier noch begrenzen von welchen IP-Adressen aus dieser Server erreichbar sein soll. Und ich kann auch noch eine Verschlüsselung einschalten, die ist hier per Default angeschaltet. |
[0:04:00] | Ich lasse jetzt mal diese Addressbegrenzung hier raus, aber normalerweise wäre empfehlenswert hier die Adresse von eurem Master-System einzutragen. |
[0:04:09] | So, dann gehe ich wieder ins Hauptmenü, gehe raus, und jetzt starte ich diese Instanz an. Und damit bin ich auf der Stelle schon fertig. |
[0:04:22] | Die Remote-Instanz ist jetzt bereit dafür ins Monitoring eingebunden werden zu können. Wichtig ist natürlich, dass ihr euch diese Port-Nummer merkt, bei dem TCP-Port per Default ist 6-5-5-7 vorgeschlagen. Ich habe das jetzt hier auch nicht geändert. Wenn ihr mehrere Instanzen auf einem Server einbinden wollt, dann müsst ihr natürlich unterschiedliche TCP-Port-Nummern vergeben. |
[0:04:43] | Alle weiteren Schritte kann ich jetzt direkt auf der Oberfläche vom Master machen. |
[0:04:48] | Dazu geht ihr hier nach WATO in das Modul "Distributed Monitoring", und zwar muss ich hier eine neue Verbindung anlegen zu der Remote-Site. |
[0:05:00] | Meine eigene Site ist hier schon eingetragen, das heißt, das ist automatisch passiert, weil ihr ja auf jeden Fall mindestens eine Instanz im Monitoring-System habt, und die wird hier automatisch eingetragen. |
[0:05:09] | Ich gehe also auf "New connection". Wichtig ist jetzt hier, das "Site ID" genau der gleiche Name ist, den ihr beim "omd create" auf der Remote-Site verwendet habt. |
[0:05:21] | In meinem Fall "remote1", jetzt schreibe ich mal hier Singapur dazu, als Kommentar zum Beispiel. Und wichtig ist die IP-Adresse des Servers, auf dem die Remote-Site läuft, die Port-Nummer, die wurde gerade in dieser Maske beim '"omd config" abgefragt, die Port-Nummer ist die "6557", das heißt, wenn es nur eine Instanz auf diesem Server gibt, die remote erreichbar ist, dann kann man bei dieser die Port-Nummer bleiben. |
[0:05:49] | Verschlüsselung, wir wollen natürlich hier verschlüsseln, weil Sicherheit ist mir sehr wichtig, und diese Checkbox müssen wir jetzt allerdings in unserem Test rausnehmen, weil wir kein Zertifikat hinterlegt haben, dass wir mit einer eigenen CA generiert haben. |
[0:06:06] | Das heißt, dieses Zertifikat, welches die Remote-Site verwendet, ist ein automatisch zufällig Generiertes, und deswegen können wir es auch leider nicht überprüfen. |
[0:06:15] | Das wäre jetzt dann nochmal ein Thema, das ihr im Handbuch nachschauen könnt, wie das genau geht, wenn ihr ein eigenes Zertifikat hinterlegen wollt. |
[0:06:23] | Der Live-Staus-Proxy ist ein Feature der Enterprise Edition, welche bei Verbindungen mit sehr hoher Latenz, zum Beispiel über den Pazifik, die Wartezeiten optimiert, und auch erkennt, wenn Remote-Sites nicht verfügbar sind. |
[0:06:40] | Was man hier auf jeden Fall eintragen muss, ist der URL-Prefix, über den die Remote-, die Web-Oberfläche der Remote-Site, erreichbar ist. |
[0:06:53] | Da muss ich jetzt hier den Namen der Instanz mit angeben, und dann komme ich zum letzten Kasten, und zwar zum Thema Configuration Connection, hier habt ihr zwei Möglichkeiten. Ihr könnt entweder sagen jede Instanz wird vor Ort administriert, das heißt, die Kollegen in Singapur verwenden ihr Checkmk selbst, um ihre Hosts anzulegen, und ihr wollt eigentlich in München nur einen zentralen Status-Bildschirm haben, wo ihr das Operating machen könnt oder Einblick haben könnt. Die andere Variante, und die ist eigentlich häufiger heutzutage, ist, das ihr eine zentrale Konfiguration auch haben wollt, das heißt, dass ich das ganze Monitoring-System wie ein großes System anfühlt, und in Singapur eigentlich überhaupt nichts angefasst wird, sondern alles von München aus passiert. |
[0:07:38] | Dazu würde die jetzt hier wählen "Push configuration to this site", das heißt, das zentrale System, hier das Münchener System, schiebt seine Konfiguration dann auch auf alle Remote-Systeme, und schiebt da auch die Informationen zu den überwachten Hosts rüber. Dazu brauchen wir jetzt wieder die gleiche URL wie oben, allerdings erweitert noch um den Pfadbestandteil von Checkmk, nämlich "/check_mk/". |
[0:08:06] | Den Rest kann man hier erstmal so lassen, und ich speichere. Der nächte Schritt ist, dass ihr euch bei der Remote-Site sozusagen einloggt. |
[0:08:17] | Bis jetzt haben wir einfach nur eine Verbindung hergestellt, aber was wir jetzt brauchen, ist ein Administrator-Zugang auf diese Remote-Site, und den gebt ihr ein, wenn ihr hier auf dieses Schlüsselsymbol klickt. |
[0:08:29] | Momentan sind wir noch nicht eingeloggt, können also noch keine Konfiguaration verteilen, wenn ich aber hier auf den Schlüssel klicke, dann kann ich mich einmalig als "cmkadmin" auf der Remote-Site anmelden, ihr müsst dann nochmal bestätigen, dass die Konfiguration, die da eventuell schon ist, überschrieben wird. Bei uns ist die Site ja leer, weil wir die ganz frisch angelegt haben. Wenn ihr aber da schon ganz lange gearbeitet habt, vielleicht hunderte Hosts überwacht oder Tausende, würden die jetzt tatsächlich komplett überschrieben werden, also eine bestehende Remote-Site einzubinden, ist dann so automatisch nicht möglich, wenn ihr die Hosts, die da eingepflegt worden sind, schon übernehmen wollt, müsste man das auf einem anderen Weg machen. |
[0:09:10] | Ich überschreibe jetzt die Konfiguration, drücke "Login", und jetzt habe ich eine Verbindung hergestellt. |
[0:09:17] | Ich habe also hier rechts den grünen Haken. Das ist der Haken für die Konfigurationsverbindung, also für das Pushen der Konfiguration, und der linke grüne Haken ist für die Status-Verbindung, die brauche ich, um den aktuellen Monitoring-Status der Host und Services von der Remote-Site zu sehen. |
[0:09:31] | So, um das Ganze auszuprobieren, wollen wir jetzt einfach mal einen neuen Host ins Monitoring aufnehmen, der in Singapur überwacht wird. |
[0:09:39] | Das heißt, wir sind ja immer noch angemeldet auf der Münchener Instanz, und wollen ein Host anlegen, so, das der in Wirklichkeit in Singapur angelegt wird. Und das ist eigentlich gar nicht mal so schwer. |
[0:09:51] | Ich klappe meine Seitenleiste wieder auf, gehe jetzt in die Host-Verwaltung, und lege hier einfach einen neuen Host an. |
[0:10:04] | Den nenne ich jetzt zum Beispiel "cmksingapur" und möchte einfach mal als Erstes den Checkmk-Server in Singapur selbst überwachen. |
[0:10:14] | Jetzt kommt der entscheidende Punkt, hier ist ein Attribut "Monitor on site", also ihr sagt von welchem Standort aus soll dieses System überwacht werden, und da wähle ich jetzt "remote1" aus, das bedeutet also dass quasi der Server vor Ort dann auch diese Anfrage an den Agenten machen wird, und der kann ja vielleicht auch in andere Netzwerkbereiche reingehen als der von meiner Zentral-Instanz aus. |
[0:10:40] | Der Rest ist wie gehabt, ich gebe die IP-Adresse an, aber natürlich jetzt die, die ich brauche, um von Singapur direkt auf das System zuzugreifen, und mehr muss ich eigentlich nicht tun. |
[0:10:57] | Natürlich muss wie immer der Agent auf dem System installiert sein, dann kann ich wieder zu meiner Service-Konfiguration gehen, und jetzt ist es bereits so, dass auch schon diese Service-Erkennung bereits das System in Singapur verwendet. |
[0:11:14] | Das heißt, dort wird dann der Agent kontaktiert, und die zu überwachenden Services ermittelt. Das sieht alles genau so aus, wie wenn es lokal wäre, und es ist auch Absicht, weil das ganze System soll ja aussehen wie ein großes Monitoring-System. Das heißt, ich sage jetzt einfach, dass er alle Services monitoren soll, mache meine "Activate changes" und dort sehen wir eine zweite Änderung, und zwar sehen wir jetzt nicht wie früher nur eine Zeile, sondern wir sehen unsere beiden Systeme hier als jeweils zwei Zeilen. So, und jetzt werden euch hier beim Activate Changes immer dieses Systeme, also die Remote-Instanzen angezeigt, auf denen es Änderung gibt, die aktiviert werden müssen. Wir haben hier ein Host in Singapur aufgenommen, deswegen ist die Instanz in Singapur so markiert, dass sie einen Restart für die Konfiguration benötigt. Die lokale Instanz hat diesen Haken, die ist up-to-date. |
[0:12:09] | Da haben wir auch nichts geändert. |
[0:12:10] | So, wenn ich jetzt hier "Activate affected" mache, bedeutet dass alle Instanzen die Änderungen haben, automatisch aktiviert werden. Deswegen drücke ich einfach nur hier drauf, und ihr seht, das jetzt dieser Balken bei Remote-Instanz läuft, und jetzt sind wieder alle Instanzen mit dem grünen Haken markiert, und die Änderung ist aktiviert. |
[0:12:31] | Wenn ihr jetzt in die Liste der Hosts reingeht, dann seht ihr das hier in Singapur ein neuer Host aufgetaucht ist. Die Gesamtzahl von 6 Hosts sehen wir hier. |
[0:12:42] | Das sind eben 5 auf der Instanz mysite, und einer in Singapur, und somit haben wir einen verteiltes Monitoring aufgebaut, was ich letztlich anfühlt, wie ein großes Monitoring-System, aber die Vorteile hat, dass es eben skalierbar ist über viele, viele Instanzen, dass es ausfallsicher ist, dass ihr in sichere Netzwerkbereiche rein monitoren könnt, ohne durch die Firewall durch zu monitoren, und viele weitere Vorteile habt. Da ihr für jede Instanz einen Status seht. |
[0:13:13] | Das ist jetzt neu unten erschienen, und ich sehe es eben hier im Site-Satus, ich habe eine Local-Site, "mysite" heißt die, und ich habe die Instanz Singapur, und mit dem Snap-in könnt ihr jetzt zwei Sachen machen: Zum einen sieht ihr, ob diese Instanz gerade erreichbar ist, was hoffentlich der Fall ist, und ihr könnt sie auch ausblenden. |
[0:13:33] | Wenn ich jetzt zum Beispiel mal auf die Ansicht meiner Hosts gehe, und blende jetzt Singapur aus, dann sehe ich auch nur noch die Elemente aus der lokalen Instanz oder ich kann es auch umgekehrt machen, und die sind ganz ausschalten, dann sehe ich nur die Hosts in Singapur. |
[0:13:49] | Es ist wichtig zu wissen, was passiert eigentlich, wenn eine Instanz nicht erreichbar ist? Nun, das Grundprinzip von verteiltem Monitoring von Checkmk ist so, dass alle Monitoring-Daten grundsätzlich auf der Remote-Instanz bleiben, und nicht die ganze Zeit in die Zentrale kopiert werden. |
[0:14:06] | Das ist ein wichtiges Prinzip, weil nur das die maximale Skalierung ermöglicht. |
[0:14:11] | Wenn ihr euch vorstellt, dass ihr vielleicht 100 Remote- Instanzen habt, die eine Million Hosts überwachen, wäre sehr sinnlos, alle ohne die Zugangsdaten in eine zentrale Datenbank schreiben zu müssen. |
[0:14:19] | Also keine Datenbank der Welt würde das hergeben, dass ihr so viele Daten in so kurzer Zeit da unterbringt. |
[0:14:25] | Deswegen macht das Checkmk so, dass die Monitoring-Daten grundsätzlich auf den Remote-Instanzen bleiben, das hat erstens den Vorteil, das es sehr, sehr gut skaliert, und es hat noch den weiteren Vorteil, dass die Remote-Instanz auch dann eigenständig funktioniert, wenn die Zentrale mal nicht erreichbar ist. Das heißt jetzt für euch, wenn eine Remote-Instanz gerade nicht erreichbar ist, dann seht ihr nicht etwa von der veraltete Daten, sondern seht überhaupt keine Daten. Die ist einfach nicht sichtbar. |
[0:14:52] | Ihr seht im Site-Status einen Fehler und es wird dann auch hier in den Status-Ansichten ein roter Fehlerbalken eingeblendet, dass die Daten unvollständig sind. |
[0:15:00] | Beim Monitoren kann man ja sowieso sagen: Unvollständige Daten sind genauso nutzlos, wie veraltete Daten. Also, wenn die Remote-Site ganz weg wäre, würde es sowieso nicht viel nutzen zu wissen, wie der Status von vor einer Stunde war, sondern mich interessiert immer der aktuelle Status, aber das muss man beim verteilten Monitoring von Checkmk wissen. Vorteil ist jetzt, sobald die Remote-Instanz wieder da ist, habt ihr sofort den aktuellen Status, also es gibt keinen Rückstau von irgendwelchen Monitoring-Updates, die per, was weiß ich für Messenger, irgend eine Zentrale geschoben werden müssen, sondern ihr habt sofort auf die Sekunde wieder aktuelle Daten aus der Remote-Instanz und habe keinerlei Zeitverzug. |
[0:15:38] | Ja, und damit sind wir hier erstmal fertig mit dem verteilten Monitoring. |
[0:15:42] | Da gibt es natürlich auch noch sehr viele interessante Aspekte, wie was passiert mit Alarmierungen? Was passiert mit der Event-Konsole und so weiter. Und diese ganzen Details findet ihr natürlich im Benutzerhandbuch in einem sehr ausführlichen Artikel über das verteilte Monitoring. |
[0:15:55] | Und, da rate ich euch auch dann reinzuschauen, wenn ihr die Raw Edition verwendet, dann solltet ihr nämlich bei der Konfiguration der Remote- Standorte einen sogenannten Status-Host eintragen, damit im Falle eines Ausfalls die Benutzeroberfläche nicht ewig wartet auf Daten, sondern dann die Site als fehlerhaft erkennt und sofort weiter macht. |
[0:16:13] | Ja, Danke fürs mitmachen, ich hoffe es war für euch interessant, und wir sehen uns dann hoffentlich beim nächsten Video. |
Wollen Sie mehr über Checkmk erfahren? Dann nehmen Sie an unserem Webinar "Einführung in Checkmk" teil!