CareTaker: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
|||
Zeile 27: | Zeile 27: | ||
== Begriffe == | == Begriffe == | ||
WatchDog | '''WatchDog''' | ||
Zeitgesteuertes System, das aktiv nach vorgebbaren Zeitabschnitten aktiv wird. Durch WatchDogs | Zeitgesteuertes System, das aktiv nach vorgebbaren Zeitabschnitten aktiv wird. Durch WatchDogs | ||
Zeile 34: | Zeile 34: | ||
lynx -dump -mime_header ... | lynx -dump -mime_header ... | ||
Zusage | '''Zusage''' | ||
Bei einem "Watchdog on demand" Antrag eines Client gibt er eine Zeitangabe mit "Zusage" die | Bei einem "Watchdog on demand" Antrag eines Client gibt er eine Zeitangabe mit "Zusage" die | ||
Zeile 41: | Zeile 41: | ||
Beispiel: Nach Tagesabschluss start muss inerhalb 6 Stunden der Tagesabschluss Ende kommen. | 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 Vorgänge müssen von Menschen als erledigt gebucht werden, ansonsten erzeugt ein | ||
Trouble Ticket Vorgang nach dem Wiedervorlage-Zeitraum wiederum ein kritsches Event. | Trouble Ticket Vorgang nach dem Wiedervorlage-Zeitraum wiederum ein kritsches Event. | ||
SysLog | '''SysLog''' | ||
Durch den SysLog Dienst lassen sich kritische Zustände loggen. (für fehler beim Tagesabschluss) | |||
Trouble Ticket | '''Trouble Ticket''' | ||
positive int64 Ganzzahl. | positive int64 Ganzzahl. | ||
Zeile 58: | Zeile 58: | ||
Wartestellungsfrist in einen Fahrplan umgestellt wird. | Wartestellungsfrist in einen Fahrplan umgestellt wird. | ||
Brisanz-Klassen | '''Brisanz-Klassen''' | ||
Sind Gruppen von eMail-Adresse. Der Brisanz-Admin kann Einträge in diese eMail | Sind Gruppen von eMail-Adresse. Der Brisanz-Admin kann Einträge in diese eMail | ||
Listen machen. | Listen machen. | ||
Abmelden | '''Abmelden''' | ||
Durch Abmelden einer Störung wird diese behoben und die Benachrichtigungs-Logik | Durch Abmelden einer Störung wird diese behoben und die Benachrichtigungs-Logik |
Version vom 6. November 2007, 14:50 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