Funktionsweise

In den nachfolgenden Kapiteln wird ein Einblick in die Funktionsweise des Runtime Supervisor gegeben. Viele Prozesse laufen vollständig automatisiert ab, wie z.B. das Senden von Event Logs von einem Observable an den Runtime Supervisor, das Versenden von eMails beim Eingang eines bestimmten Event Logs oder die Verbindungsüberwachung in Echtzeit. Um diese Prozesse besser verstehen zu können, werden nachfolgend die wichtigsten Prozesse auf technischer Ebene erläutert.

Identifikation von Observables

Der Runtime Supervisor muss Observables eindeutig zuordnen können. Ein Print Service hat z.B. eine ID in Form einer Guid. Diese ist jedoch für den Runtime Supervisor nicht eindeutig. Wird dieser Print Service z.B. mit derselben Konfiguration auf einem anderen Server gestartet (zum Test), sollte dieser vom Runtime Supervisor auch als eigenständiger Print Service erkannt werden, da der Print Service auf dem anderen Server gleichzeitig gestartet werden könnte.

Abhilfe schafft die sogenannte „Client ID“, mit der sich ein Observable am Runtime Supervisor registriert. Diese ist ein 32 Bit langer MD5-Hashwert, der sich je nach Observable-Typ aus unterschiedlichen Bausteinen zusammensetzt. Nachfolgende Liste gibt Aufschluss darüber:

Broker:

Domain + Server + Install Name + Application Name + Application Pool Name

Service Host:

Domain + Server + Install Name + Service Host Name

Authentication Service:

Domain + Server + Authentication Service ID

Print Service:

Domain + Server + Print Service ID

Document Service:

Domain + Server + Document Service ID

Der „Install Name“ ist der Name der Installation, der beim Publish in Framework Studio angegeben wird. Der „Application Name“ ist der Name der Framework Studio Application, die gepublisht wird. Sollte der Rechner, auf dem ein Observable läuft, nicht in einer Domäne registriert sein, wird diese nicht in den Hashwert mit aufgenommen.

Registrierung von Observables

Wie in Kapitel 5 erläutert wurde, benötigt ein Observable ausschließlich die URL des Runtime Supervisor Windows Service, um sich erfolgreich am Runtime Supervisor registrieren zu können und die Überwachung durch diesen zu initiieren.

Wenn ein Observable konfiguriert wurde, sich mit dem Runtime Supervisor in Verbindung zu setzen, startet dieses beim Programmstart einen Prozess, der versucht, den Runtime Supervisor zu erreichen und sich an diesem zu registrieren. Hierfür wird die URL verwendet, die zuvor konfiguriert wurde.

Das Observable startet nun den ersten Versuch, mit dem Runtime Supervisor Kontakt aufzunehmen. Bei diesem Request werden alle Daten übertragen, die nötig sind, um das Observable am Runtime Supervisor anzulegen. Diese Daten beinhalten hauptsächlich alle statischen Werte, die sich zur Laufzeit des Observables nicht ändern können (z.B. das Betriebssystem). Ist dem Runtime Supervisor das Observable mit der übertragenen Client ID schon bekannt, werden alle Daten entsprechend aktualisiert. Wurde der Registrierungsvorgang vom Runtime Supervisor erfolgreich bearbeitet, bekommt das Observable eine entsprechende Antwort.

Erhält das Observable die Antwort, dass alles fehlerfrei bearbeitet wurde, wird der Registrierungsprozess auch an diesem abgeschlossen. Die Verbindung für die Überwachung seitens des Runtime Supervisor ist somit aufgebaut.

Erhält das Observable die Antwort, dass ein Fehler aufgetreten ist oder erhält es nach einem Timeout sogar gar keine Antwort (Runtime Supervisor nicht erreichbar), dann wird in einem Intervall von 30 Sekunden immer wieder versucht, den Runtime Supervisor zu erreichen. Beim ersten Fehlversuch wird zudem ein entsprechender Eintrag in das Windows Event Log geschrieben. Verbindet sich ein Observable also nicht mit dem Runtime Supervisor, kann das Windows Event Log über den Grund Aufschluss geben.

Parallelität

Observables wie z.B. ein Authentication Service müssen neben der Kommunikation mit dem Runtime Supervisor auch “ihren eigenen Job machen”. Es kann natürlich sein, dass während des Abarbeitens eines Prozesses, der in Verbindung mit dem Runtime Supervisor steht, auch kritische Fehler auftreten. Diese potenziellen Fehler dürfen allerdings keinen Einfluss auf die eigentliche Aufgabe des Observables haben.

Scheitert z.B. ein Authentication Service auf Grund eines Fehlers dabei, sich am Runtime Supervisor zu registrieren, darf dieser Fehler nicht zur Folge haben, dass der Authentication Service abstürzt und seinen eigentlichen Job nicht mehr machen kann. Deswegen laufen alle Prozesse, die in Zusammenhang mit dem Runtime Supervisor stehen, völlig losgelöst von den Hautprozessen der Observables.

Überwachung der Verbindung

Nachdem ein Observable erfolgreich am Runtime Supervisor registriert wurde, besteht ab diesem Zeitpunkt eine dauerhafte Verbindung. Diese Verbindung basiert auf ASP.NET SignalR. Eine SignalR-Verbindung wird automatisch auf drei Ebenen überwacht und generiert Events, die vom Runtime Supervisor und dem Observable verarbeitet werden können (z.B. ein Verbindungsabbruch).

Die drei Ebenen der Verbindung sind die folgenden:

Physisch:

Die physikalische Verbindung ist das Kabel selbst. Wird der Netzwerkstecker gezogen, bricht die physische Verbindung ab.

Transport:

Die Transport-Verbindung ist in den meisten Fällen die TCP-Verbindung. Sie kann auch erhalten bleiben, wenn die darunter liegende physische Verbindung kurz unterbrochen wird (Packet Loss).

Logisch:

Die logische Verbindung wird von SignalR selbst aufrechterhalten. Sie wird mit einer ID versehen und kann auch längere Unterbrechungen der physischen Verbindung oder auch der Transport-Verbindung überstehen. So kann ein Observable z.B. innerhalb von 30 Sekunden nach dem Ziehen des Netzwerksteckers mit dem Runtime Supervisor „reconnected“ werden, ohne die logische Verbindung zu unterbrechen.

Eine ausführliche Beschreibung der Funktionsweise einer SignalR-Verbindung würde den Rahmen dieser Dokumentation sprengen. Eine sehr gute Erklärung auf technischer Ebene bietet die ASP.Net SignalR Dokumentation von Microsoft. Diese finden Sie unter folgendem Link:

http://www.asp.net/signalr

Verarbeiten von Event Logs

Wenn an einem Observable ein Event auftritt, resultiert dies meist aus einem unbehandelten Fehler bei der Ausführung des Programms. Diese Events wurden bisher dezentral in die vom Observable-Typ abhängigen Logs geschrieben (meist das Windows Event Log). Ist der Runtime Supervisor für ein Observable konfiguriert, wird dieses nach erfolgreicher Registrierung versuchen, Event Logs ausschließlich an den Runtime Supervisor zu schicken. Für den Fall, dass der Runtime Supervisor nicht verfügbar ist, oder beim Verarbeiten des Event Logs ein Fehler auftritt, gibt es Fallbacks, die garantieren, dass keine Event Logs „verloren gehen“.

Log Store

Tritt ein Event am Observable auf, wird diesem eine ID in Form einer Guid gegeben (hier im Text und in Abbildung 41 vereinfacht dargestellt). Das Event bekommt im Beispiel die ID 1. Es wird sofort vom Obvservable versucht, dieses Event über die bestehende SignalR-Verbindung an den Runtime Supervisor zu schicken. Dieser könnte zu diesem Zeitpunkt im schlechtesten Fall nicht erreichbar sein oder einen Fehler bei der Verarbeitung des Events produzieren. Im ersten Fall bekommt das Observable keine Antwort (Timeout). Im zweiten Fall bekommt das Observable die Antwort, dass sein Event nicht ordnungsgemäß verarbeitet wurde.

In beiden Fällen wird das Event (ID 1) in den sogenannten “Log Store” geschrieben. Dieser beinhaltet alle Event Logs, die am Observable aufgetreten sind, jedoch noch nicht vom Runtime Supervisor verarbeitet wurden.

Note

Der Timestamp, der zu jedem Event Log im Runtime Supervisor gespeichert wird, ist der Zeitpunkt, zu dem das Event am Observable aufgetreten ist.

Nun tritt kurz darauf (innerhalb von 30 Sekunden) ein zweites Event ein (ID 2). Es wird wieder versucht, dieses sofort an den Runtime Supervisor zu schicken. Zuvor wird jedoch überprüft, ob sich noch nicht verarbeitete Events im Log Store befinden. Ist dies der Fall (ID 1), so werden alle Events aus dem Log Store mit dem neu aufgetretenen Event an den Runtime Supervisor geschickt. Im Beispiel also Event 1 (aus dem Log Store) und Event 2. Nun kann der Fall eintreten, dass nur eines der beiden Events erfolgreich am Runtime Supervisor verarbeitet wird. Beim Versuch, Event 2 in die Datenbank zu schreiben könnte z.B. ein Fehler auftreten.

In diesem Fall sendet der Runtime Supervisor in seiner Antwort an das Observable alle ID’s mit, die erfolgreich verarbeitet wurden. Das Observable stellt also fest, dass Event 1 nun erfolgreich verarbeitet wurde, Event 2 jedoch nicht. Die Folge ist, dass Event 2 nun in den Log Store geschrieben wird. Event 1 wurde erfolgreich verarbeitet und wird aus dem Log Store entfernt.

Tritt nun erst einmal kein weiteres Event am Observable auf, wird alle 30 Sekunden überprüft, ob sich Events im Log Store befinden. Ist dies der Fall, wird alle 30s versucht, diese an den Runtime Supervisor zu schicken. Im Beispiel wird Event 2 nach 30s nochmals zum Runtime Supervisor geschickt und erfolgreich verarbeitet. Danach ist der Log Store am Observable leer.

Fallback

Event Logs dürfen nicht einfach verloren gehen, nur weil der Runtime Supervisor vielleicht nicht erreichbar ist oder selbst beim Verarbeiten auf einen Fehler stößt. Eine logische Folge aus dieser Situation wäre, dass der Log Store am Observable immer größer und niemals abgearbeitet wird. Im schlechtesten Fall läuft der Arbeitsspeicher des Rechners langsam mit Event Logs voll.

Beenden des Observables

Das Observable kann jederzeit beendet werden. Z.B. beim Update eines Authentication Service muss z.B. der Windows Service neu installiert werden. Zu diesem Zeitpunkt könnten sich jedoch noch nicht verarbeitete Event Logs im Log Store befinden.

Das Observable bekommt aber mit, wenn es heruntergefahren wird. Es wird dann noch einmal versucht, die Events aus dem Log Store an den Runtime Supervisor zu senden. Schlägt dies fehl, werden alle nicht verarbeiteten Events in das bisherige Log des Observables geschrieben (meist das Windows Event Log).

Sendeintervall

Normalerweise werden die Events aus dem Log Store auch dann noch einmal zum Runtime Supervisor geschickt, wenn ein neues Event auftritt. Ist letzteres nicht der Fall, wird alle 30s überprüft, ob sich nicht verarbeitete Events im Log Store befinden und diese nochmals an den Runtime Supervisor geschickt.

Kann ein Event innerhalb von 10 Minuten, aus welchem Grund auch immer, nicht am Runtime Supervisor verarbeitet werden, so wird dieses automatisch aus dem Log Store entfernt und in das Standard-Log des Observables geschrieben (Windows Event Log).

Die Überprüfung, ob sich Events, die älter als 10 Minuten sind, im Log Store befinden, erfolgt jede Minute einmal.

Versenden von eMails

Für das Versenden von eMails durch den Runtime Supervisor gibt es zwei Möglichkeiten:

1. SMTP (.NET SMTP Client)
2. OAuth/Graph (Microsoft.Graph API und Azure.Identity Bibliothek)

Der Ablauf ist dabei immer gleich. Beim Eingang eines Event Logs am Runtime Supervisor wird überprüft, ob SMTP oder Graph für den Runtime Supervisor aktiviert wurde. Ist dies der Fall, dann werden alle Empfänger überprüft, die für den Event Log Level (Error, Warning, etc.) des eingegangenen Events eine Nachricht erhalten sollen (siehe Kapitel Alerting). Anschließend wird die eMail generiert und an jeden Empfänger versendet.

Generierung der eMails

Der Betreff der eMail beinhaltet Typ und Name des Observables. Im Text erscheint an erster Stelle das Event Log mit seinem Event Log Level und der Uhrzeit, zu der das Event am Observable aufgetreten ist. Danach kommt der eigentliche Text des Event Logs.

An jede eMail vom Runtime Supervisor wird eine Zusammenfassung des Observables angehängt, zu dem das Event Log gehört.

Der Link zur Seite des Observables in dieser Zusammenfassung wird nur generiert, wenn in den “Web Application Settings” des Runtime Supervisor die URL für “Web Application Root” definiert wurde (Siehe Kapitel Web Application).

Aktualisierung dynamischer Daten

Jedes Observable sendet Daten an den Runtime Supervisor, die sich zur Laufzeit ändern können. So kann sich z.B. der verfügbare Speicherplatz der lokalen Partitionen ändern. Diese dynamischen Daten werden periodisch an den Runtime Supervisor übertragen. Das Sendeintervall beträgt 5 Minuten. Statische Daten, wie z.B. Informationen über die Hardware des Rechners, sind von diesem Vorgang ausgeschlossen.

Aktualisierung der Settings

In der Web Application des Runtime Supervisor können im Bereich Settings (siehe Kapitel Settings) Einstellungen vorgenommen werden. Es kann während der Laufzeit des Runtime Supervisor Windows Service z.B. ein neuer Empfänger für eMails eingetragen werden.

Einstellungen für die Web Application werden sofort übernommen und angewendet. Wenn z.B. die Einstellung „Number of records per page in events grid“ geändert wird und danach in die Event-Tabelle gewechselt wird, ist die neue Anzahl der Einträge auf einer Seite der Tabelle zu sehen.

Für den Windows Service gilt dies nicht! Der Windows Service arbeitet mit sehr vielen parallelen Prozessen und kann deshalb nicht einfach auf Knopfdruck sämtliche Einstellungen übernehmen, ungeachtet dessen, was die Prozesse gerade verarbeiten.

Der Windows Service kümmert sich deswegen im Intervall von 5 Minuten selbst darum, die in der Datenbank gespeicherten Settings zu aktualisieren. D.h., wird in der Web Application eine Einstellung geändert, die den Windows Service betrifft (z.B. die SMTP-Einstellungen) und werden diese gespeichert, heißt das erst einmal, dass sie korrekt in die Datenbank geschrieben werden. Ab diesem Zeitpunkt können also maximal 5 Minuten vergehen, bis der Windows Service die gespeicherten Einstellungen auch übernimmt. Im konkreten Fall kann es also sein, dass nach dem Speichern der SMTP-Einstellungen der Windows Service trotzdem noch für maximal 5 Minuten eMails über den zuvor aktiven SMTP-Server verschickt.