Logging and monitoring

All output of the application is in JSON format according to the BCI logging guidelines.

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. STOPPING: Logged when a migration fails, stopping the application.

Module health Endpoints and K8s probes

If the modules get installed behind a reverse proxy i.e. /smdp/* then the prefix has to be prepended to the given paths (i.e. /health gets to /smdp/health).

Overall status

Health Endpoint
- Endpoint Address: /health
- Expected Status Code: HTTP Status 200
- Failure Status Code: HTTP Status 503

Service

By default the service is listening on http port 2501. More guidance on how to configure the probes can be found here: Bosch.Foundation.Health#configure-kubernetes-to-use-probes

Health Endpoint
- Endpoint Address: /health
- Expected Status Code: HTTP Status 200
- Failure Status Code: HTTP Status 503
Startup Probe Endpoint
- Endpoint Address: /health/startup
- Expected Status Code: HTTP Status 200
- Failure Status Code: HTTP Status 503
Liveness Probe Endpoint
- Endpoint Address: /health/live
- Expected Status Code: HTTP Status 200
- Failure Status Code: HTTP Status 503
Readiness Probe Endpoint
- Endpoint Address: /health/ready
- Expected Status Code: HTTP Status 200
- Failure Status Code: HTTP Status 503
Ping Endpoint
- Endpoint Address: /ping
- Expected Status Code: HTTP Status 200
- Failure Status Code: n/a, timeout

RabbitMQ

Deviation Processor should process incoming messages from RabbitMQ almost immediately. In case of a crash or restart of Deviation Processor, the messages will not be consumed in the queue until the service is up and running again. The configured TTL for messages in the queue is 1 week, the queue will not be deleted automatically. In case of the removal of the Deviation Processor module from the system, an operator has to delete the queues manually.