Detection Pattern

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.

Ausgangslage
 Das System soll darauf ausgelegt werden lange Zeit ohne Fehler zu laufen. Manche Errors resultieren aus Faults, die schwer zu detektieren sind. Die Faults können daran gehindert werden, aktiv zu werden, indem das System regelmässig gewartet wird.

Problem
 Fehler wie Memory Leaks können früh erkannt werden und noch bevor sie zu Errors oder Failures werden, behandelt werden. Im Fall des Memory Leaks kann mittels Garbage Collection verhindert werden, dass Speicher unnötig besetzt bleibt und dies zum Absturz des Systems führt. Bei Fehlerhaften Speicher stellen auf der Festplatte oder im Arbeitsspeicher kann mittels Correcting Audits (2) die Speicherstellen wieder korrigiert werden, bevor das System den Fehler mitkriegt.

Anwendung
 Routine Maintenance kann entweder durch die Komponente selbst oder durch ein Maintenance Interface (7) ausgelöst werden. Ausserdem sind Routine Exercises (23) gute Gelegenheiten um Routine Maintenance auszuführen.

Um die Routine Maintenance auszuführen können Prozesse mit niedriger Priorität genutzt werden. Diese können dann die Idle-Time des Prozessors brauchen. Der Prozess kann die Daten auf Korrektheit prüfen. Enthalten sie Fehler kann er sie korrigieren oder eine Fehlerbehandlung auslösen.

Ausgangslage
 Man entwickelt ein fehlertolerantes System, welches unbeschäftigte Komponenten hat, die darauf warten eine aktive Komponente im Fehlerfall zu ersetzen. Dies trifft auf Active-Standby und N + M Redundancy (3) zu.

Problem
 Bei einem Failover (32) auf eine Standby-Komponente, ist man sich nicht sicher ob dieser fehlerfrei abläuft und ob die Standby-Komponente tatsächlich den Betrieb übernehmen kann.

Anwendung
 Es sollten regelmässig Failover auf Ersatzkomponenten ausgeführt werden, um sicherzustellen, dass diese im Ernstfall funktionieren. Dabei sollte der Test am besten ausgeführt werden, wenn es wenig Aktivität auf dem System hat. Kommt es während des Betriebs der Ersatzkomponente zu einem Error kann wieder ein Failover auf die Produktivinstanz gemacht werden.

Ein Fehler während der Routine Exercise ist besser als ein Fehler während die Komponente wirklich gebraucht würde.