ich bin am Verzweifeln ich habe hier eine CME Version installiert. In meinem verteilten System gibt es 3 Sites und eine Core Site. Bei allen Sites ist "** [Asynchronous local delivery plus remote forwarding] konfiguriert. Es funktionieren auch teilweise die Notfications bei ein paar Hosts. Nur ich erkenne und sehe keinen Zusammenhang zwischen den Hosts wo die Benachrichtigungen funktionieren und wo nicht.
Global Switch für Notifications ist ein
Es gibt eine Global Notification Rule wo ich Enable synchronous delivery via SMTP konfiguriert habe
Es gibt Contact Groups und zugeordnete Users
Es gibt die eine Rule für “Assignment of Host to contact groups” (Put all hosts into the contact group “all”)
Testweise wurde auch schon Permissions auf Ordnerebene vergeben
Ich gehe davon aus, dass der Fehler wieder irgendwo ein verstecktes Menü / Checkbox dgl. ist, dass ich nicht sehe.
In den Events sehe ich nicht mal den Versuch, dass ein Email versendet wird.
Hier dürfte das Problem liegen. Wenn es eine CME ist dann ist es nicht ganz unwichtig welche Sites zu welchem Customer gehören. Das ist auch dann wichtig wenn Contact Groups zugeordnet werden.
Hier ist der komplette Aufbau im Endeffekt relevant.
Wenn eine MSE Edition benutzt wird dann dürfte es in deinem System doch Customers geben. Diese werden einzelnen Sites zugeordnet und dort gibt es auch immer nur Contact Gruppen welche auch immer nur zu einem Customer gehören.
Wie gesagt um hier einen Fehler zu finden ist der komplette Aufbau des Systems relevant.
Genauso wie du es sagst, ist der Aufbau.
Es gibt Sites, dieses wurden einem Customer zugewiesen und es gibt Contact groups diese wurden einem Customer zugewiesen, mehr gibt es dazu ja nicht zu sagen?
1x Site + 1 x Customer + 1x Contact Group - fertig - mehr ist es nicht.
Kannst du mit der obigen Fehlermeldung etwas anfangen?
Error: bogus message header b’\x16\x03\x01\x01\x01\x01\x00\x00\xfd\x03’: should be an int. Closing connection
2023-12-25 20:28:06,939 [40] [cmk.mknotifyd.outgoing(x.x.x.x:6555)] Error reading data:
Traceback (most recent call last):
Was mir aufgefallen ist, dass seit gestern sich in der var/log/notify.log in der Provider Instanz nichts mehr tut… letzte Einträge sind von 25.12 - 20:00 Uhr…
2023-12-25 19:44:53,804 [20] [cmk.base.events] Configuration has changed. Restarting myself.
2023-12-25 19:44:54,165 [20] [cmk.base.events] We are back after a restart.
2023-12-25 19:44:54,166 [20] [cmk.base.events] CMC has closed the connection. Shutting down.
2023-12-25 19:44:54,624 [20] [cmk.base.events] Starting in keepalive mode with PID 1676542
2023-12-25 19:53:53,941 [20] [cmk.base.events] Configuration has changed. Restarting myself.
2023-12-25 19:53:54,297 [20] [cmk.base.events] We are back after a restart.
2023-12-25 19:53:54,298 [20] [cmk.base.events] CMC has closed the connection. Shutting down.
2023-12-25 19:53:54,726 [20] [cmk.base.events] Starting in keepalive mode with PID 1680582
2023-12-25 19:57:45,354 [20] [cmk.base.events] Starting in keepalive mode with PID 1890
2023-12-25 20:01:53,501 [20] [cmk.base.events] Configuration has changed. Restarting myself.
2023-12-25 20:01:53,883 [20] [cmk.base.events] We are back after a restart.
2023-12-25 20:01:53,883 [20] [cmk.base.events] CMC has closed the connection. Shutting down.
2023-12-25 20:01:54,294 [20] [cmk.base.events] Starting in keepalive mode with PID 4285
Da musst wohl oder übel mal deinen Support Partner oder direkt in München anfragen.
Bei einem MSE Aufbau würde ich immer die Sites der einzelnen Customer auch die Mails versenden lassen welche diesem Customer gehören.
Die Central Site würde ich hier raus lassen, da diese ja eigentlich nix von den Customern wirklich weiß.
Die Idee dahinter ist ganz einfach - Es gibt einen zentralen Server, der das eben machen soll. Dieser ist möglichst “weit” vom Kundenenvironment weg… Die Central Site teilt auch die Konfiguration aus. Dh. die Kundensites sind nur “Distributed Sites”.
Seufz ich hoffe mal das sich jemand im Forum findet, der mir mit den Notifications helfen kann, denn offenbar funktioniert nur die Notification auf der Central Site.
Ich denk also das der Fehler beim forwarding an die Central Site liegt…
Aber halt nicht so einfach in einer MSE Umgebung.
Die Benutzer welche auf der Customer Site existieren existieren eigentlich auch nur dort und nie in der Zentrale. Außer es sind explizit globale Benutzer.
Wie gesagt sprich mal deinen Aufbau mit deinem Partner oder dem Team in München durch ob das so überhaupt funktionieren kann.
Also lokal beim Kunden gibt es nur die Basic Checkmk Installation dh. auch keine angelegten Benutzer, weil ja die Konfiguration von der Zentrale gepushed wird. Lokal beim Kunden wurde auch nichts konfiguriert. Es handelt sich hier ja um eine distributed Instanz und um keine Eigenständige!
Natürlich sind User / Kontaktgruppen angelegt worden (aber nur in der Zentralinstanz) und das ist lt. Doku auch etwas was die Zentralinstanz repliziert:
Zentrale Konfiguration
Bei einem verteilten System via Livestatus wie oben beschrieben, ist es durchaus möglich, dass die einzelnen Instanzen von unterschiedlichen Teams eigenverantwortlich gepflegt werden und die Zentralinstanz lediglich die Aufgabe hat, ein zentrales Dashboard bereitzustellen.
Falls aber mehrere oder alle Instanzen von den gleichen Menschen administriert werden sollen, ist eine zentrale Konfiguration viel komfortabler. Checkmk unterstützt dies und wir sprechen dann von einer verteilten Konfigurationsumgebung. Dabei werden alle Hosts und Services, Benutzer und Rechte, Zeitperioden, Benachrichtigungen u.s.w. im Setup der Zentralinstanz zentral gepflegt und dann automatisch nach Ihren Vorgaben auf die Remote-Instanzen verteilt.
So ein System hat nicht nur eine gemeinsame Statusoberfläche, sondern auch eine gemeinsame Konfiguration und fühlt sich dann endgültig wie „ein großes System“ an.
Ich gehe hier jetzt von einem Bug aus - in der Zwischenzeit ging 20 Stunden Troubleshooting drauf und ich bin mir sehr sicher, dass es nicht an mir liegt.
Aber wie gesagt - wenn du eine MSE Installation verwendest dann wird das alles nicht so einfach und unbedingt repliziert. Das ist ja gerade Sinn und Zweck einer MSE, dass man nicht auf jedem Satelliten die Konfiguration komplett hat.
Gibt im Handbuch schon einen Abschnitt zur MSE Die Managed Services Edition - Checkmk als Dienstleistung anbieten
Der ist nicht sehr lang aber zeigt die Komponenten welche Customer spezifisch sind schon alle auf.
Bei einer MSE ist halt die Planung des Aufbaus der wichtigste Punkt.
Kommt halt drauf an was man machen will.
Den Abschnitt kenne ich natürlich. Auf der Kundenseite kann ich, wenn ich mich dort einlogge auch keine Konfiguration machen:
In der Dokumentation finde ich auf jeden Fall keinen Punkt, dass die distributed Notification nicht funktionieren soll. Es ist wirklich zum Mäuse melken.
Die Information birgt in Wahrheit viel Interpretationsfreude:
Checkmk wird jetzt bei der Verteilung der Konfigurationsdaten nur diese zu einer Kundeninstanz schicken, welche entweder allgemeiner Natur sind oder für diese Instanz freigegeben wurden. Die Konfiguration kann von dem Dienstleister weiterhin bequem über das zentrale Setup seiner eigenen Instanz erfolgen.
Die folgenden Elemente in Checkmk können einem Kunden zugewiesen werden:
Es wäre hilfreich zu wissen, was explizit in der CME nicht funktioniert gegenüber der Standard Version. Ich bin beim Kauf der Lizenz vom Featureset der Standardversion ausgegangen. Kennst du ev. so ein Paper?
Das funktioniert schon in einer MSE auch. Nur ist es halt wichtig wie die Benutzer definiert sind und was wie an Notifications versendet wird.
Das funktioniert schon alles auch in der MSE. Es ist aber anders zu konfigurieren. Die Notifications sind hier das komplizierteste meiner Meinung nach.
Du wirst es kaum glauben, aber ich habe nun einen Fortschritt in der Sache.
Es muss ein User für den spezifischen Kunden angelegt sein.
E-Mail-Adresse muss ausgefüllt sein
Unabhängig wer noch in der Contact Group ist, wird nur dieser User alarmiert
Egal ob in der Notification Rule steht, dass es abhängig von der Contact Group ist
Dh. Es gibt keine Gruppen die ich alarmieren kann, sondern es muss pro zu alarmieren Benutzer ein User erstellt werden, der explizit dem Customer zugewiesen werden muss. (Ein User kann nur einem Customer zugewiesen werden).
Wenn das wirklich so ist und ich habe es gerade so getestet, ist das ziemlicher Mist, weil es ja als Service Provider klar sein muss, dass mehrere User alarmiert werden sollen. Jetzt muss pro Customer immer alle zu alarmieren Personen hinterlegt werden…
Ich schließe mich meinen Vorrednern mal in einer Sache an: Hier scheint es noch einiges an Lernpotential zu geben und ich würde definitiv empfehlen über Consulting nachzudenken.
Damit können dann sowohl offene Fragen geklärt werden, als auch eine Menge Wissen transportiert werden.
