ViaThinkSoft - intelligent software for everyone            D. Marschall
Internet-Draft                                              ViaThinkSoft
Intended status: DRAFT



                                                          March, 26 2011


                      ViaThinkSoft StatusMon


Abstract

        ...

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Copyright Notice

   Copyright (C) ViaThinkSoft (2011).  All Rights Reserved.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.   Editorial Policy . . . . . . . . . . . . . . . . . . . . . . 3
   3.   Format Rules . . . . . . . . . . . . . . . . . . . . . . . . 4
   3a.   ASCII Format Rules  . . . . . . . . . . . . . . . . . . . . 5
   3b.   PostScript Format Rules . . . . . . . . . . . . . . . . . . 6





















Marschall                    Informational                      [Page 1]

Internet-Draft    ViaThinkSoft StatusMon Specification        March 2011

Übersicht

   Allgemeines
        Was ist das?
        Beispiele
   StatusMon Spezifikation 1.0
        Implementierung
        Parsing
   StatusMon Spezifikation 2.0
        Implementierung
        Parsing
   Kommandos
   Verteilerliste

1. Content

   This document includes:

   1. Introduction and definition of a Status Monitor
   2. Specification of the Status Monitor Interface 1.0
   3. Specification of the Status Monitor Interface 2.0
   4. Possible features for a Status Monitor Interface 3.0
   5. Specification of Status Monitor Distribution List 1.0
   6. Recommended implementation details for a Status Monitor Client
   7. Examples

1.  Introduction and definition of a Status Monitor

1.1.  What is a status monitor?

   A status monitor is a simple website which contains hidden
   information about a status of a service. The hidden information is
   called "status string". The purpose of a status monitor is to
   indicate wheter the service is OK or needs attention. The website
   itself can be used to show verbose information about the status
   visible through a web browser. A status monitor client checks this
   status monitor website and interprets the hidden status information
   to perform a check of the service. If the status monitor indicated a
   warning, the user is notified immediately.

1.2.  Including of the status string

   The Status monitor interface is the hidden implementation of a status
   string inside a (X)HTML page over a simple GET request at the HTTP
   protocol.

   At least one of the followings methods has to be inside the (X)HTML
   response to let the page be a Status Monitor:
   - (X)HTML metatag (http-equiv) and/or
   - (X)HTML comment and/or
   - HTTP response header entry

Marschall                    Informational                      [Page 2]

Internet-Draft    ViaThinkSoft StatusMon Specification        March 2011
   The advantages of the "hidden" status string are:
   - It is easy to implement
   - The status monitor and the page with verbose information can use
   the same url
   - The status monitor can be implemented in a public website
   containing information for everybody

1.3.  Allgemein

   Bei jedem Statusmonitor wird empfohlen, auch eine Ausgabe für
   Webbrowser zu erzeugen, die ausführliche Informationen über den
   Status enthält.

   Der Benutzer kann jederzeit den Status eines Monitors durch Klicken
   der URL detailiert betrachten. Liegt eine Warnung vor, wird der
   Benutzer sogar aufgefordert, die URL zu öffnen, um den Grund des
   Fehlers zu sehen.

   Der Überprüfungsalgorithmus als auch der Benutzer teilen sich also
   den Inhalt der Monitor-Seite.

1.4.  Status Monitor Client

   The status monitor Client is a software or a service which checks a
   status monitor regulary in a defined time interval and notifies
   the user as soon as the status monitor indicates that attention is
   neccessary.


























Marschall                    Informational                      [Page 3]

Internet-Draft    ViaThinkSoft StatusMon Specification        March 2011

2. Assigned object IDs

   Since interface 2.0 every status type can also be represented by an
   numeric OID. Every state is inside the id-states arc.

   -- StatusMon Specification Identifier Registry
   id-viathinksoft OBJECT IDENTIFIER ::= { iso(1)
      identified-organizatin(3) dod(6) internet(1) private(4)
      enterprise(1) 37476 }

   id-statusmon-v1 OBJECT IDENTIFIER ::= { id-viathinksoft products(2)
   statusmon(1) 1 }

   -- STATES Arc
   id-states  OBJECT IDENTIFIER ::= { id-statusmon-v1 1 }

   -- STATES
   id-state-ok               OBJECT IDENTIFIER ::= { id-states    1 }
   id-state-warning          OBJECT IDENTIFIER ::= { id-states    2 }
   id-state-severity         OBJECT IDENTIFIER ::= { id-states    3 }
   id-state-constant         OBJECT IDENTIFIER ::= { id-states    4 }
   id-state-picutre          OBJECT IDENTIFIER ::= { id-states    5 }
   id-state-message          OBJECT IDENTIFIER ::= { id-states    6 }
   id-state-error-internal   OBJECT IDENTIFIER ::= { id-states  100 }
   id-state-error-arguments  OBJECT IDENTIFIER ::= { id-states  101 }

Anforderungen an die Statusmonitor-Software

   * Es sollen Optionen angeboten werden:
     - Warnen bei Ping-Ausfall Ja, Nein
     - Warnen bei SEVERITY Änderung, <, >, =
     - ...




















Marschall                    Informational                      [Page 4]

Internet-Draft    ViaThinkSoft StatusMon Specification        March 2011

1. Unterschiede Version 1 und 2

   +-------------------------------+-----------------+-----------------+
   |                               | Version 1       | Version 2       |
   +-------------------------------+-----------------+-----------------+
   | Accepted status types                                             |
   +-------------------------------+-----------------+-----------------+
   | Status "OK"                   | Yes             | Yes             |
   | Status "WARNING"              | Yes             | Yes             |
   | Status "SEVERITY"             | No              | Yes             |
   | Status "CONSTANT"             | No              | Yes             |
   | Status "PICTURE"              | No              | Yes, but client |
   |                               |                 | implemention    |
   |                               |                 | is optional!    |
   | Status "MESSAGE"              | No              | Yes             |
   | Usage of OID identifiers      | No              | Yes, but only   |
   |                               |                 | numeric OIDs!   |
   | Case-Sensitive                | Yes             | Yes             |
   +-------------------------------+-----------------+-----------------+
   | Accepted including methods                                        |
   +-------------------------------+-----------------+-----------------+
   | Status as HTML comment        | Required        | Yes             |
   | Status as X-Status-Header     | Optional        | Yes             |
   | Status as http-equiv Metatag  | No              | Yes             |
   | Status as normal meta tag     | No              | No              |
   | XHTML-Support                 | Not neccessary  | Yes             |
   +-------------------------------+-----------------+-----------------+
   | Compatibility                                                     |
   +-------------------------------+-----------------+-----------------+
   | HTTPS support                 | No              | No              |
   | Cookies                       | No              | No              |
   | Password authentification     | No              | No              |
   +-------------------------------+-----------------+-----------------+
   | Other features                                                    |
   +-------------------------------+-----------------+-----------------+
   | Monitor distribution list     | No              | Separate URL    |
   | 1 URL, multiple monitors      | No              | No              |
   +-------------------------------+-----------------+-----------------+


As you can see, there are following limitations:
- https
- cookies
- password
- multiple monitors


   Redirects        Ja                Ja
   CaseInsenitive        Ja?                Ja

   v2 ist vollständig Abwärtskompatibel zu v1 Monitoren.

Marschall                    Informational                      [Page 5]

Internet-Draft    ViaThinkSoft StatusMon Specification        March 2011
1. Implementation in a Status Monitor v1

   In the Status Monitor Interface v1 there are 2 possible
   implementation methods available.

   a) (X)HTML comment (REQUIRED)

   <!-- STATUS: <status string> -->

   b) HTTP Response Header entry (OPTIONAL)

   X-Status: <status string>

   Following rules does exist:
   - The (X)HTML comment is NECCESSARY. Without this comment, the
   (X)HTML page is not a valid Status Monitor 1.0
   - The HTTP Response Header entry is OPTIONAL and is rarely used for
   checking.
   - The behavior of 2 same and equal comments is not defined (?)

2. Implementation in a Status Monitor v2

   In the Status Monitor Interface v2 there are 3 possible
   implementation methods available:

   a) (X)HTML comment

   <!-- STATUS: <status string> -->

   b) HTTP Response Header entry

   X-Status: <status string>

   c) (X)HTML http-equiv meta tag.

   <meta http-equiv="X-Status" content="<status string>" />

   Please note that here every valid (X)HTML notation is correct.
   For example
   - If the page is using e.g. HTML 4.01, then uppercase meta tags are
   allowed.
   - Spaces or linebreaks are allowed inside the tag (but not inside the
   <status string>).
   - http-equiv and content can change places.

   For this reason it is highly recommend to use a (X)HTML parser to
   gather this information.

2.1 Rules

   Following rules does exist:
   - At least ONE implementation must be existing.
   - MULTIPLE implementations (also of the same kind) may be used, but
Marschall                    Informational                      [Page 6]

Internet-Draft    ViaThinkSoft StatusMon Specification        March 2011
   then they need exactly the same <status string>.

Status String

   <status string> ::= <status type> | <status type> ' ' <params>

   in v2:
   <status type> ::= <uppercasestring> | <numericoid>

   in v1:
   <command> ::= <uppercasestring>

   <params> ::= ...

   <uppercaseletter> ::= 'A' | 'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H' |
   'I' | 'J' | 'K' | 'L' | 'M' | 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' |
   'T' | 'U' | 'V' | 'W' | 'X' | 'Y' | 'Z'.

   <uppercasestring> ::= <uppercaseletter> | <uppercaseletter>
   <uppercasestring>

   Note:
   <numericoid> is according to [RFC-1778], page 4 defined as:
   <numericoid> ::= <numericstring> | <numericstring> '.' <numericoid>

   Warning: Other representations of an OID (e.g. OID-IRI notation,
   ASN.1 notation or usage of descriptions) are NOT allowed as it
   makes the OID-identifier itself not unique and comparable.

Verfügbare Stati

1. Status "OK" (1.3.6.1.4.1.37476.2.1.1.1.1)

   USAGE:
      <status string> ::= ('OK' | id-state-ok)

   Warning: If you are using the OID notation instead of the
   state-identifier, your Status Monitor will not be compatible with
   version 1.0!

2. Status "WARNING" (1.3.6.1.4.1.37476.2.1.1.1.2)

   USAGE:
      <status string> ::= ('WARNING' | id-state-warning)

   Neu in Version 2 ist sowohl das die Parsing-Methode als auch Metatags
   und neue Status-Methoden.

   Es gibt nun 2 Zustandsspeichernde Befehle "SEVERITY" und "CONSTANT"
   sowie einen grafischen Status "PICTURE", der nicht 
   durch die Überwachungssoftware ausgewertet wird sondern menschliche
   Überwachung benötigt.

Marschall                    Informational                      [Page 7]

Internet-Draft    ViaThinkSoft StatusMon Specification        March 2011
   Warning: If you are using the OID notation instead of the
   state-identifier, your Status Monitor will not be compatible with
   version 1.0!

3. Status "SEVERITY" (1.3.6.1.4.1.37476.2.1.1.1.3)

   USAGE:
      <status string> ::= ('SEVERITY' | id-state-severity) <int> [' '
      <text>]

   <int> ist eine Zahl, die die "schwere" einer Warnung angibt. "0" ist
   dabei der Zustand "OK" und >0 "WARNING".

   Die Client-Software muss den Zustand <int> dauerhaft speichern (ggf.
   auch über das Herunterfahrens des Systems).

   Sinn des Status "SEVERITY" ist, dass der Benutzer nur gewarnt wird,
   wenn die Schwere der Warnung steigt, nicht aber wenn sie gleich
   bleibt oder abfällt. Daher muss der Wert dem Monitor gespeichert
   werden.

   Anmerkung: Die Zahl <int> ist Monitorspezifisch und kann nicht mit
   anderen Monitoren verglichen werden.

   Implementierung: Für die Implementierung wird ein signed int32
   empfohlen. Allerdings sollten negative Werte nicht angeommen
   werden!

   Hinweis: <int> kann insbesondere für einen Unixtimestamp verwendet
   werden. Der Monitor könnte dann den Unixtimestamp eines gewissen
   aktuellen Ereignisses wiedergeben und der Benutzer wird gewarnt,
   sobald dieses Ereignis erneut aufgetreten ist.

   <text> ist optional und ist ein beliebiger Text, der den Status
   spezifiziert und in der Client-Software angezeigt werden kann. Es
   wird empfohlen bei fehlenden Text die Client-Software "Severity
   <int>" anzeigen zu lassen sowie bei vorhandenen Text "(<int>)
   <text>".

   3.1 Argument 1: <int>

   It is recommended to use a signed int32 for implementation, as it is
   the usual integer datatype in different programming languages and
   architectures.

   Values smaller than 0 are NOT allowed in the status monitor
   interface.

   Therefore, the range of this argument is from 0 to 2.147.483.647
   (2^31 - 1).

   3.2 Example

Marschall                    Informational                      [Page 8]

Internet-Draft    ViaThinkSoft StatusMon Specification        March 2011
   HDD
   Unix timestamp (besser als constant?)

4. Status "CONSTANT" (1.3.6.1.4.1.37476.2.1.1.1.4)

   USAGE:
      <status string> ::= ('CONSTANT' | id-state-constant) <text>

   Nicht erlaubt: New lines ?

5. Status "PICTURE" (1.3.6.1.4.1.37476.2.5.1.1.5)

   USAGE:
      <status string> ::= ('PICTURE' | id-state-picture) <url> [' '
      <text>]

   Url kann absolut oder relativ sein

        Unterstützt die Software die Darstellung
        von Bildern nicht, so darf keine Warnung ausgegeben werden.
        Als angemessene Reaktion wird empfohlen, die Ausgabe
        mit "SEVERITY 0 (Picture)" gleichzusetzen.

6. Status "MESSAGE" (1.3.6.1.4.1.37476.2.1.1.1.6)

   USAGE:
      <status string> ::= ('MESSAGE' | id-state-message) <text>

6. ERROR_ARGUMENT

   This error indicates that the client has provided illegal argumetns
   (= GET parameters) to the Status Monitor. The user must correct
   this.

   The optional first parameter (text) may describe how to use the
   Status Monitor.

7. ERROR_INTERNAL [text (optional)]

   An temporary internal error prevents the Status Monitor to provide
   the current state of the service. This error is equivalent to a
   HTTP 500 response.

   The optional first parameter (text) may describe what happened and
   when the service will be available again, maybe also debug
   details.

8. Examples

  <!-- STATUS: OK -->

  <!-- STATUS: WARNING -->

Marschall                    Informational                      [Page 9]

Internet-Draft    ViaThinkSoft StatusMon Specification        March 2011
  <!-- STATUS: 1.3.6.1.4.1.37476.2.1.1.1.2 -->

  <!-- STATUS: SEVERITY 0 -->

  <!-- STATUS: SEVERITY 2 -->

  <!-- STATUS: SEVERITY 10 It's burning!!! -->

  <!-- STATUS: 1.3.6.1.4.1.37476.2.1.1.1.3 10 It's still burning -->

  <!-- STATUS: CONSTANT hello world -->

  <!-- STATUS: PICTURE webcam.jpg -->

  <!-- STATUS: PICTURE http://www.example.com/webcam.jpg -->

  <!-- STATUS: PICTURE http://www.example.com/webcam.jpg Webcam of
  Daniel Marschall -->

  <!-- STATUS: MESSAGE Note that this monitor service is only available
  until December, 24th! -->

todo: andere examples z.b. als meta tags






























Marschall                    Informational                     [Page 10]

Internet-Draft    ViaThinkSoft StatusMon Specification        March 2011

8. Concept


                                                           Run every
                                                           interval
                                                           +--(1)--+
                                                           |       |
                                                           |       v
+-------------+   Request   +-------------+   Request   +--+----------+
| Datasource, | <===(3)===  | Status      | <===(2)===  | Status      |
| service,    |             | Monitor     |             | Monitor     |
| etc.        |  ===(4)===> | (Interface) |  ===(6)===> | Client      |
+-------------+    Data /   +--+----------+   STATE     +-------------+
                 Condition     |       ^                   ^       |
                               |       |                   |       |
                               +--(5)--+                   |       |
                               Interpret                   |      (8)
                           data / condition                |       |
                                                           |       |
                     +-----------------(7)-----------------+       |
                     |       check / compare / update              |
                     |                                             |
                     v                        +--------------------+
          +----------------------------+      |
          | CLIENT  MONITOR  DATA      |      |  NOTIFICATION
          | (Client specific           |      |  (if neccessary)
          | storage of data)           |      |
          +----------------------------+      |       +----------------+
          | CLIENT MONITOR STATUS: ... |      +------>| Local user     |
          | Last checked: ...          |      |       +----------------+
          | Last severity: ...         |      |
          | Last constant: ...         |      |  respectively:
          | Last text: ...             |      |
          | Last notification: ...     |      |       +----------------+
          | Cached picture: ...        |      |       | Notify via     |
          |                            |      +------>| E-Mail, SMS,   |
          | etc.                       |              | Pager etc.     |
          +----------------------------+              +----------------+

(1) The Status Monitor Client runs a monitor check every interval. This
interval can be defined for each status monitor the client manages. The
status monitor distribution list defines also the recommended checking
interval for each status monitor.

(2) The status monitor client sends a simple GET HTTP request to the
status monitor.

(3) (4) The status monitor (programmed e.g. in PHP) checks the condition
of a service, e.g. checking how much space is left on the server hard
disk etc.

(5) The information provided from the data source or the service is
Marschall                    Informational                     [Page 11]

Internet-Draft    ViaThinkSoft StatusMon Specification        March 2011
interpreted by the status monitor. Here, a configuration file could
decide if the status is critical or not. Example: Configuration file
defines 10% HDD capacity left as critical. If the space left is 6%
(resp. hard disk is 94% full), the status monitor replies a warning
(e.g. "WARNING" or "SEVERITY 94"), otherwise it replies that everything
is OK (e.g. "OK" or "SEVERITY 0").

(6) This status is sent to the status monitor client.

(7) The status monitor client interprets the status and decides wheter
the user is notificated. Herefore, the cached client monitor data is
checked and compared. Even if the status is critical, there might be
cases where the user is not notified. For example, if the last hard disk
state was "96% full" (SEVERITY 96) and the current check indicated that
the hard disk is now only 94% full (SEVERITY 94), then the state is
still critical, but no new warning notification is neccessary.

(8) If the status monitor client decided, that the user has to be
notificated, then it shows a notification dialog, and/or an email, SMS,
pager message etc. is sent. Please note, that the status monitor client
could also be stored on a server, which has the purpose to notifiy via
email.































Marschall                    Informational                     [Page 12]

Internet-Draft    ViaThinkSoft StatusMon Specification        March 2011


   TODO: definieren "client monitor state" + alle commandos und ihre
   auswirkungen beschreiben, diagramm auch in worten beschreiben

   Warning: "Monitor State" and "Client Monitor State" are not the same!

   The "Client Monitor State" is a specific field in the Client Monitor
   Data which defines the general current state of the monitor. There
   can be following client states:
   - OK
   - Warning: <reason>
   - Error: <reason>
   - Internet connection down
   - (client specific)

   in this example the Client Monitor State is written as "Status:".

   Note: The client is not enforced to use Client Monitor Data. In this
   case, only Version 1.0 is possible since 2.0 requires
   zustandsspeicherende states. Also, if the client monitor state is not
   cached, then the monitor would warn every interval and not only once.

   Example:

   1. Date/Time: 03/04/2011 1:20 PM
      --> State="OK"
      --> Client Monitor Data=
            * Last Check: 03/04/2011 1:20 PM
            * Status: OK
      --> Notification=None

   2. Date/Time: 03/04/2011 2:20 PM
      --> State="PICTURE webcam.jpg"
      --> Client Monitor Data=
            * Last Check: 03/04/2011 2:20 PM;
            * Status: "Error: PICTURE not implemented!"
      --> Notifcation="Error, PICTURE not implemented"

   3. Date/Time: 03/04/2011 3:20 PM
      --> State="SEVERITY 2"
      --> Client Monitor Data=
            * Last Check: 03/04/2011 3:20 PM;
            * Status: "Warning: Severity=2"
            * Severity: 2;
      --> Notification="Warning! Severity is 2!"

   4. Date/Time: 03/04/2011 4:20 PM
      --> State="SEVERITY 2"
      --> Client Monitor Data=
            * Last Check: 03/04/2011 4:20 PM;
            * Status: "Warning: Severity 2";
            * Severity: 2;
Marschall                    Informational                     [Page 13]

Internet-Draft    ViaThinkSoft StatusMon Specification        March 2011
      --> Notification=None (since severity did not increase)

   5. Date/Time: 03/04/2011 5:20 PM
      --> State="SEVERITY 1"
      --> Client Monitor Data=
            * Last Check: 03/04/2011 5:20 PM;
            * Status: "Warning: Severity 1";
            * Severity: 1;
      --> Notification=None (since severity did not increase)

   6. Date/Time: 03/04/2011 6:20 PM
      --> State="CONSTANT foobar"
      --> Client Monitor Data=
            * Last Check: 03/04/2011 6:20 PM;
            * Status: "OK";
            * Severity: 1;
            * Constant="foobar"
      --> Notification=None

   7. Date/Time: 03/04/2011 7:20 PM
      --> State="CONSTANT barfoo"
      --> Client Monitor Data=
            * Last Check: 03/04/2011 7:20 PM;
            * Status: "OK",
            * Severity: 1;
            * Constant: "barfoo"
      --> Notification=Warning! Constant has changed from foobar to
      barfoo!

   8. Date/Time: 03/04/2011 8:20 PM
      --> State="CONSTANT barfoo"
      --> Client Monitor Data=
            * Last Check: 03/04/2011 8:20 PM;
            * Status: "OK",
            * Severity: 1;
            * Constant: "barfoo"
      --> Notification=None

   9. Date/Time: 03/04/2011 9:20 PM
      --> State="MESSAGE test message"
      --> Client Monitor Data=
            * Last Check: 03/04/2011 9:20 PM;
            * Status: "OK";
            * Severity: 1;
            * Constant: "barfoo"
      --> Notification="Notification from Status Monitor: test message"

   Client Monitor State as well as Notification is dependent of the
   Client.




Marschall                    Informational                     [Page 14]

Internet-Draft    ViaThinkSoft StatusMon Specification        March 2011

Parsen eines Monitors v1.

   (TODO)

Parsen eines Monitors v2.

   Es wird folgendes Verhalten empfohlen:

   - Als nächstes werden folgende Informationen gesammelt:
     a) X-Status Response Header (sofern vorhanden)
        X-Status: <status string>
        Groß- und Kleinschreibung MUSS beachtet werden1
     b) ALLE vorhandenen STATUS-Kommentare (sofern vorhanden)
        <!-- STATUS: <status string> -->
        Groß- und Kleinschreibung MUSS beachtet werden!
     c) ALLE vorhandenen Status-Metatags (sofern vorhanden)
        <meta name="status" content="<status string>" />
        Es wird ausdrücklich empfohlen, einen HTML-Parser zu verwenden.
        Ansonsten muss beachtet werden:
        - Groß- und Kleinschreibung kann bei HTML abweichen
        - name und content können vertauscht sein
        - Leerzeichen, Newlines und Tabs können auftreten
        - Es kann mit ">" oder "/ >" abgeschlossen werden (HTML/XHTML)
        - etc.
     Diese Werte können in einen dynamischen Array abgelegt werden.
   - Es wird geprüft, ob der Array mindestens 1 Element hat.
     Ansonsten: => KEIN MONITOR GEFUNDEN
   - Es wird geprüft, ob ALLE Elemente dieses Arrays
     EXAKT gleich sind.
     Ansonsten: => PARSING-ERROR
     Anmerkung: Dies bedeutet, dass auch das mehrmalige Vorkommen
     eines STATUS-Kommentars mit selben Inhalt in Ordnung ist und
     nicht zu einem Parsing-Error führt.
   - Der Array kann nun verworfen werden und der Status-String
     wird nun genauer betrachtet.

   Parsing des Status-Strings:

   <status string> ::= <command> [" " <content>]

   - <status string> wird bis zum ersten Leerzeichen oder dem Stringende
   ausgelesen.
     Die Zeichenkette vor dem ersten Leerzeichen ist das Kommando
     <command>.
     Alles nach diesem Leerzeichen sind die Inhalte <content>.
     Vorsicht: <content> kann auch ein leerer String sein.
   - Es wird geprüft, ob <command> eines der folgenden Ausdrücke ist:
     OK
     WARNING
     SEVERITY
     CONSTANT
     PICTURE
Marschall                    Informational                     [Page 15]

Internet-Draft    ViaThinkSoft StatusMon Specification        March 2011
ansonsten COMMAND UNKNOWN
und dann die argumente prüfen

3.0 Ideas and suggestions for Status Monitor Interface 3.0

Following things might change in version 3.0. I want to describe why
this features are not yet added in version 2.0 and why there are
problems.

1. Official support for the HTTPS protcol
   The problem here is that the Status Monitor Client has to rely on
   trusted root certificates. Especially with server applications
   (e.g. a PHP client), there can be heavy problems in supporting the
   HTTPS connection especially when self-signed TLS certificates are
   used.
2. Possibility to support authentification
   There are 2 problems:
   First, the client has to support it. There may be multiple
   authentification methods (e.g. PLAIN, DIGEST...)
   Second, the password has to be stored
3. XML bei Verteiler
4. Unicode-Support

3.  Security Considerations

   Security issues are not discussed in this memo.

References

   [RFC-1778]   T. Howes, S. Kille, W. Yeong, C. Robbins, "The String
                Representation of Standard Attribute Syntaxes",
                RFC-1778, March 1995.

Author's address

   Daniel Marschall
   ViaThinkSoft
   Eichendorffweg 6
   D-69245 Bammental
   Germany

   Phone:   +49 6223-488840
   Fax:     +49 6223-867927
   EMail:   daniel-marschall@viathinksoft.de









Marschall                    Informational                     [Page 16]

Internet-Draft    ViaThinkSoft StatusMon Specification        March 2011

Full Copyright Statement

   Copyright (C) The Internet Society (2011).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




















Marschall                    Informational                     [Page 17]

Internet-Draft    ViaThinkSoft StatusMon Specification        March 2011


















---

TODO
- intro
- Client implementierung
- verteilerliste definition
- Mögliche Rückgabe werte eines v1, v2 monitor-client software
- beispiele für anwendung + beispielscripts







client=man kann einstellen, ob gewarnt wird wenn text ändert, aber
const/severity nicht
        es wird empfohlen, dass text gespeichert im monitor
es steht frei, ob speicherung aller const...severity...text... erhalten
wird, wenn client pc neu startet


------------






2.0
zustände eines statusmonitors
error,
ok,
warning,
not checked
Marschall                    Informational                     [Page 18]

Internet-Draft    ViaThinkSoft StatusMon Specification        March 2011

2.0        Definition eines Statusmonitors

Ein Statusmonitor ist eine auf Schnittstelle, die es erlaubt, Dienste
über das Internet
mittels einer speziellen Software zu überwachen.

Bei einem Statusmonitor handelt es sich um eine spezielle HTML-URL, die
von einem
Script wie z.B. PHP geneiert werden kann und eine für Browser versteckte
Information
(HTML-Kommentar oder HTTP-Response-Header) enthält. Diese Information
kann verwendet
werden, um den Benutzer zu warnen.

Nachfolgend wird mit "StatusMon-Interface" diese versteckte Information
betitelt.
Die Version 1.0 des StatusMon-Interface 


3.0        Mögliche Einsatzgebiete für einen Statusmonitor

Mögliche Einsatzgebiete für einen Statusmonitor sind

-        Überwachen von Online-Software wie z.B. phpBB, Joomla,
Wikimedia, phpMyAdmin
        etc. und warnen, sobald eine neue Version (mit potentiellen
        Sicherheitsupdates) vorliegt.
-        Überwachen des verfügbaren Speicherplatzes einer
Serverfestplatte und warnen,
        sobald ein Grenzwert überschritten wurde.


MarxEngine
Personal WebBase
Promoter




Die Anforderungen an einen Statusmonitor sind:
1. Der Service MUSS stets erreichbar sein. Ist der Host "down", entsteht
eine Warnung.
2. Als Protokoll SOLLTE "http" verwendet werden. "https" Verbindungen
werden aufgrund der Kompatibilität nicht empfohlen.
3. Der Statusmonitor MUSS erreichbar sein ohne jegliche
   erforderliche POST oder Authentifikationsdaten (Passwort).
4. Es MUSS einer der folgenden Kommentare sich in der Ausgabe
   befinden:
   <!-- STATUS: OK -->
   <!-- STATUS: WARNING -->
5. Es MUSS die Groß- und Kleinschreibung und alle Leerzeichen
   beachtet werden.
Marschall                    Informational                     [Page 19]

Internet-Draft    ViaThinkSoft StatusMon Specification        March 2011
6. "OK" und "WARNING" DÜRFEN NICHT gemeinsam auftreten.
7. Es SOLLTE zusätzlich eine der folgenden Kopfzeilen in der
   HTTP-Response gesendet werden:
   X-Status: OK
   X-Status: Warning


Spezifikationen für das ViaThinkSoft StatusMon-Interface

Einsatzgebiete für StatusMon
- versionscheck
- positive responder
- verteiler

Spezifikation der Version 1
Der Status-Wert wird wie folgt entnommen
Inhalt <!-- STATUS: [wert] --> befindet sich in der Datei. Es wird nur
das ERSTE Vorkommen beachtet!
Es gibt folgende Status-Werte:
OK
WARNING
Spezifikationen der Version 2
Version 2 ist vollständig mit Version 1 abwärtskompatibel
Es kommen folgende Status-Werte hinzu:
GRAPHICAL <url>
SEVERITY <integer>
SEVERITY <integer> <text>

Zustandsspeichernede Statuscodes
WATCH <text>

Spezifikationen für Verteilerliste, Version 1.0
Eine Verteilerliste hat folgende Struktur:
<url> <interval> <name>


Beispiele: Errorcode kann ein unixtimestamp sein - warnung, sobald ein
ereignis neuer ist


Idee: event. auch ein hash anbieten, alarm bei änderung?
Implentierung
wie kann man ein rfc verfassen?




verteiler
- url
- interval
- (options??? no, client specific)
- monitor name

Marschall                    Informational                     [Page 20]

Internet-Draft    ViaThinkSoft StatusMon Specification        March 2011



fußnoten
- It is recommended to prefer statusmon 1.0 interface if the monitor
only outputs OK or WARNING. this means, use no OID notation and use at
least one HTML comment.
- [ ]= option



useragent für delphiapp



limitatons
- public
- only 1 monitor per html site



redirect muss beachteet werden
cookies optional


der client entscheidet, ob ein <text> wechsel bei picture,constant etc.
eine notification ausgibt!
        (option)



fraglich:
        message mehrmals ausgeben oder nur 1 mal?


freiheiten beim client
- es ist frei, ob der status beim herunterfahren gespeichert wird
(constant, severity, picture, ...)
- erstellen von log files
- herunterladen des pictures



statusmon flags
- name
- visit next
- warnagain at same level?
- include others (oder lieber verteilerliste ???)

in verteilerliste
- revisit after
- others

Marschall                    Informational                     [Page 21]

Internet-Draft    ViaThinkSoft StatusMon Specification        March 2011


php script kann status monitors prüfen per cron und kann sms oder email
senden etc (vts service idee)
netzwerkstatus prüfen


---

Verteilerliste

A distribution list is a list of status monitor URLs which a client can
import.
It also contains intervals, names, ...

example: multiple servers

The url can be absolute or relative.

---

PROBLEME:

1. was ist mit char-encoding bei html-kommentaren oder metatags?
   was ist mit unicode innerhalb von response-header?



MIT EINBEZIEHEN
- BNF: http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html#sec2.1
- char encoding für response header
  TEXT           = <any OCTET except CTLs,
                        but including LWS>
  wie lang kann der response header sein?




distribution list: -1 as interval => default interval of the client
(configurable in the client)


The reason why <!-- --> is allowed: besser zu implementieren, obwohl
parser es ignorieren könnten
evtl in version 3: streichen


weitere 3.0 ideen:
- full asn.1 module support?
- eigenes statmon protokoll



Marschall                    Informational                     [Page 22]

Internet-Draft    ViaThinkSoft StatusMon Specification        March 2011


unicode @ statusmonitor + verteilerliste?
versionsangabe in verteilerliste

















































Marschall                    Informational                     [Page 23]