Understand operational logs

Automation orchestrator writes structured operational logs to pod standard output for every platform component and, when configured, forwards them to an external OpenTelemetry Protocol (OTLP) compatible observability backend.

Use operational logs to diagnose errors, trace requests, and assess system behavior using your existing log aggregation tooling.

Operational logs and audit events

Operational logs and audit events are distinct. Operational logs capture the technical details of what the platform is doing internally: request processing, database connectivity, worker lifecycle, and error traces. Audit events record business-level activity: who did what and when.

Both write to pod standard output, but they use separate loggers and serve different purposes.

Log format

Operational logs are structured JSON by default. Each log entry contains:

Field Description
timestamp ISO 8601 UTC timestamp.
level Log level:debug,info,warning,error, orcritical.
event The log message or event name.

Additional context fields appear when relevant, such as workflow_id, execution_id, activity_id, and request_id.

Request and workflow correlation

Automation orchestrator includes correlation identifiers in log entries to enable cross-component tracing:

  • request_id — populated from the X-Request-Id HTTP header. Links all log entries produced during a single request across the API server and middleware. Clients can supply this header to enable end-to-end tracing.
  • workflow_id, execution_id, activity_id — present in entries from the workflow worker. Link log entries to a specific workflow, run, and node.

Access logs

All components write to pod standard output. The platform does not use file-based logging.

Component deployment names follow the pattern cr-name-component, where cr-name is the name of your AutomationOrchestrator custom resource. To stream logs from a running component:

$ oc logs -f deployment/cr-name-backend -n namespace
$ oc logs -f deployment/cr-name-worker -n namespace
$ oc logs -f deployment/cr-name-temporal -n namespace

To retrieve logs from a database migration job, first find the job name, then retrieve its logs:

$ oc get jobs -n namespace
$ oc logs job/cr-name-backend-migration-generation -n namespace
$ oc logs job/cr-name-temporal-migration-generation -n namespace

Log retention depends on your OpenShift cluster's log aggregation configuration. For long-term retention, configure an OTLP forwarding endpoint.