Detection Pattern

Zusammenfassung
 Eine Komponente im System soll das System oder Teile davon überwachen und ggf. Aktionen einleitet.

Kontext
 Gegeben sei ein hochverfügbares System, bei welchem das Verhalten Innerhalb und zwischen den Komponenten bekannt ist. Ausserdem ist bekannt wie viel Zeit für die typsichen Aufgaben benötigt wird.

Problem
 Fehler können immer passieren. Stilles Verwerfen von fehlerhaften Operationen ist der sicherste Weg, dass das System weiterhin verfügbar bleibt. Dies ist der Fall, weil Fehler sich nicht verbreiten können. Allerdings kann es vorkommen, dass andere Teile des Systems nichts vom Fehler mitbekommen und deshalb nicht korrekt reagieren.

Lösung
 Als Lösung wird ein System Monitor im System bestimmt. Jener überwacht andere Komponenten um sicher zu stellen, dass sie korrekt arbeiten. Wenn eine überwachte Komponente stoppt, soll der Monitor dies an den FAULT OBSERVER weiterleiten oder Recovery Schritte einleiten.

Konsequenzen & Schlussfolgerung
 Dank dem, dass Fail-Silent Komponenten überwacht werden, können sich Fehler nicht im System verbreiten und andere Teile des Systems trotzdem darauf reagieren.

Zusammenfassung
 Durch Bestätigungen der Gegenseiten, wird sichergestellt, dass die Nachricht angekommen und verstanden wurde.

Kontext 
 Ein fehlertolerantes System bei dem verlässlich mit dem System Monitor kommuniziert werden kann.

Problem
 Typischerweise Bestehen Anfragen an System nur aus der Aufgabe was zu tun ist. Allerdings kann es beim Übermitteln der Aufgabe, oder in der Aufgabe selbst, Fehler geben, ohne dass der Sender der Nachricht davon erfährt.

Lösung
 Um zu garantieren, dass die Nachricht korrekt übertragen und richtig verstanden wurde, wird für jeden Nachricht mit einer Bestätigung geantwortet. Wenn der Sender kein Acknowledgement auf seine Anfrage erhält, kann er entsprechende Schritte einleiten. Je nach Kontext kann dies bedeuten, dass der Fault Observer alamiert werden muss und/oder im Sinne von RIDING OVER TRANSIENTS die Anfrage erneut gesendet wird.

Konsequenzen & Schlussfolgerung
 Korrekt übermittelte Operationen werden durch das verwenden von Acknowledgements bestätigt. Ein sofortiges Bestätigen des Erhaltes eines Request ohne schon eine Antwort zu haben kann auch sinnvoll sein. Wenn aber ein System keine Anfragen beantwortet, kann auch kein Status zurückgeschickt werden.

Zusammenfassung
 Der System Monitor überwacht ein anderes System. Entweder wird er mit einer Nachricht über den Status des jeweiligen Systems informiert oder er fragt selber danach.

Kontext
 Um die MTTR zu verkürzen, müssen Fehler so schnell wie möglich erkannt werden. Kommunikationspfade besitzen eine begrenzte Laufzeit.

Problem
 Während die Aktivität auf dem zu überwachenden Task gering ist, kann es erscheinen, als ob er tot ist. Er muss also etwas unternehmen, um sein Zustand bekanntzugeben.

Lösung
 In einem regelmässigen Abstand teilt der überwachte Task sein Systemstatus am SYSTEM MONITOR mit, die sogenannte Heartbeat-Response. Empfängt man kein Heartbeat-Response innerhalb des bestimmten Zeitintervalls, so muss eine Wiederherstellung eingeleitet werden.

Zur Überwachung gibt es zwei Varianten:

1. Der überwachte Task übermittelt automatisch im bestimmten Intervall sein Status.
2. Der SYSTEM MONITOR muss den Status anfordern, falls vom zu überwachenden Task keine automatisierten Heartbeats zur Verfügung gestellt werden. Dies führt jedoch zu mehr Komplexität beim Monitor, um die Automation zu implementieren.

Der SYSTEM MONITOR muss eine Schnittstelle bereitstellen, mit der der zu überwachende Task interagieren kann. Mittels FAULT CORRELATION kann er feststellen, ob Faults im Kommunikationssystem oder im überwachten System bestehen. Heartbeats können mit weiteren Informationen angereichert werden, um die Korrektheit zu bestimmen.

Konsequenzen
 Es können mit dem Heartbeat präventiv fehlerhafte Systeme erkannt und eine Fehlerbehandlung eingeleitet werden, bevor das System effektiv benötigt wird. Der Intervall kann mit einem REALISTIC THRESHOLD eingegrenzt werden. Je nach der Last des überwachten Systems kann die Übermittlung verzögert werden, eine falsch ausgelöste Wiederherstellung kann die Datenverarbeitung einschränken. Die Heartbeats verursachen einen teils unnötigen Overhead, vor allem wenn viele Nachrichten übermittelt werden. In diesem Fall gibt der Fluss von ACKNOWLEDGEMENTS genügend Informationen. Bei der Implementation muss darauf geachtet werden, dass die Heartbeats keine Seiteneffekte besitzen. (z.B. Veränderung des Systemzustandes).

Schlussfolgerung
 Heartbeat eignet sich vor allem, wenn nur wenige Aktivitäten vorhanden sind, ansonsten ist das Pattern ACKNOWLEDGEMENTS zu bevorzugen.

Zusammenfassung
 Die Aktivitäten einer Komponente werden von ausserhalb überwacht.

Kontext 
 Im System soll ein SYSTEM MONITOR hinzugefügt werden. Die Ressourcen einer Komponente solle aber nicht zusätzlich belastet werden.

Problem
 In manchen Systemen kommt es oft vor, dass die effektive Last, die ursprünglich Geplante übertrifft. In diesem ist es nicht möglich, zusätzliche Meldungen zur Fehler Benachrichtigung zu generieren.

Lösung
 Man integriert die Möglichkeit, dass der Monitor die Aktivitäten des zu überwachenden Systems beobachten kann, ohne dabei in den Nachrichtenfluss einzugreifen. Er kann dabei eine Hardware- oder Softwarekomponente darstellen, abhängig von den Anforderungen, und überwacht somit die sichtbaren Effekte des überwachten Tasks. Dieser wird dabei nicht verändert. Er kann ähnlich wie der SYSTEM MONITOR Aktivitäten auslösen, wenn sich das System nicht verhält wie erwartet, jedoch mit dem Unterschied, dass der Watchdog nur ein Task überwacht. Typischerweise meldet sich der Watchdog beim SYSTEM MONITOR und dem FAULT OBSERVER, sobald ein Failure erkannt wurde. Es gibt mehrere Arten zur Überwachung eines Systems:

1. Ein- und Ausgabe überwachen, vergleichbar mit einem Proxy.
2. Setzen eines Timers vor einer kritischen Operation, anschliessender Vergleich, ob die Zeit eingehalten wurde.
3. Verwendung von Gucklöcher (engl. peepholes) oder Testpunkten (Hardware) um direkt in den Task zu schauen.

Vergleichbar mit dem Herdenhund, welcher ein ausgerissenes Schaf wieder zur Herde zurück bringt.

Konsequenzen
 Der Watchdog besitzt einen kleineren Overhead als ACKNOWLEDGEMENTS und HEARTBEAT, indem er direkt über Hard- oder Software in den Nachrichtenfluss eingreift. Man kann nur genau einen Task überwachen. Die Komplexität wird aber nur geringfügig erhöht.

Schlussfolgerung
 Der Watchdog ist einfacher und sparsamer, jedoch auch in seiner Fähigkeit eingeschränkt im Vergleich zu einem SYSTEM MONITOR. Oft wird der Watchdog auf eingebetteten Systemen eingesetzt, wo eine Überwachung aus der Ferne meist schwierig ist.