VIATHINKSOFT STATUS MONITOR FRAMEWORK
MEMO #1 ÜBER DAS NEUDESIGN 2013

VERSION: 1

Nach etlichen Design-Konflikten und Fehlimplementierungen möchte ich das StatMon-Framework im Jahr 2013 komplett erneuern und verbindlich festlegen.

The Status Monitor Framework besteht aus einem Sender der StatusMonitor-Informationen nach einem festgelegten Format sendet, einem Empfänger, der die Informationen ausließt und zu gegebener Zeit Alarm schlägt. Es wurden bereits zahlreiche Status-Monitore in PHP geschrieben z.B. zur Überwachung von Festplattenfehlern, Versions-Updates, Warnsysteme für ungewöhnliche Aktivitäten (z.B. SSH-Anmeldung von einer fremden IP), Integrations-Checks (z.B. Prüfung ob ein Cronjob regelmäßig ausgeführt wurde) und viele weitere. Es gibt unzählige Szenarien in denen ein Statusmonitor nützlich ist. Durch Implementierung von Clienten in Java, Delphi oder PHP können eine große Anzahl von Monitoren überwacht werden und der User wird somit stets über aktuelle Warnungen informiert.

StatMon soll als RFC (Request for Comments) veröffentlicht und damit als Web-Standard vorgeschlagen werden. Da ein RFC nie wieder verändert werden kann, ist es von äußerster Dringlichkeit, dass das Design und die Grundsatzentscheidungen alle Szenarien und Probleme möglichst gut berücksichtigen. Außerdem ist es dringend notwendig, dass durch StatMon keine Spezifikationen anderer Standardisierungsorganisationen, z.B. W3C oder andere RFCs verletzt werden und auch die gängige Praxis nicht verfehlt werden.

DESIGN ENTSCHEIDUNG #1 : Namensgebung, Terminus

Definition: StatusMonitor Framework
        Definiert das Format spezifiziert als RFC, eine Sammlung aus Referenzimplementierungen für Clients und Monitore.

Definition: StatusMonitor (SM)
        Eine (X)HTML-Seite die einen oder mehrere Sub-StatusMonitore.

Definition: Sub-StatusMonitor (SSM)
        Eine Information in einer (X)HTML-Seite die eine Status-Information enthält, z.B. "Temperatur ist bei 70°C und die Standard-Warngrenze liegt bei 100°C"
        Ein StatusMonitor kann mehrere Sub-StatusMonitore enthalten. So ist es z.B. möglich, dass ein SM beispielweise Temperatur der Festplatte und Temperatur der CPU gesondert auflistet.
        Im Client wird dies als Baum dargestellt. Der StatusMonitor enthält dann z.B. 2 Substatusmonitore. Der SM ist "OK" wenn alle seine SSMs "OK" als Status besitzen.
        WICHTIG: Ein SSM speichert generell nie einen Zustand! Hat ein Monitor also die Funktion zu Warnen, sobald ein Wert steigt, dann muss dieser Zustand im SM-Client (Datenbank) gespeichert und verglichen werden. Der SSM gibt generell nur den aktuellen Zustand des Testsubjekts aus und nicht dessen verlauf. (Dadurch ist es auch möglich, dass verschiedene Beobachter (SM-Clients) zu verschiedenen Prognosen kommen).

Definition: SSM-Type
        Jeder Sub-Statusmonitor hat einen Typ, der die Funktion des SSM beschreibt.
        Typen werden in einem anderen Memo besprochen.
        Mögliche Typen sind z.B.
        CONSTANT: Warne, sobald ein Wert sich verändert
        SEVERITY: Warne, sobald ein Wert ansteigt (z.B. Fehl-Logins)
        RESOURCE: Warne, sobald ein Wert abfällt (z.B. freier Festplatten-Platz)
        VALUE: Warne sobald ein Wert eine obere oder untere Grenze verlässt (z.B. Temperatur, Kühlflüssigkeit)

Definition: SM-Sender
        Meist ein PHP Script das auf Serverseite den Zustand des Testsubjekts misst und anschließend einen oder mehrere SSMs ausgibt.

Definition: SM-Client
        Die Software auf dem Computer des Endnutzers bzw eine Software die SMs überwacht und die SSMs auswertet und den Nutzer warnt sobald eine SM-Type-Extension den Status eines SSM als kritisch einstuft oder es zu anderen Problemen kommt (z.B. Monitor nicht erreichbar aber Ping zu Google Funktioniert).
        Der SM-Client verfügt über eine Datenbank, um den Zustand der SSMs zu speichern.
        Überwacht ein Client z.B. einen SSM mit dem Typ SEVERITY, so speichert die Type-Extension für "SEVERITY" den Value des letzten Aufrufs in der Datenbank und vergleicht ihn mit dem aktuellen Value. Somit kann gewarnt werden, sobald ein Wert ansteigt.

Definition: Zustand / Client-DB
        Bei einem "SM-Sender" ist das Wort "Zustand" definiert als der Zustand des Testsubjekts, z.B. bei der Überprüfung des freien Festplatten-Speicherplatz ist "Zustand" definiert als der freie Festplattenplatz.
        Bei einem "SM-Client" ist das Wort "Zustand" definiert als die Information in der SM-Client-Datenbank die beschreibt, welche Werte die SMs/SSMs zuletzt hatten. Aus diesem Zustand heraus kann berechnet werden ob ein Wert z.B. gestiegen oder gefallen ist.

Definition: Status
        Als "Status" wird das Resultat bezeichnet, das der SM-Client an den Nutzer weitergibt. Der Status ist abhängig vom Zustand des SSMs in der Client-DB.
        Beispiel:
        SM-Client #1 hat in seiner Client-DB die Information dass der freie Speicherplatz bei 100 MB lag. Der SSM meldet in seiner aktuellen Prüfung dass nur noch 90 MB frei sind. Dieser Cleint wird seinen Status in WARNING ändern.
        SM-Client #1 hat bereits eine Warnung ausgegeben und der User hat die Grenze heruntergesetzt. Somit ist in seiner Client-DB der Wert 90 gespeichert und somit wird das Ergebnis 90 des SSMs bei diesem Clienten den Status nicht in Warning abändern.

Definition: Local ID
        Jeder SSM muss eine LocalID (locid) besitzen, die innerhalb des SM einzigartig ist. Grund hierfür ist, dass der SSM für die Client-Datenbank eindeutig identifiziert.
        Unter dem Index <SM URL, locID, SMType OID> kann somit eine SM-Type-Extension den Zustand eines SSM speichern und wieder auslesen.
        Vorteil gegenüber Indexes (SSM #1, SSM #2, SSM #3...) ist, dass somit SSMs entfernt werden können, ohne dass dies die Zustände der restlichen Monitore zerstört.
        Es ist des Weiteren möglich das für ein SSM mehrere SM-Type-Zustände gespeichert werden. z.B. wenn ein SSM zuerst den Type CONSTANT hielt, dann SEVERITY und dann wieder CONSTANT. Der Zustand von CONSTANT ist dann erhalten geblieben.

Definition: SM-Type-Extension
        Eine Erweiterung (OOP) mit der der SM-Client lernt, einen bestimmten SM-Type zu bewerten und ggf Zustandsinformationen in die SM-Client-Datenbank zu speichern/auszulesen.

Definition: Truti
        siehe "Truthahn".



DESIGN ENTSCHEIDUNG #2 : (X)HTML-Integration

Zielstellung:
Es sollen beliebig viele Statusmonitor-Informationen in eine HTML- oder XHTML-Seite gepackt werden. Die Informationen sollen für den normalen User unsichtbar sein und nur durch einen StatusMonitor-Parser verarbeitbar. Das Integrieren einer StatMon-Information durch PHP soll so einfach wie möglich sein.

Die Fragestellung lautet, wie man diesen Monitor in die (X)HTML-Seiten implementieren kann.

Beispiel für einen StatusMonitor:
Der Statusmonitor "Temperatur" warnt, sobald das Subjekt eine Temperatur von 100 °C überschreitet. Die Temperatur ist derzeit 70 °C.
Syntax:
STATMON <version> <local id> <description> <comparison type> <type specific arguments> <unit>
STATMON v1 main "Temperatur" SEVERITY 70 100 "°C"

Möglichkeiten:

(1) Einfügen als HTML-Kommentar

Beispiel:
<!-- STATMON v1 main "Temperatur" SEVERITY 70 100 "°C" -->

Vorteile
- Sehr einfache Implementierung eines StatusMonitors z.B. in PHP. Es muss lediglich die Information per "print" ausgegeben werden. Es spielt keine Rolle, an welcher Stelle im (X)HTML-Dokument der Kommentar ausgegeben wird.
- Sehr einfache Implementierung eines Clients. Es muss lediglich /<!-- (.+) -->/ per RegExp geparsed werden

Nachteile
- Die Spezifikation für XML-Parser geben vor, dass Kommentare vom Parser ignoriert werden dürfen. Daher ist es möglich, dass manche Parser die StatusMonitor-Information unmöglich parsen können.
- Der Statusmonitor kann nicht mittels DOM-Tree geparsed werden (wäre Vorteilhaft für manche API-Frameworks, z.B. für Firefox-Plugins)
- Es ist eine zusätzliche Spezifikation notwendig, wie mit Sonderzeichen umgegangen werden muss. HTML-Spezifische Merkmale wie z.B. das Escaping mittels &quot; ist nicht möglich innerhalb von Kommentaren.
- Das Escaping (Verboten: ", <, >, &, ') muss definiert werden. Der Rest könnte als utf8 definiert werden.

Fragen:
- Ist ein CDATA-Kommentar bei XHTML notwendig?

(2) Einfügen als Meta-Tag

Beispiel:
<meta name="StatMon" value="STATMON v1 main 'Temperatur' SEVERITY 70 100 '°C'" />

Vorteile:
- Garantiert unsichtbar für den User
- Das <meta> Element ist perfekt geeignet, um Metainformationen wie StatMon weiterzuleiten.
- Die Fragestellung, welcher Zeichensatz verwendet wird, wird durch (X)HTML gelöst, da (X)HTML entscheidet, welcher Zeichensatz verwendet wird (UTF8 oder ISO-8859-x?) und Entities (&quot;) statt manueller Escape-Sequenzen möglich sind.
- 100% RFC und W3C Konform.

Nachteile:
- Ein (X)HTML-Parser ist für den Clienten notwendig.
- Damit die (X)HTML-Ausgabe W3C-Konform bleibt, MUSS der Sender die <meta> Elemente im <head> Teil senden. Dies ist nicht in allen Szenarien möglich und erschwert die Implementierung eines Senders. Es besteht also das Problem, dass die StatMon-Information ganz am Anfang generiert werden muss bzw. der restliche Content mittels ob_start() gecached werden muss, was nicht in allen Szenarien möglich ist!
- Das Escaping (Verboten: ", <, >, &, ') muss definiert werden. Der Rest könnte als utf8 definiert werden.
  Hier im Beispiel mit Single-Quots anstelle Double-Quots.

Fragen:
- Ist es möglich, mehrere Meta-Tags mit dem selben Namen zu erstellen? z.B.
  <meta name="StatMon" value="STATMON v1 main 'Temperatur Festplatte' SEVERITY 70 100 '°C'" />
  <meta name="StatMon" value="STATMON v1 main 'Temperatur CPU' SEVERITY 1200 100 '°C'" />

(3) Einfügen als HTTP-Response-Header

Beispiel:
X-STATMON: STATMON v1 main "Temperatur" SEVERITY 70 100 "°C"

Vorteile:
- Garantiert unsichtbar für den User
- Einfach zu implementieren für Clienten

Nachteile:
- PHP Scripte können nicht so einfach den Response-Header senden, wenn das Script bereits Content ausgeliefert hat. Dies ist z.B. der Fall wenn ein Script innerhalb eines CMS eine StatMon-Information senden will. Es besteht also das Problem, dass die StatMon-Information ganz am Anfang generiert werden muss bzw. der restliche Content mittels ob_start() gecached werden muss, was nicht in allen Szenarien möglich ist!
- 100% RFC und W3C Konform.

(4) Einfügen als alternatives HTML-Element

Beispiel:
<viathinksoft:statmon version="1" locid="main" name="Temperatur" type="Severity" value="70" critical="100" unit="°C" />

(Anmerkung: Facebook verwendet auch eigene XHTML-Elemente ("FBML"), allerdings scheint das nicht W3C-Konform zu sein)

Vorteile:
- Die Fragestellung, welcher Zeichensatz verwendet wird, wird durch HTML gelöst, da HTML entscheidet, welcher Zeichensatz verwendet wird (UTF8 oder ISO-...?) und Entities (&quot;) statt manueller Escape-Sequenzen möglich sind.
- Es ist möglich, die Reihenfolge der Argumente zu verändern und sogar zu erweitern. So kann z.B. in einer späteren StatMon-Spezifikation ein weiteres Argument hinzukommen, ohne dass die existierenden Parser dadurch in ihrer Funktion gestört werden.
- Einfacher zu lesen, da jedes Argument einen menschenlesbaren Namen (z.B. name, type, value) besitzt.

Nachteile:
- Ein (X)HTML Parser ist für den Clienten notwendig.
- Für HTML-Dokumente: Nicht W3C valid und es kann kein namespace hinzugefügt werden.
- Für XHTML-Dokumente: <viathinksoft:statmon> ist kein gültiger XHTML-Tag und der W3C-Validator/Browser kennt das ViaThinkSoft-DTD nicht. Trotzdem ist der XML Namespace valid.
- Verstößt möglicherweise gegen die W3C-Richtlinien da es dann kein gültiges HTML oder XHTML mehr ist. Dies erschwert/verhindert eine Vorstellung als RFC Standard.

Frage:
- Ist es irgendwie möglich, das zusätzliche Attribut per DTD zu spezifizieren, sodass das Ausgabedokument inklusive <viathinksoft:statmon> Tag 100% W3C-Valid ist (für beide Varianten, HTML und XHTML)?

Weitere Problematik:
- Beliebige Attribute können nicht angegeben werden, da DTD starr ist, die Types aber verschiedene Argumente brauchen.
  so benötigt z.B. type=Value die attribute min,max,value, während type=constant nur die attribute value braucht.
- Lösung: Jeder Typ bekommt 1 Element:
  <vstatmoncollection:value min= max= value=>
  <vstatmoncollection:constant value="">
  ...
- vstatmoncollection bekäme dann ein eigenes DTD.
- Weiteres PROBLEM: man kann nicht alle statmons z.b. unbekannte finden! dies war bei <!-- STATMON ... --> möglich, auch unbekannte statmons zu finden.
- Man bräuchte ein Universalelement attribs="param1,param2,param3" was wieder Probleme mit Escaping bietet und unsauber wirkt, denn die args sind dann nicht mit html-attribs angegeben werden, sondern nur comma-separated
- Geht nicht mit HTML5, nur mit XHTML 5.

(5) Einfügen als bekanntes HTML-Element

Es wurde auch die Möglichkeit untersucht, ob ein StatMon auch als ein bekanntes HTML-Element integriert werden kann, sodass man keine W3C-Richtlinien verletzen muss. Ich habe keine HTML-Tags gefunden, die diese Eigenschaft erfüllen. Microsoft verwendete in "Windows ME" <object> Tags zum darstellen von Windows-Extensions:
<object clsid="..........." ...>

Vorteile:
- Mittels clsid="" wäre es möglch, ein unsichtbares <object> zu erzeugen, das die StatMon-Informationen enthält.

Nachteile:
- <object clsid=""> ist eine inoffizielle Erweiterung von Microsoft und kein gültiges HTML oder XHTML. Der <object> Tag ist nicht für unsichtbare Informationen vorgesehen.

(6) Ausgabe über ein gesondertes Protokoll/Format

Es wird NICHT in Erwägung gezogen, die StatMon-Information über ein gesondertes Protokoll oder Format auszugeben. HTML bzw. XHTML soll als Container für eine StatMon-Information dienen!


DESIGN ENTSCHEIDUNG #3 : OOP-Design, SWING Implementierungsproblem

(ToDo)


DESIGN ENTSCHEIDUNG #4 : Sonstige Ideen

1) Sollte das Design empfehlen, dass ein Monitor verschieden stark gewichtete Warnungen ausgibt? z.B. Festplattenplatz gering = Popup-Warnung, aber Festplattenschaden = Popup, Audiosignal, SMS und E-Mail an alle Beteiligten?

(ToDo)