Logging and Monitoring

This chapter describes the logging and monitoring capabilities of ADONIS for containerised deployments. It covers log generation, storage, retention, monitoring integration, and platform health check mechanisms for Docker Compose and Kubernetes environments.

Logging

Both the web server and application server containers generate log information for system events and errors.

Logging in ADONIS follows a dual approach to support both container-native workflows and application-specific requirements:

• Persistent Storage: Logs are written to persistent storage because ADONIS requires local log files to generate a Support Information Package (SIP) for troubleshooting by technical support.

  In Docker Compose, this is typically achieved using bind mounts (for example, ./logs/webserver) or named volumes configured directly in the docker-compose.yml file.

  In Kubernetes, a dedicated PersistentVolumeClaim (PVC) is used for storage. The corresponding Persistent Volumes (PV) and PVCs are configured through the supplied Helm chart.

• Standard Streams (stdout/stderr): In addition to being written to files, logs are also forwarded to the standard container streams (stdout and stderr). This enables integration with external logging solutions such as central log collectors, SIEM platforms, and data lakes.

Log Storage and Retention

Log files are stored on the configured persistent storage. Retention periods, rotation policies, and rollover settings can be configured through the logging configuration. The effective retention period depends on several factors, including:

• the configured logging settings

• the available customer infrastructure resources

• organisational operational policies and compliance requirements

Log Levels

ADONIS uses the following log levels:

Log Level	Description
INFO	General operational information
WARN	Warnings indicating potential issues
ERROR	Errors that affect functionality
SEVERE	Errors that severely affect functionality
DEBUG	Detailed diagnostic information (only enabled in debug mode)

Logging Behaviour

Logging behaviour is configured entirely through environment variables defined in the docker-compose.yml file for Docker Compose deployments or the Helm values.yaml file for Kubernetes deployments.

Configurable parameters include:

• log level

• maximum file size

• maximum log history

• total log size limits

Data Protection in Logs

Sensitive values and personal data written to logs are pseudonymised wherever applicable.

Log Output Format

Whenever a log entry is created, a new line is written to the relevant log file and forwarded to the standard container streams (stdout and stderr).

Log entries use the following format:

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

or

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

Where:

• TIMESTAMP: The time when the log entry was created (year, month, day, hour, minute, second, millisecond).

• LOGLEVEL: The log level of the entry (for example, INFO, WARN, ERROR).

• TYPE: The type of the entry (for example, ROOT, MONITORING, or SECURITY).

• PROCESS_ID: The ID of the process that created the log entry.

• THREAD_ID: The ID of the thread that created the log entry or null.

• SESSION_ID: The ID of the session in whose context the entry was created or null.

• REQUEST_ID: The ID of the request in whose context the entry was created or null.

• CLIENT_TYPE: Either A if the entry was written in the context of the Administration Toolkit, or * for all other cases.

• SUB_TYPE: The optional subtype of the log entry, for example EXTCONNECT or AUDIT. This is only relevant for log entries created by the application server.

• CONTENT: The actual content of the log entry.

Example

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

Monitoring

ADONIS is designed to integrate into existing enterprise monitoring and observability solutions. Monitoring capabilities include log forwarding, integration with common log collection solutions, and built-in platform health check mechanisms for containerised deployments.

Log Monitoring

ADONIS does not provide a built-in logging stack. Instead, customers are expected to integrate ADONIS logs into their existing observability or monitoring infrastructure.

ADONIS supports this through the following mechanisms:

• log output via standard container logging mechanisms (stdout/stderr)

• compatibility with common log collection agents (for example, Fluent Bit)

• forwarding logs to systems such as OpenSearch, Elasticsearch, or similar platforms

In Kubernetes environments, container logs are typically stored temporarily on the node and collected by a log processor before being forwarded to the organisation's central logging system.

Metrics and operational monitoring can be integrated into existing tools such as Prometheus, Grafana, or other enterprise monitoring platforms.

Monitoring Mechanisms

ADONIS provides built-in monitoring mechanisms for platform-level health checks.

The delivered container images include functionality for Kubernetes liveness and readiness probes.

• Liveness: Verifies that the web application process is running.

• Readiness: Verifies that the web application is available to users and not operating in emergency mode.

In Docker Compose deployments, the probes can be executed manually inside the web server container using the probes utility. The corresponding health checks can also be configured directly in the docker-compose.yml file.

Docker Probe Utility

The following command displays the available probe options:

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

The following command executes the liveness probe:

docker exec your_webserver_container_name probes -liveness Success: 200

The following command executes the readiness probe:

docker exec your_webserver_container_name probes -readiness Success: 200

In Kubernetes deployments, the delivered Helm chart already contains predefined liveness and readiness probes.

Helm Chart Probe Configuration

livenessProbe:

exec:

command:

- /aserver/aprobes

- "--path=liveness"

readinessProbe:

exec:

command:

- /aserver/aprobes

- "--path=readiness"