Configure OTLP forwarding

Configure automation orchestrator to forward audit events to an external OpenTelemetry Protocol (OTLP) compatible observability backend.

Before you begin

You have cluster administrator access to the OpenShift cluster running automation orchestrator.
You have an OTLP-compatible observability backend with an HTTP endpoint that accepts log data on the /v1/logs path.
If your endpoint requires authentication, you have the API key or TLS certificates ready.

About this task

Automation orchestrator always writes audit events to pod standard output. When you enable OTLP forwarding, events are also exported to your observability backend.

Procedure

If your OTLP endpoint requires authentication, create the appropriate Secret for your auth method. Skip this step if your endpoint requires no authentication.

API key authentication:

$ oc create secret generic ao-otel-api-key \
  --from-literal=api-key=your-api-key \
  -n namespace

Mutual TLS (mTLS):

$ oc create secret tls ao-otel-client-cert \
  --cert=path-to-client.crt \
  --key=path-to-client.key \
  -n namespace

Custom CA certificate (server verification):

$ oc create secret generic ao-otel-ca-cert \
  --from-file=ca.crt=path-to-ca.crt \
  -n namespace

Edit the AutomationOrchestrator custom resource to add the .spec.otel configuration:
```
$ oc edit automationorchestrator cr-name -n namespace
```

Add the otel block. The following examples show the configuration for each authentication method:

API key authentication:

spec:
  otel:
    enabled: true
    endpoint: https://collector.example.com:4318/v1/logs
    serviceName: automation-orchestrator
    authHeaderName: Authorization
    apiKeySecretRef:
      name: ao-otel-api-key

Mutual TLS (mTLS):

spec:
  otel:
    enabled: true
    endpoint: https://collector.example.com:4318/v1/logs
    serviceName: automation-orchestrator
    clientCertSecretRef:
      name: ao-otel-client-cert
    caCertSecretRef:
      name: ao-otel-ca-cert

Custom CA certificate only (server verification):

spec:
  otel:
    enabled: true
    endpoint: https://collector.example.com:4318/v1/logs
    serviceName: automation-orchestrator
    caCertSecretRef:
      name: ao-otel-ca-cert

Save and close the editor.

The operator reconciles the change and triggers a rolling restart of the backend and worker pods to inject the updated configuration as environment variables. Brief pod cycling occurs during this process.

Results

Verify that the backend pod has the OTEL environment variables set:

$ oc exec -n namespace deployment/cr-name-backend -c backend -- env | grep APP_OTEL

The output lists the APP_OTEL_* variables corresponding to your configuration.

OTLP configuration reference

Use the following field reference when configuring the .spec.otel block of the AutomationOrchestrator custom resource to enable OpenTelemetry Protocol (OTLP) forwarding.


Field	Type	Default	Description
`enabled`	Boolean	`false`	Enable OTLP forwarding. When`false`, audit events are written to pod standard output only.
`endpoint`	String	—	OTLP HTTP endpoint for logs. Use`https://` for external endpoints. Use`http://` only for localhost or cluster-internal`.svc` DNS addresses.
`serviceName`	String	Derived from product name	Optional. Service name reported in OpenTelemetry resource attributes. When omitted, automation orchestrator uses a value derived from the product name configuration. Set this field to`automation-orchestrator` to use a consistent, meaningful service name in your observability platform.
`authHeaderName`	String	—	Optional. HTTP header name used to send the API key. When omitted, the backend uses`Authorization`.
`apiKeySecretRef.name`	String	—	Name of the Secret containing the API key. The Secret must have a key named`api-key` with the bare token value. Automation orchestrator automatically prepends`Bearer` when sending the header.
`caCertSecretRef.name`	String	—	Name of the Secret containing the CA certificate for server verification. The Secret must have a key named`ca.crt`.
`clientCertSecretRef.name`	String	—	Name of the Secret containing the client certificate and private key for mutual TLS (mTLS). The Secret must be of type`kubernetes.io/tls` with keys`tls.crt` and`tls.key`.