Metrics service deployment requirements

Review infrastructure requirements and prerequisites for deploying metrics service to provision appropriate resources and ensure successful deployment without capacity or compatibility issues.

System requirements

Supported platforms

Platform Versions Notes
Red Hat Enterprise Linux 9.2 or later Required for containerized installer deployment.RHEL 8 is NOT supported (Ansible Automation Platform 2.7 requirement)
Podman 4.6.0 or later Container runtime for metrics service
PostgreSQL 15 or later Formetrics_service database andawx/automation controller database
Ansible Automation Platform 2.7.0 or later Metrics service integrated with Ansible Automation Platform 2.7 containerized installer
Important:

Metrics service does not support RHEL 8. All Ansible Automation Platform 2.7 deployments require RHEL 9.2 or later.

Data retention periods

Data Category Description Retention Period Cleanup Schedule
Hourly metrics Raw metrics collected hourly from controller 7 days Daily at 4:00-5:30 AM
Daily summaries Aggregated daily metrics 30 days Daily at 4:00-5:30 AM
Anonymized payloads Anonymized data sent to Red Hat Data Ingress 7 days (after successful transmission) / 30 days (unsent/pending transmission) Daily at 4:00-5:30 AM
Indirect node audit data

Daily collection of indirect node audit records linked to jobs that finished in the previous day (when FEATURE_INDIRECT_NODE_COLLECTION_ENABLED: true)

 7 days

Daily at 4:00-5:30 AM
Dashboard data Job execution data for dashboard reporting 90 days Daily at 5:30 AM
Note:

Cleanup tasks run automatically daily at 4:00 AM to enforce retention policies.

Note:
Dashboard data retention follows the automation controller retention period by default. To use an independent retention period for dashboard data, add the following to your inventory file: 

automationmetrics_extra_settings:
  - setting: DASHBOARD_COLLECTION__USE_CONTROLLER_RETENTION
    value: false

When DASHBOARD_COLLECTION__USE_CONTROLLER_RETENTION is set to false, the dashboard uses its own retention_period_days value (default: 90 days) instead of the controller retention period.

Warning:

When dashboard retention syncs with the controller setting (DASHBOARD_COLLECTION__USE_CONTROLLER_RETENTION: True, the default), any data in the metrics service database older than the controller retention period will be deleted. Verify your controller retention period before enabling dashboard collection. If the controller retention period is shorter than the dashboard's previous retention period (default: 90 days), enabling this sync will permanently delete dashboard data older than the controller retention period.

Collection task schedule

Metrics service runs automated collection tasks on the following schedule:

Task Group Task Schedule Feature Flag Description
METRICS_COLLECTION_GROUP collect_metrics Hourly (5 * * * *) METRICS_COLLECTION Collects automation activity data from controller
METRICS_COLLECTION_GROUP collect_hourly_metrics (main_jobevent_service) Hourly (20 * * * *) METRICS_COLLECTION Collects collection/module usage from job events
METRICS_COLLECTION_GROUP daily_anonymize_and_prepare Daily at 1:00 AM (0 1 * * *) ANONYMIZED_DATA_COLLECTION Anonymizes collected data and prepares payload for Red Hat
METRICS_COLLECTION_GROUP cleanup_metrics_data Daily at 4:00 AM (0 4 * * *) Always on Purges expired data per retention policies
INDIRECT_NODE_COLLECTION_GROUP daily_collect_indirect_nodes Daily at 1:55 AM UTC (55 1 * * *) FEATURE_INDIRECT_NODE_COLLECTION_ENABLED Collects indirect node audit data from controller

All tasks run in the automation-metrics-tasks container (containerized) or metrics-tasks pod (operator).

Hardware requirements

metrics service hardware requirements are the same as Gateway specifications:

Component Minimum Recommended Notes
CPU 2 vCPUs 4 vCPUs Dedicated to metrics service container
RAM 4 GB 8 GB For metrics processing and database operations
Storage (database) 20 GB 40 GB+ (SSD preferred) For metrics_service database; grows based on data retention
Storage (container) Included in database storage Included in database storage For container images and temporary processing
Network bandwidth Standard Ansible Automation Platform networking Standard Ansible Automation Platform networking For data transmission to Red Hat Data Ingress via Gateway
Note:

Metrics service can run on any node defined in the [automationmetrics] inventory group. Hardware requirements can be shared (AIO Growth topology) or dedicated (Enterprise Multi-Node topology).

Filesystem requirements

Path Purpose Minimum Size
/var/lib/containers Container images and storage 10 GB (part of overall storage)
{{ aap_volumes_dir }}/automationmetrics Host-side volume mount (maps to/var/lib/ansible-automation-platform/metrics inside container) 5 GB (part of overall storage)
/var/lib/postgresql (or custom path) PostgreSQL data directory for metrics_service database 20 GB minimum, 40 GB+ recommended

Network requirements

Connection Protocol Port Direction Purpose
metrics service → Controller database PostgreSQL 5432 (default) Outbound Read-only data collection
metrics service → metrics_service database PostgreSQL 5432 (default) Outbound Metrics storage and retrieval
metrics service → Gateway HTTPS 443 Outbound Anonymized data transmission to/api/metrics/ endpoint
Monitoring → metrics service (optional) HTTP 8087 Inbound Health check endpoint at/health/ via nginx

Proxy Support: metrics service supports HTTP/HTTPS proxy configuration via standard environment variables (HTTP_PROXY, HTTPS_PROXY, NO_PROXY).

Database requirements

Database User Privileges Purpose
metrics_service metrics_service ALL metrics service's own data storage, Django migrations, schema management
awx/automation controller ms_awx_readonly GRANT SELECT ON ALL TABLES IN SCHEMA public Read-only access to controller data for metrics collection

PostgreSQL Version: 15 or later (both databases)

Note:

The ms_awx_readonly user requires SELECT privileges on all tables in the public schema of the awx/automation controller database. This is configured automatically by the installer.

Feature flags

Metrics service behavior is controlled by the following feature flags:

Flag Default Level Restart Required Purpose
METRICS_COLLECTION true (enabled) Metrics service env var Yes Enables all metrics data collection from controller
ANONYMIZED_DATA_COLLECTION true (enabled) Database dynamic setting No Enables anonymization and transmission of data to Red Hat
FEATURE_INDIRECT_NODE_COLLECTION_ENABLED false (disabled) Gateway AAPFlag (platform-level) No Enables daily collection of indirect node audit data from controller

Feature flags resolve through the following priority chain (highest to lowest):

  1. DB Setting (dynamic_settings table)
  2. Dynaconf / environment variable
  3. Direct settings attribute
  4. DAB AAPFlag (Gateway-level flags, including FEATURE_INDIRECT_NODE_COLLECTION_ENABLED)
  5. Default value

Data sources

Metrics service reads data from the following controller database tables using the ms_awx_readonly user:

Data Type Controller Table What Is Collected Feature Flag
Automation activity main_unifiedjob,main_job, related tables Job execution data, host counts, template metadata METRICS_COLLECTION
Indirect node audit main_indirectmanagednodeaudit Indirect node counts grouped by Ansible collection and module FEATURE_INDIRECT_NODE_COLLECTION_ENABLED
Job event data main_jobevent Collection, module, and role usage from job events METRICS_COLLECTION

Supporting and related tables

Collector Primary table Supporting tables Time filter
main_jobevent_service main_jobevent main_unifiedjob main_unifiedjob.finished
main_indirectmanagednodeaudit main_indirectmanagednodeaudit main_job,main_unifiedjob,main_inventory,main_organization,main_unifiedjobtemplate main_unifiedjob.finished

The main_indirectmanagednodeaudit table is a controller table, not created by metrics service. The ms_awx_readonly user's existing SELECT privileges cover this table. No additional database permissions are required.

Indirect node data handling:

  • Host names and organization names are stripped entirely from the payload before sending to Red Hat. Only aggregate host_count values grouped by Ansible collection and module are included.
  • Indirect node counts are tagged as managed_node_type = INDIRECT in the anonymized payload.
  • Metrics service does not collect full host inventory data. Full host inventory collection is handled separately by the metrics-utility CLI for CCSP reports.

Performance impact and capacity planning

Validated performance characteristics

Metrics service is designed for minimal impact on automation controller operations:

Metric Measured Impact Notes
Controller performance impact <5% Peak impact during hourly collection (XX:05, XX:10, XX:15)
Peak memory usage 300-500 MB During active collection with chunked processing
Local storage usage <1 GB per cycle Includes hourly, daily, and anonymized data before cleanup
Database query performance Read-only access No write impact on controller database
Network bandwidth Minimal Anonymized payloads transmitted daily (varies by environment size)

Collection strategy:

  • Hourly micro-batches with chunked processing (1000 rows per batch)
  • Read-only database access prevents controller impact
  • Scheduled during low-usage periods (1:00 AM - 5:00 AM for daily tasks)

Data retention (local to metrics service database)

Data Category Retention Period Storage Impact
Hourly collection data 7 days Primary storage consumer
Daily summaries 30 days Aggregated, smaller than hourly
Anonymized payloads 7 days Compressed before transmission
Dashboard report data 90 days (when dashboard enabled) Largest storage consumer if dashboard enabled

All data is purged automatically by cleanup_metrics_data task (daily at 4:00 AM).

Capacity planning guidelines

When to scale metrics service resources

Note:
Metrics service is deployed as a single instance on one node. Scale vertically by increasing CPU, RAM, or storage on that node. Multi-node or horizontal scaling is not supported.
Condition Recommended Action
Hourly collection duration exceeds 10 minutes Add 2 vCPUs or optimize database queries
Memory usage sustained above 80% (>6.4 GB of 8 GB) Add 4 GB RAM
Database size exceeds 10 GB Increase storage OR reduce retention periods
Task execution failures increase Check database performance, verify network connectivity

Storage growth estimates (without dashboard):

  • Small environment (1000 jobs/day): ~50-100 MB/day
  • Medium environment (5000 jobs/day): ~200-300 MB/day
  • Large environment (20,000 jobs/day): ~500-800 MB/day

Storage growth with dashboard enabled (90-day retention):

  • Multiply above estimates by 3-4x due to additional dashboard data collection

Disconnected environments

Metrics service handles disconnected environments gracefully:

If Segment.com is unreachable:

  • Service retries transmission 3 times per scheduled run
  • Logs failure and waits for next cycle (no retry storms)
  • No impact on automation controller operations when disconnected
  • Local collection continues normally

When connectivity is restored:

  • Next scheduled anonymization/transmission cycle resumes
  • Only most recent anonymized payload is sent (older payloads are purged per retention policy)
  • No backlog buildup or resource exhaustion

Recommendation for disconnected environments: Disable ANONYMIZED_DATA_COLLECTION feature flag if permanent disconnection is expected. This prevents log noise from failed transmission attempts while allowing local collection to continue.