Logging and monitoring

The services log to std:out. Monitoring solutions such as Elasticsearch and Kibana elk can be attached.

The logging can be enabled as described for the individual containers in Setup and configuration.

Security logging

The following security related events according the NEXEED logging guidelines are logged: - INPUT_VALIDATION_FAILED - ENDPOINT_DOES_NOT_EXIST - UNAUTHORIZED_ACCESS - UNAUTHENTICATED_ACCESS - TLS_DISABLED* - INVALID_SCOPE - GRANT_UNSUPPORTED

*The TLS_DISABLED event is logged when the Web Portal itself is not configured to listen on HTTPS or does not use a secured communication to the database and message broker

Database migration logging

Database migration logs are now managed through lifecycle logging, ensuring structured and consistent tracking of migration events. These logs provide visibility into the migration process, helping to confirm successful updates or diagnose failures. The following lifecycle log events are recorded:

DATA_MIGRATION_STARTED: Logged at the start of the migration process. DATA_MIGRATION_SUCCESSFUL: Logged upon successful completion of the migration. DATA_MIGRATION_FAILED: Logged when a migration fails, including error details.

IAS logging guidelines configuration

The Web Portal follows IAS logging guidelines with the following logger level configuration:

Default -> Warning (guideline level: WARN)
SECURITY -> Information (guideline level: INFO)
LIFE-CYCLE -> Information (guideline level: INFO)

The SECURITY and LIFE-CYCLE logger levels are required to be set at Information level as per IAS logging guidelines.

Runtime log level changes

Web Portal supports runtime log-level changeswithout restarting the pod.

The following endpoint is available for operators:

GET /api/v1/logging reads the current dynamic logging configuration.
PUT /api/v1/logging updates the dynamic logging configuration.

The endpoint is protected by resource authorization and requires the logging resource with read and modify privileges.

The ConfigMap name is a constant: dynamic-logging-configmap.

Runtime settings are read from DynamicLogLevelSettings:

WatchTimeoutSeconds (default: 1800)
MaxRetryDelaySeconds (default: 60)
PodNamespace (required in Kubernetes)

The ConfigMap payload key is logging-config.json and must contain DynamicLogLevelConfiguration entries for one or more services.

By default, the delivered Helm configuration keeps DynamicLogLevelConfiguration empty. Add entries only when a temporary runtime log-level override is required.

Each entry has:

ServiceName — The service name to match (compared case-insensitively against the service name). Set to null or omit for a default/fallback entry.
ValidUntil — DateTimeOffset after which the entry expires and the dynamic log levels are cleared automatically.
DynamicLogLevel — Dictionary of category to log level. Supported levels: TRACE, DEBUG, INFO / INFORMATION, WARN / WARNING, ERROR, FATAL / CRITICAL, OFF / NONE.

Service matching logic: the hosted service first looks for an entry whose ServiceName matches the running service. If none is found, it falls back to the first entry with a null or empty ServiceName (the default entry). If neither exists, the dynamic logging configuration is cleared.

Example payload format for an active override:

{
	"DynamicLogLevelConfiguration": [
		{
			"ServiceName": "Bosch.Nexeed.WebPortal.CoreService",
			"ValidUntil": "2026-06-30T23:59:59+00:00",
			"DynamicLogLevel": {
				"Default": "INFO",
				"Microsoft": "INFO",
				"Bosch": "INFO"
			}
		}
	]
}

After troubleshooting, remove the entry again or let it expire via ValidUntil.

Troubleshooting

If runtime log-level updates are not applied:

verify Core Service environment variables under DynamicLogLevelSettings are set correctly,
verify the dynamic-logging-configmap exists in the service namespace,
verify the Core Service service account has get, list, watch, and update permissions for ConfigMaps,
verify the request user has a role granting logging resource permissions.