Service fernüberwachen

[Captnemo]

Ich muss für ein Projekt, welches aus verschiedenen Programmen und mehreren Diensten besteht, die Möglichkeit einbauen, dass von einem entfernten Arbeitsplatz die Dienste überwacht werden können.

Im genaueren geht es darum, dass die Pförtner in ihrem Kassenprogramm (gehört auch zu diesem Projekt) eine Info sehen sollen, ob die Serverdienste (gehören ebenfalls zu diesem Projekt) laufen, und diese ggf. auch starten können sollen. Letzteres allerdings ohne sich auf den Server aufschalten zu müssen, denn diese Rechte sollen sie nicht bekommen.

Wie würde man so was am Sinnvollsten realisieren. Sowohl die Anzahl der zu überwachenden Dienste, als auch die Anzahl der überwachenden Programme kann sich verändern.

Das Starten der Dienste kommt später, das werde ich wohl über einen Helperservice realisieren. Erst mal soll aber die Überwachung laufen.

Ich hatte mir überlegt, das per UDP-Broadcast zu machen. Soll heißen, jeder Dienst sendet einen UCP-Broadcast in definierten Intervallen ins Netzwerk. Jeder gestartete Client kann diese empfangen. Kommt von einem Dienst keine Broadcast mehr, so kann man ja davon ausgehen, dass er nicht mehr reagiert, pausiert oder beendet wurde, und der Pförtner kann reagieren.
Wäre das mit einem UDP-Broadcast schon das sinnvollste, oder gibt es noch bessere Möglichketen?

Später kann ggf. der Helperservice selbst einen Neustart der Dienste übernehmen, aber die Pförtner sollen auf jeden Fall sehen können, ob die benötigten Dienste laufen.

[Nersgatt]

Ich würde die Überwachung der Dienste nicht in den Diensten selbst implementieren, sondern in einem eigenen Dienst.
So kann sich der Dienst auf seine Kernaufgabe konzentrieren. Außerdem kannst Du dann den Überwachungsdienst einfacher auf weitere Dienste ausweiten, ohne die zu überwachenden Dienste anfassen zu müssen.

Bei dem Überwachungsdienst würde ich sowas wie einen Observer implementieren, wo die Clients ihre Interesse an dem Status eines bestimmten Dienstes kund tun können. Der Überwachungsdienst informiert dann die Clients über Änderungen und nimmt auch Start- und Stopanforderungen an. Hier wäre auch die Möglichkeit z.B. ein Rechtesystem zu implementieren, ohne die zu überwachenden Dienste anfassen zu müssen.

[Klaus01]

Zitat:

Zitat von Captnemo (Beitrag 1297605)

Wäre das mit einem UDP-Broadcast schon das sinnvollste, oder gibt es noch bessere Möglichketen?

Broadcasts funktionieren nur in einem Netzsegment - Broadcasts werden in der Regel nicht geroutet.

Grüße
Klaus

[Sir Rufo]

Einen kleinen Service gebaut mit einem

Delphi-Quellcode:

TIdHTTPServer

der dann z.B. eine Status-Seite anzeigen kann und darüber auch die Dienste startet.

Dabei werden einfach irgendwelche Links von dem Server aufgerufen und damit eine bestimmte Aktion ausgelöst.

PS:
Richtig nett/flexibel wird das, wenn du erst eine kleine REST-Schnittstelle implementierst. Dann kannst du dir überlegen ob du das komplett über HTML-Seiten machen möchtest und/oder über eine eigene Anwendung (Desktop/Mobil). Das ist dann wurscht, weil alle nur noch bestimmte Links aufrufen um die Aktionen auszulösen ;)

[Captnemo]

Das mit dem THTTPServer ist ne gute Idee. Den würde ich dann im Helperservice unterbringen, welcher seinerseits die Workerservices überwacht, bzw. abfragt (Ich will ggf. auch noch ein paar Statusinformationen auslesen).
Vor allen Dingen die Tatsache das ggf. auch noch auf mobilen Endgeräten darzustellen finde ich richtig nett :)

Jetzt muß ich mir nur noch überlegen, wie Kommunikation zwischen den Diensten möglichst schlank realisiere. Auch über REST?

Zitat:

Zitat von Klaus01 (Beitrag 1297607)

Broadcasts funktionieren nur in einem Netzsegment - Broadcasts werden in der Regel nicht geroutet.

Ist mir bekannt. Wäre in meinem Fall nicht tragisch, dass alles sich innerhalb eines Subnetzes befindet. Aber, der Teufel schei**t ja in die Ecke, und so kann sich so was ja auch schnell mal ändern ;)

Zitat:

Zitat von Nersgatt (Beitrag 1297606)

Ich würde die Überwachung der Dienste nicht in den Diensten selbst implementieren, sondern in einem eigenen Dienst.

Grundsätzlich stimme ich dir da zu. Aber da nicht nur die Tatsache ob der Dienst gestartet ist wichtig ist, sondern auch ob er seine Schnittstellen noch erreichen kann, muss ich schon die Workerservices selbst fragen.

[Captnemo]

Grad gesehen, die RestClient-Komponente gibt's in meinem XE4 noch gar nicht :( (oder ich bin blind)

[Captnemo]

Zitat:

Zitat von Captnemo (Beitrag 1297616)

Grad gesehen, die RestClient-Komponente gibt's in meinem XE4 noch gar nicht :( (oder ich bin blind)

Oh, ich bin doch blind ;) Datasnap

[Sir Rufo]

Ob ich dafür tatsächlich ein DataSnap benutzen würde ...

Eigentlich brauchst du nur die HTTP-Server-Komponente und sendest an den fröhlich deine Requests und von dem den Response. Wenn das was du hin- und herschickst z.B. JSON-Daten sind, dann ist das schon REST ;)

[Der schöne Günther]

Die Komponenten hätten dir in dem Fall sowieso nur leidlich geholfen. Schau mal, ich hatte vor nicht mal einer Woche genau die gleiche Frage:

http://www.delphipraxis.net/184570-e...stellen-2.html

[Captnemo]

Da ich keine zusätzlichen Komponenten einsetzen möchte, sondern nur das, was Delphi von Haus aus liefert, kann ich ja nur auf TCPServer zurückgreifen, oder sehe ich das falsch?

[himitsu]

Eigentlich wäre es besser, wenn die Clienten eine "Funktion" der Services aufrufen, um zu prüfen, ob es läuft.

Zitat:

Kommt von einem Dienst keine Broadcast mehr, so kann man ja davon ausgehen, dass er nicht mehr reagiert, paus...

Es wäre sehr aussagefähig, wenn man nur erfährt

Zitat:

Ja, der einfache und fehlerunanfälligste Teil in den Services läuft, aber ob der wichtige Teil wirklich noch läuft, ist ja egal.

Wäre also ungünstig, wenn der Kontrollteil unabhängig läuft, vielleicht auch noch in einem eigenem Thread, und er nicht die eigentlichen Funktionen prüft.
* entweder direkt eine Schlüsselfunktion aufrufen
* der die "ich funktioniere"-Notification prüft das "intern" irgendwie ab, indem sie z.B. eine/mehrere der Schlüsselfunktionen aufruft (hier spart man wenigstens Traffic)

[Nersgatt]

Zitat:

Zitat von Captnemo (Beitrag 1297622)

Da ich keine zusätzlichen Komponenten einsetzen möchte, sondern nur das, was Delphi von Haus aus liefert, kann ich ja nur auf TCPServer zurückgreifen, oder sehe ich das falsch?

Wieso, die Indykomponenten sind doch dabei. Mit dem TIdHttpServer ist ein ein kleines Serverchen schnell zusammengeklöppelt. Auf jeden Fall in den Grundzügen.

[Captnemo]

Zitat:

Zitat von Nersgatt (Beitrag 1297625)

Zitat:

Zitat von Captnemo (Beitrag 1297622)

Da ich keine zusätzlichen Komponenten einsetzen möchte, sondern nur das, was Delphi von Haus aus liefert, kann ich ja nur auf TCPServer zurückgreifen, oder sehe ich das falsch?

Wieso, die Indykomponenten sind doch dabei. Mit dem TIdHttpServer ist ein ein kleines Serverchen schnell zusammengeklöppelt. Auf jeden Fall in den Grundzügen.

Stimmt auffallend. Hatte ich gar nicht mehr in Erinnerung. Ich dachte grad, ich hätte mir die selbst installiert (weil es früher auch immer so war).

Sind die den eigentlich mittlerweile so mit Emba verheiratet, dass es die auch mit XE12 noch gibt? (Nur so am Rande gefragt)

[Nersgatt]

Setzt nicht Datasnap sogar auf Indy auf? Ich hab da irgendwie sowas im Hinterkopf.

[himitsu]

DataSnap setzt auf DBX auf und das nutzt vermutlich aktuell Indy.

[mkinzler]

Zitat:

Zitat von himitsu (Beitrag 1297631)

DataSnap setzt auf DBX auf und das nutzt vermutlich aktuell Indy.

DBX ist der Zugriff auf die Daten und nicht der Netzwerkdienst.

[himitsu]

DataSnap benutzt DBX und dessen RPC-Funktionalität für den Transport/Connection zwischen Client und Server.

DataSnap-CallCommand > TDBXContext/TDBXCommand > ... > TSQLConnection > TCustomConnection