Detection Pattern

Errors (in Daten, Nachrichten etc) können sich schnell von einer Mitigation Unit auf eine andere ausbreiten. Aus diesem Grund sollte eine Unit of Mitigation isolieren und dadurch das überschwappen auf andere Teile im System mit einer Barriere verhindern.

Anschliessend kann die Fehlerbehandlung initiiert werden. Gegen Aussen soll das System eine Fail-Silent Meldung propagieren. Das System wird defakto in Quarantäne gesetzt.

Riding over Transients (dt. überspringen der Störsignale/flüchtige Erscheinungen)

Gewisse Fehler treten nur einmalig oder kurzfristig auf. Es soll verhindert werden, dass die Behandlung solcher Fehler das System unnötig belasten.

Das System sollte mittels Fault Correlation überwacht werden. Die Errors werden kategorisiert. Ist die Kategorie nicht als transient Errors definiert, dann sollte die Behandlung des Errors sofort beginnen. Ansonsten wird die Fehlerbehandlung nur eingeleitet, wenn der Fehler in der letzten Zeit häufig aufgetreten ist. Ansonsten wird der Fehler ignoriert (mit Ausnahme, dass der Counter erhöht wird). Für jede Fault Correlation kann ein maximales Aufkommen definiert werden, ab wann der Fehler behandelt wird.

Beispielsweise sollte ein einmaliger DB-Connection-Verlust keine Auswirkung haben. Schlagen jedoch mehrere Abfragen in kürzester Zeit fehl, sollte ggf. der Systemadministrator benachrichtigt werden. Würde der System-Administrator bereits nach der ersten fehlgeschlagenen Anfrage benachrichtigt, könnte dieser z.B. den DB-Server neustarten,
obwohl nur ein temporäres Problem bestand. Kurzfristige Fehler können zu unkorrekten Behandlungsmethoden führen und werden deshalb erst ab dem erreichen eines Threshold behandelt (Stichwort: LEAKY BUCKET COUNTER).

Wie kann erkannt werden, ob es sich um einen kurzlebigen (tranisent) oder einen wiederkehrenden (intermittent) Error handelt. Hierfür besitzt jede Unit of Mitigation ein Leaky Bucket Counter. Bei jedem auftretenden Error wird der Counter erhöht. In vorbestimmten Zeitperioden wird der Counter um jeweils eins reduziert, wobei der Wert nie unter 0 geht. Erreicht der Counter nun dennoch einen Threshold, dann handelt es sich um einen permantenten Fehler (wenn das hinzukommen von neuen Fehler schneller ist als das abfliessen, dann handelt es sich um einen permanenten Fehler). In jedem Fall sollte jedes einzelne Auftreten des Errors an den Fault Observer gemeldet werden.

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.

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.