Understand automation orchestrator observability
Automation orchestrator provides three independent observability systems so you can monitor platform health, review system activity, and support Red Hat product improvement. You do not need to configure telemetry collection. It is enabled by default, and all three systems operate independently.
Telemetry data collection in automation orchestrator is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product capabilities, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope in the Additional resources section.
Three observability systems
- Prometheus metrics
-
You can scrape the local
/metricsendpoint with any Prometheus-compatible monitoring system to track request latency, error rates, and workflow execution performance. Prometheus metrics stay within your cluster and require no outbound network access. - Audit event logging
- Structured event logs that capture system actions for compliance and debugging. Audit events are always emitted to standard output for collection by your log aggregation infrastructure (for example, OpenShift logging, Splunk, or Elasticsearch). When you enable an OpenTelemetry (OTEL) collector endpoint, both audit events and application logs are exported to the collector for forwarding to external observability platforms.
- Analytics telemetry
- Anonymized usage data that automation orchestrator sends to Red Hat for product improvement. This telemetry pipeline operates separately from other Ansible Automation Platform components such as automation controller or automation hub, using different identifiers and transmission paths. No personally identifiable information (PII) is included in telemetry data.
Review what analytics telemetry data automation orchestrator collects
automation orchestrator collects the following categories of telemetry data:
| Category | What is collected | Purpose |
|---|---|---|
| Workflow lifecycle | Creation, modification, deletion, version creation, version restore, publish, unpublish, and export events | Track workflow adoption, design patterns, versioning, and publishing activity |
| Execution metrics | Step timing, success/failure rates, retry counts, timeout events | Identify bottlenecks and optimize performance |
| Approval events | Human-in-the-loop approval requests, decisions, and wait times | Measure approval turnaround and bottlenecks |
| API metrics | Endpoint response times, status codes, payload sizes, unique callers per period, and feature usage by endpoint | Monitor integration health and API adoption |
| User login | Authentication method, identity provider | Track authentication patterns |
| System health | Integration health checks, component availability, resource utilization | Operational monitoring |
| Credential usage | Credential counts, types, and workflow step references | Track credential adoption across workflows |
| Tool execution | Tool namespaced name, execution status, duration | Track tool adoption and performance |
| Large language model (LLM) token usage | Token consumption counts per streamed LLM response, model identifiers | Track AI-assisted feature costs and usage patterns |
API metrics and user login events are not collected by default. Automation orchestrator disables these events to reduce telemetry volume at scale.
All identifiers in telemetry data are anonymized. Workflow and step definitions are represented as SHA-256 hashes rather than the actual content.
Zero-configuration default behavior
You do not need to configure any settings, create any resources, or perform any manual steps to activate telemetry. Telemetry collection is enabled by default when automation orchestrator starts.
If your organization requires telemetry to be disabled, you can turn off analytics transmission through the runtime settings.
Telemetry does not affect platform operations
Telemetry operations never block or delay your workflows or API responses, even when they fail:
- If the telemetry endpoint is unreachable, events are retried and then dropped with no impact on platform operations.
- You do not need to configure firewall rules for telemetry.
- If outbound access is unavailable, automation orchestrator continues to function normally.
Disconnected environments
In disconnected or air-gapped environments, analytics telemetry cannot reach the external endpoint. Events are retried and then dropped when the endpoint remains unreachable, with no impact on platform operations.
Prometheus metrics and audit event logging continue to function normally in disconnected environments because they operate locally within the cluster.
Disconnected telemetry export is not available in this Technology Preview release.
Review data retention periods
| Location | Retention period |
|---|---|
| Standard output logs | Based on your log aggregation system configuration |
| External monitoring systems | Based on your monitoring system configuration |
| Red Hat telemetry | 90 days for aggregated metrics |