Project

General

Profile

Actions

Feature #1177

open

Monitoring

Added by Dirk von Suchodoletz about 6 years ago. Updated almost 5 years ago.

Status:
Feedback
Priority:
Normal
Start date:
04/24/2018
Due date:
06/28/2019 (over 4 years late)
% Done:

100%

Estimated time:

Description

Es kann notwendig sein, dass Nutzer (hauptsächlich Administratoren) ein Feedback über die laufenden Events und die (Mis-)erfolge bekommen. Beispielsweise will man Rückmeldungen bekommen, ob WoL oder ähnliches geklappt hat.

Actions #1

Updated by Udo Daniel Walter almost 6 years ago

  • Assignee deleted (Christian Hofmaier)
Actions #2

Updated by Udo Daniel Walter over 5 years ago

  • Status changed from New to In Progress
  • Assignee set to Udo Daniel Walter
Es wird einen Event Log geben. (UI im Dashboard und über API)
  • Client Boots, Events, Crashs, ...
  • Filterbar nach Name, Typ, Zeitraum, ...
API um den aktuellen Zustand zu bekommen
  • Laufende Clients und was gebootet wurde
  • Laufende Events
Actions #3

Updated by Dirk von Suchodoletz over 5 years ago

  • Due date set to 02/28/2019

Ist hier der Austausch mit Manuel (bwCloud) erfolgt? Was waren die Absprachen und Ergebnisse? Im Ticket dokumentieren ...

Actions #4

Updated by Udo Daniel Walter over 5 years ago

Beim Austausch mit Manuel kam zum Thema Monitoring nur raus, dass es einen Log geben soll. (Siehe Update #2)

Actions #5

Updated by Dirk von Suchodoletz over 5 years ago

Das Entscheidende ist hier ja das Zusammenspiel und Ineinandergreifen der Komponenten. Welche Techniken dazu zum Einsatz kommen, sind zu überlegen. Davon hängt dann ja jeweils die mögliche Implementierung ab ...

Actions #6

Updated by Udo Daniel Walter about 5 years ago

  • % Done changed from 0 to 50
Die Grundlagen für das Monitoring sind schon implementiert.
Die verschiedenen Module des BAS loggen Ereignisse in den Log. Dazu gehören unter anderem:
  • Booten von Clients
  • Aktionen über die Webapp und API
  • Automatisch stattfindende Aktionen (Zeit gesteuerte Events, Errors, Sync, ...)

Dabei wird abgespeichert um was für eine Art von Ereignis es sich handelt (z.B. neuer Client, Client gelöscht, Client gestartet, ...) und eine Beschreibung mit zusätzlichen Details.
Falls relevant wird auch eingetragen in welcher Gruppe, an welchem Client und/oder von welchem User das Ereignis ausgelöst wurde.

Noch nicht entschieden (Versuchen wir am Dienstag mit den verschiedenen Parteien abzuklären):
Ist es sinnvoll zu der/dem unter Umständen eingetragenen Gruppe/Client/User ein "Snapshot" zu speichern und wenn ja welche Daten (Name, UUID, ...)?
So könnte man bei gelöschten und geänderten Gruppen/Clients/Usern besser den Verlauf nachvollziehen, da man nicht einfach nur die ID hat. Falls das nicht benötigt wird könnte man sich diese Datenmengen allerdings sparen.

Actions #7

Updated by Udo Daniel Walter about 5 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 50 to 100

Der Log ist implementiert.

Actions #8

Updated by Dirk von Suchodoletz almost 5 years ago

  • Due date changed from 02/28/2019 to 06/28/2019
  • Status changed from Closed to Feedback

Bitte Hinweis auf Dokumentation hinterlegen. Wie sieht es mit:

  • Laufende Clients und was gebootet wurde
  • Laufende Events

Sowohl für Pools als auch für Serverlandschaft relevant ...

Actions

Also available in: Atom PDF