CareTaker: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
|||
Zeile 11: | Zeile 11: | ||
html-Templates entsprechend dem Zustand von Systemen (ONLINE,OFFLINE) ins Web gestellt werden. | html-Templates entsprechend dem Zustand von Systemen (ONLINE,OFFLINE) ins Web gestellt werden. | ||
Verschlüsselte Übertragung der Log-Anfragen | * Verschlüsselte Übertragung der Log-Anfragen | ||
der Log-String wird in 3 Stufen umgesetzt | |||
Stufe 1: die Webanfrage wird BlowFish verschlüsselt, der Key ist GaZMa bekannt<bt> | |||
Stufe 2: base64 Kodierung des "rauschen" | |||
Stufe 3: RFC 1738 konformes umkodierung | |||
- hier wird nun über Web übertragen - | - hier wird nun über Web übertragen - | ||
Zeile 25: | Zeile 24: | ||
der Log-Event wird auf dem Server in einer firebird Datenbank abgelegt (im Moment | der Log-Event wird auf dem Server in einer firebird Datenbank abgelegt (im Moment | ||
noch Standard log files!) | noch Standard log files!) | ||
== Begriffe == | |||
WatchDog | WatchDog | ||
Zeitgesteuertes System, das aktiv nach vorgebbaren Zeitabschnitten aktiv wird. Durch WatchDogs | |||
lassen sich "Zusage" oder "Wiedervorlage" Fristen überprüfen und deren Einhaltung testen. | |||
Implemetierung via cron-jobs, als "brwoser" wird lynx verwendet. | |||
lynx -dump -mime_header ... | |||
Zusage | Zusage | ||
Bei einem "Watchdog on demand" Antrag eines Client gibt er eine Zeitangabe mit "Zusage" die | |||
Festlegt, wie lange der WatchDog ruhig bleiben soll. Erfolgt in diesem Zeitraum keine Abmeldung | |||
des Watchdogs schlägt dieser Alarm. (für Tagesabschluss, Tagwache) | |||
Beispiel: Nach Tagesabschluss start muss inerhalb 6 Stunden der Tagesabschluss Ende kommen. | |||
Wiedervorlage | Wiedervorlage | ||
Trouble Ticket Vorgänge müssen von Menschen als erledigt gebucht werden, ansonsten erzeugt ein | |||
Trouble Ticket Vorgang nach dem Wiedervorlage-Zeitraum wiederum ein kritsches Event. | |||
SysLog | SysLog | ||
Zeile 67: | Zeile 68: | ||
kann deaktviert werden. (Einfach Eingabe des Trouble-Tickets in einem admin | kann deaktviert werden. (Einfach Eingabe des Trouble-Tickets in einem admin | ||
bereich). | bereich). | ||
== Ticket Arten == | == Ticket Arten == |
Version vom 6. November 2007, 14:49 Uhr
CareTaker ist ein System das Funktionen überprüft, und auf Störugen aufmerksam machen kann bevor Kunden diese bemerken. Er ist auch die zentrale Stelle an die Fehlerzustände gemeldet werden. Insbesondere kritische Module (eCommerce) melden exceptions an den den Caretaker.
Ein Server im InterNet nimmt Log-Events von verteilten Anwendungen entgegen. Der Dienst wird auch selbst aktiv indem er Trouble Tickets vergibt, und einer Problemsache mit Fristen nachgeht. Durch eine Watchdog on demand Funktion müssen "open" - Logs rechtzeitig durch "close" - Logs abgemeldet werden, ansonsten entsteht ein Trouble Ticket. Durch eine Auto Watchdog Funktion wird ständige Kontrolle diverse Systeme vorgenommen. Projekt-Admins können TCareTaker Events mit eMail-Notifikations verknüpfen. Des weiteren können html-Templates entsprechend dem Zustand von Systemen (ONLINE,OFFLINE) ins Web gestellt werden.
- Verschlüsselte Übertragung der Log-Anfragen
der Log-String wird in 3 Stufen umgesetzt
Stufe 1: die Webanfrage wird BlowFish verschlüsselt, der Key ist GaZMa bekannt<bt> Stufe 2: base64 Kodierung des "rauschen" Stufe 3: RFC 1738 konformes umkodierung
- hier wird nun über Web übertragen -
der Log-Event wird auf dem Server in einer firebird Datenbank abgelegt (im Moment noch Standard log files!)
Begriffe
WatchDog
Zeitgesteuertes System, das aktiv nach vorgebbaren Zeitabschnitten aktiv wird. Durch WatchDogs lassen sich "Zusage" oder "Wiedervorlage" Fristen überprüfen und deren Einhaltung testen. Implemetierung via cron-jobs, als "brwoser" wird lynx verwendet. lynx -dump -mime_header ...
Zusage
Bei einem "Watchdog on demand" Antrag eines Client gibt er eine Zeitangabe mit "Zusage" die Festlegt, wie lange der WatchDog ruhig bleiben soll. Erfolgt in diesem Zeitraum keine Abmeldung des Watchdogs schlägt dieser Alarm. (für Tagesabschluss, Tagwache) Beispiel: Nach Tagesabschluss start muss inerhalb 6 Stunden der Tagesabschluss Ende kommen.
Wiedervorlage
Trouble Ticket Vorgänge müssen von Menschen als erledigt gebucht werden, ansonsten erzeugt ein Trouble Ticket Vorgang nach dem Wiedervorlage-Zeitraum wiederum ein kritsches Event.
SysLog
Durch den SysLog Dienst lassen sich kritische Zustände loggen. (für fehler beim Tagesabschluss)
Trouble Ticket
positive int64 Ganzzahl.
- Als kritisch eingestufte Log - Events haben die Erzeugung eines Trouble-Tickets zur folge. Zusammen mit dem Ticket entwirft TCareTaker einen Fahrplan zur Behebung der Störung.
- "Watch on demand" Antragsteller erhalten auch ein Trouble-Ticket, das erst nach Ablauf der
Wartestellungsfrist in einen Fahrplan umgestellt wird.
Brisanz-Klassen
Sind Gruppen von eMail-Adresse. Der Brisanz-Admin kann Einträge in diese eMail Listen machen.
Abmelden
Durch Abmelden einer Störung wird diese behoben und die Benachrichtigungs-Logik kann deaktviert werden. (Einfach Eingabe des Trouble-Tickets in einem admin bereich).
Ticket Arten
- BestellungNunVollstaendigLieferbar
- BestellungNunTeilweiseLieferbar
- BestellungMerkmalTeilweiseLieferbarVerloren
- WareEingetroffen
- LagerPlatzZugeteilt
- LagerPlatzFreigabe
- BelegScan
- Miniscore
- WareRausgegangen
- WareBestellt
- ZahlungPerLastschrift
- ForderungsAusgleich
- KatalogVersendung