Logging und Monitoring

Dieses Kapitel beschreibt die Logging- und Monitoring-Funktionen von ADONIS für containerisierte Deployments. Behandelt werden die Generierung, Speicherung und Aufbewahrung von Logs sowie die Integration in Monitoring-Lösungen und Plattform-Health-Check-Mechanismen für Docker Compose- und Kubernetes-Umgebungen.

Logging

Sowohl der Web-Server-Container als auch der Applikations-Server-Container erzeugen Logeinträge zu Systemereignissen und Fehlern.

Das Logging in ADONIS folgt einem dualen Ansatz, um sowohl container-native Workflows als auch anwendungsspezifische Anforderungen zu unterstützen:

• Persistenter Speicher: Logs werden in persistentem Speicher abgelegt, da ADONIS diese lokalen Log-Dateien benötigt, um ein Support Information Package (SIP) für die Fehleranalyse durch den technischen Support zu erzeugen.

  In Docker Compose werden dafür typischerweise Bind Mounts (z. B. ./logs/webserver) oder Named Volumes verwendet, die direkt in der Datei docker-compose.yml konfiguriert werden.

  In Kubernetes wird für die Speicherung ein dedizierter PersistentVolumeClaim (PVC) verwendet. Die zugehörigen Persistent Volumes (PV) und PVCs werden über das mitgelieferte Helm-Chart konfiguriert.

• Standard-Streams (stdout/stderr): Zusätzlich zur Speicherung in Dateien werden Logs auch auf die Standard-Container-Streams (stdout und stderr) ausgegeben. Dies ermöglicht die Integration mit externen Logging-Lösungen wie zentralen Log-Sammlern, SIEM-Plattformen oder Data Lakes.

Aufbewahrung und Speicherung von Logs

Log-Dateien werden im konfigurierten persistenten Speicher abgelegt. Aufbewahrungszeiträume, Rotationsrichtlinien und Rollover-Einstellungen können über die Logging-Konfiguration angepasst werden. Der tatsächlich verfügbare Aufbewahrungszeitraum hängt unter anderem von folgenden Faktoren ab:

• den konfigurierten Logging-Einstellungen

• den verfügbaren Infrastrukturressourcen des Kunden

• betrieblichen Richtlinien und Compliance-Anforderungen der Organisation

Log-Level

ADONIS verwendet die folgenden Log-Level:

Log-Level	Beschreibung
INFO	Allgemeine Betriebsinformationen
WARN	Warnungen, die auf potenzielle Probleme hinweisen
ERROR	Fehler, die die Funktionalität beeinträchtigen
SEVERE	Fehler, die die Funktionalität schwerwiegend beeinträchtigen
DEBUG	Detaillierte Diagnoseinformationen (nur im Debug-Modus aktiviert)

Logging-Verhalten

Das Logging-Verhalten wird vollständig über Umgebungsvariablen konfiguriert, die in Docker Compose-Deployments in der Datei docker-compose.yml bzw. in Kubernetes-Deployments in der Helm-Datei values.yaml definiert werden.

Zu den konfigurierbaren Parametern gehören:

• Log-Level

• maximale Dateigröße

• maximale Anzahl historischer Logdateien

• Gesamtgröße der Logs

Datenschutz in Logdateien

Sensible Werte und personenbezogene Daten, die in Logdateien geschrieben werden, werden nach Möglichkeit pseudonymisiert.

Format der Log-Ausgabe

Bei der Erstellung eines Log-Eintrags wird eine neue Zeile in die entsprechende Log-Datei geschrieben und an die Standard-Container-Streams (stdout und stderr) weitergeleitet.

Log-Einträge verwenden das folgende Format:

<TIMESTAMP> [<LOGLEVEL>] [T:<TYPE>] [<PROCESS_ID>] [<THREAD_ID>] [<SESSION_ID>] [<REQUEST_ID>] [<CLIENT_TYPE>] <CONTENT>

oder

<TIMESTAMP> [<LOGLEVEL>] [T:<TYPE>] [<PROCESS_ID>] [<THREAD_ID>] [<SESSION_ID>] [<REQUEST_ID>] [<CLIENT_TYPE>] [ST:<SUB_TYPE>] <CONTENT>

Dabei gilt:

• TIMESTAMP: Zeitpunkt der Erstellung des Log-Eintrags (Jahr, Monat, Tag, Stunde, Minute, Sekunde, Millisekunde).

• LOGLEVEL: Log-Level des Eintrags (zum Beispiel INFO, WARN, ERROR).

• TYPE: Typ des Eintrags (zum Beispiel ROOT, MONITORING oder SECURITY).

• PROCESS_ID: ID des Prozesses, der den Log-Eintrag erzeugt hat.

• THREAD_ID: ID des Threads, der den Log-Eintrag erzeugt hat, oder null.

• SESSION_ID: ID der Session, in deren Kontext der Eintrag erzeugt wurde, oder null.

• REQUEST_ID: ID der Anfrage, in deren Kontext der Eintrag erzeugt wurde, oder null.

• CLIENT_TYPE: Entweder A, wenn der Eintrag im Kontext der Administrations-Toolkit geschrieben wurde, oder * für alle anderen Fälle.

• SUB_TYPE: Optionaler Untertyp des Log-Eintrags, zum Beispiel EXTCONNECT oder AUDIT. Dies ist nur für Log-Einträge relevant, die vom Applikations-Server erzeugt werden.

• CONTENT: Der eigentliche Inhalt des Log-Eintrags.

Beispiel

2025-11-25 17:55:31.859 [INFO] [T:WORKER] [19] [2573] [1608282999] [11210] [*] WEBMETHOD START: com.boc.axw.executeTechnical

Monitoring

ADONIS wurde für die Integration in bestehende Enterprise-Monitoring- und Observability-Lösungen konzipiert. Die Monitoring-Funktionen umfassen die Weiterleitung von Logs, die Integration mit gängigen Log-Sammellösungen sowie integrierte Plattform-Health-Check-Mechanismen für containerisierte Deployments.

Log-Monitoring

ADONIS stellt keinen integrierten Logging-Stack bereit. Stattdessen integrieren Kunden die Logs von ADONIS in ihre bestehende Observability- oder Monitoring-Infrastruktur.

ADONIS unterstützt dies durch folgende Mechanismen:

• Ausgabe von Logs über standardisierte Container-Logging-Mechanismen (stdout/stderr)

• Kompatibilität mit gängigen Log-Collection-Agents (zum Beispiel Fluent Bit)

• Weiterleitung von Logs an Systeme wie OpenSearch, Elasticsearch oder vergleichbare Plattformen

In Kubernetes-Umgebungen werden Container-Logs typischerweise temporär auf den Nodes gespeichert und anschließend von einem Log-Prozessor erfasst und an ein zentrales Log-System weitergeleitet.

Metriken und operatives Monitoring können in bestehende Tools wie Prometheus, Grafana oder andere Enterprise-Monitoring-Plattformen integriert werden.

Monitoring-Mechanismen

ADONIS bietet integrierte Monitoring-Mechanismen für Health-Checks auf Plattformebene.

Die ausgelieferten Container-Images enthalten Funktionalität, die Kubernetes liveness- und readiness-Probes unterstützen.

• Liveness: Prüft, ob der Webapplikationsprozess ausgeführt wird.

• Readiness: Prüft, ob die Webapplikation für Benutzer verfügbar ist und nicht im Emergency-Modus betrieben wird.

In Docker Compose-Deployments können die Probes manuell innerhalb des Web-Server-Containers mit dem Dienstprogramm probes ausgeführt werden. Die entsprechenden Health-Checks können außerdem direkt in der Datei docker-compose.yml konfiguriert werden.

Docker-Probe-Dienstprogramm

Der folgende Befehl zeigt die verfügbaren Probe-Optionen an:

docker exec <my_webserver_container_name>_name probes

Usage of probes:

-liveness

Perform liveness check

-readiness

Perform readiness check

-timeout duration

Request timeout duration (e.g., 5s, 10s, 1m) maximum is 5m (default 30s)

-url string

Base URL for health check (default "http://localhost:8080")

Error: Exactly one of --liveness or --readiness must be specified

Der folgende Befehl führt die Liveness-Probe aus:

docker exec your_webserver_container_name probes -liveness Success: 200

Der folgende Befehl führt die Readiness-Probe aus:

docker exec your_webserver_container_name probes -readiness Success: 200

In Kubernetes-Deployments enthält das bereitgestellte Helm-Chart bereits vordefinierte Liveness- und Readiness-Probes.

Helm-Chart-Probe-Konfiguration

livenessProbe:

exec:

command:

- /aserver/aprobes

- "--path=liveness"

readinessProbe:

exec:

command:

- /aserver/aprobes

- "--path=readiness"