Das hier beschriebene Modell beschreibt die beim Erfassen von Nutzungsdaten mit dem Logging-Framework verwendeten Objekt-Klassen. Da es beim Logging-Framework um die Erfassung von Nutzungsdaten geht, ist ein Event hier das zentrale Element, welches sich durch verschiedene Attribute in drei unterschiedliche Unterklassen differenzieren lässt:
Ein Event grundsätzlich immer die folgenden Attribute:
Attribut | Bedeutung | JSON-Identifier | ElasticSearch-Identifier |
---|---|---|---|
timestamp | Zeitpunkt des Events | DATE | @timestamp |
instanceId | ID der Instanz der Applikation | INSTANCEID | INSTANCEID |
eventSource | Quelle / Verursacher des Events | SOURCE | SOURCE |
eventType | Typ des Events, z. B. DISPLAY_SHOW für das Einblenden eines Elements, s. Enumerations-Typen | TYPE | TYPE |
eventData | Zusätzliche Daten im Kontext des Events, bspw. eine ID des Ziel-Objekts einer Interaktion | DATA | *entfällt, da Kind-Elemente zur einfacheren Indizierung in des Wurzel-Element verschoben werden |
usersession | ID zur Identifierung einer Nutzer-Sitzung | SESSION | SESSION |
Für eine Standardisierung und Vereinheitlichung von Quellen und Arten von Events wurden Datenmodell des Logging-Framework Enumerations-Typen eingeführt:
EventSource | Bedeutung |
---|---|
USER | Quelle des Events war der Benutzer |
SYSTEM | Quelle des Events war das System |
ENVIRONMENT | Quelle des Events war etwas im Umfeld des System (äußere Einflüsse) |
Die SOURCE eines Events gibt also an, um welche Art von Event es sich handelt.
EventType | Type | Bedeutung |
---|---|---|
EventTypeSystem | DISPLAY_SHOW | Element wird sichtbar / geöffnet |
EventTypeSystem | DISPLAY_HIDE | Element wird unsichtbar / geschlossen |
EventTypeSystem | DATA_AVAILABLE | Daten sind zum Laden verfügbar |
EventTypeSystem | DATA_LOADED | Daten wurden geladen |
EventTypeSystem | LOG | Wichtige Log-Meldung der Instanz (Level: WARN oder ERROR) |
EventTypeSystem | STARTUP | Instanz wird gestartet |
EventTypeSystem | STARTUP_FINISHED | Instanz wurde gestartet / ist einsatzbereit |
EventTypeSystem | ALIVE | Instanz ist funktionsfähig |
EventTypeSystem | SHUTDOWN | Instanz wurde heruntergefahren / beendet |
EventTypeUser | USER_ACTIVITY | Eine von einem Nutzer aktiv ausgelöste Interaktion, bspw. Drücken einer Bedienoberfläche |
EventTypeUser | USER_PASSIVE | Ein von einem Nutzer passiv ausgelöstes Event, bspw. erfasst durch andere Sensoren (Blick auf bestimmtes Objekt,...) |
EventTypeUser | USER_SESSIONSTART | Ein Nutzer wurde erkannt und eine Session wurde gestartet. |
EventTypeUser | USER_SESSIONEND | Die Session wurde beendet. |
EventTypeUser | EXIT | Ein Nutzer verlässt die Applikation. |
EventTypeUser | ENTER | Ein Nutzer beginnt die Interaktion mit der Applikation. |
Unter Session wird im Logging-Framework ein Zeitabschnitt definiert, in welchem ein (oder mehrere) Benutzer mit dem System interagiert.
Auch zusätzliche Eventdaten im Feld eventData unterliegen einer Kategorisierung. Diese sind je Element einzigartig, können, müssen aber nicht bei jedem Event verwendet werden. Bisher sind hier folgende Kategorien definiert:
EventData | Bedeutung |
---|---|
DATA_ID | Der eindeutige Schlüssel mit dem das dem Event zugrundeliegende Informationsobjekt referenziert werden kann. |
DATA_TYPE | Der Typ des dem Event zugrundeliegenden Informationsobjekts. |
EVENT_POSITION | Position in Form von X / Y-Koordinaten |
TARGET_CLASS | Java-Klasse des Event-auslösenden Elements |
TARGET_SCALE | Skalierungswerte (X/Y) ( = Größe) des Event-auslösenden Elements |
CUSTOM | Benutzerdefinierter Wert. Kann beliebig bei der Integration des Logging-Frameworks befüllt werden. Beinhaltet z. B. die Log-Meldung bei EventTypeSystem=LOG |
ACTIVITY | Detail-Aktion die durchgeführt wurde, beim einem EventTypeUser=USER_ACTIVITY z. B. CLICKED, PRESSED, DRAG,... |
Diese Liste ist aufgrund der Offenheit der Anzahl an Parametern flexibel nach den weiter zu evaluierenden Bedürfnissen zu erweitern / anzupassen.
Wie den Spalten "JSON-Identifier" sowie "ElasticSearch-Identifier" zu entnehmen ist, ist generell zu Differenzieren zwischen dem Modell im Java-Kontext und dem Modell im ElasticSearch-Kontext. Im ElasticSearch-Kontext sind zum einen noch zusätzliche, organisatorische Felder von ElasticSearch enthalten (auf die an dieser Stelle nicht weiter eingegangen wird) und zum anderen wurde hier zur weiteren Optimierung der Indizierung das Objekt "DATA" aufgelöst und die Kind-Elemente für ElasticSearch auf die oberste Ebene verschoben. Zusätzlich wurde das DATE-Element in das timestamp-Element überführt:
JSON-Repräsentation, Java:
{ "DATE": "2021-02-06 16:34:56.035", "SOURCE": "SYSTEM", "SESSION": "821309ed-ece8-4b35-b658-372738e526e2", "INSTANCEID": "TestMirror", "TYPE": "LOG", "DATA": { "DATA_TYPE": "WARN", "CUSTOM": "Failed adding visualitem to flow." } } |
JSON-Repräsentation, ElasticSearch (ElasticSearch-Felder ausgeblendet):
{ ... "CUSTOM": "Failed adding visualitem to flow.", "DATA_TYPE": "WARN", ... "INSTANCEID": "TestMirror", ... "SOURCE": "SYSTEM", ... "SESSION": "821309ed-ece8-4b35-b658-372738e526e2", ... "@timestamp": "2021-02-06T16:34:56.046Z", "TYPE": "LOG", ... } |