Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 12. Usage reporting with metrics-utility

The Ansible Automation Platform metrics utility tool (metrics-utility) is a command-line utility that is installed on a system containing an instance of automation controller.

When installed and configured, metrics-utility gathers billing-related metrics from your system and creates a consumption-based billing report. The metrics-utility tool is especially suited for users who have multiple managed hosts and want to use consumption-based billing. After a report is generated, it is deposited in a target location that you specify in the configuration file.

metrics-utility collects two types of data from your system: configuration data and reporting data.

The configuration data includes the following information:

  • Version information for automation controller and for the operating system
  • Subscription information
  • The base URL

The reporting data includes the following information:

  • Job name and ID
  • Host name
  • Inventory name
  • Organization name
  • Project name
  • Success or failure information
  • Report date and time

To ensure that metrics-utility continues to work as configured, clear your report directories of outdated reports regularly.

12.1. Configuring metrics-utility
Copy link

Configure the metrics-utility to gather and report usage data for your Ansible Automation Platform, both on Red Hat Enterprise Linux and OpenShift Container Platform.

Prerequisites:

  • An active Ansible Automation Platform subscription

Metrics-utility is included with Ansible Automation Platform, so you do not need a separate installation. The following procedure gathers the relevant data and generate a CCSP report containing your usage metrics. You can configure these commands as cronjobs to ensure they run at the beginning of every month. See How to schedule jobs using the Linux 'cron' utility for more on configuring using the cron syntax.

Procedure

  1. Create two scripts in your user’s home directory to set correct variables to ensure that metrics-utility gathers all relevant data.

    1. In /home/my-user/cron-gather: 

      #!/bin/sh

# Specify the following variables to indicate where the report is deposited in your file system
export METRICS_UTILITY_SHIP_TARGET=directory
export METRICS_UTILITY_SHIP_PATH=/awx_devel/awx-dev/metrics-utility/shipped_data/billing

# Run the following command to gather and store the data in the provided SHIP_PATH directory:
metrics-utility gather_automation_controller_billing_data --ship --until=10m
      Copy to Clipboard Toggle word wrap

    2. In /home/my-user/cron-report: 

      #!/bin/sh

# Specify the following variables to indicate where the report is deposited in your file system
export METRICS_UTILITY_SHIP_TARGET=directory
export METRICS_UTILITY_SHIP_PATH=/awx_devel/awx-dev/metrics-utility/shipped_data/billing

# Set these variables to generate a report:
export METRICS_UTILITY_REPORT_TYPE=CCSPv2
export METRICS_UTILITY_PRICE_PER_NODE=11.55 # in USD
export METRICS_UTILITY_REPORT_SKU=MCT3752MO
export METRICS_UTILITY_REPORT_SKU_DESCRIPTION="EX: Red Hat Ansible Automation Platform, Full Support (1 Managed Node, Dedicated, Monthly)"
export METRICS_UTILITY_REPORT_H1_HEADING="CCSP Reporting <Company>: ANSIBLE Consumption"
export METRICS_UTILITY_REPORT_COMPANY_NAME="Company Name"
export METRICS_UTILITY_REPORT_EMAIL="email@email.com"
export METRICS_UTILITY_REPORT_RHN_LOGIN="test_login"
export METRICS_UTILITY_REPORT_COMPANY_BUSINESS_LEADER="BUSINESS LEADER"
export METRICS_UTILITY_REPORT_COMPANY_PROCUREMENT_LEADER="PROCUREMENT LEADER"

# Build the report
metrics-utility build_report
      Copy to Clipboard Toggle word wrap

  2. To ensure that these files are executable, run:

    chmod a+x /home/my-user/cron-gather /home/my-user/cron-report

  3. To open the cron file for editing, run:

    crontab -e

  4. To configure the run schedule, add the following parameters to the end of the file and specify how often you want metrics-utility to gather information and build a report using cron syntax. In the following example, the gather command is configured to run every hour at 00 minutes. The build_report command is configured to run on the second day of each month at 4:00 AM.

    0 */1 * * * /home/my-user/cron-gather

    0 4 2 * * /home/my-user/cron-report

  5. Save and close the file.

  6. To verify that you saved your changes, run:

    crontab -l

  7. To ensure that data is being collected, run:

    cat /var/log/cron

    The following is a typical output. Note that time and date might vary depending on how your configure the run schedule: 

    May  8 09:45:03 ip-10-0-6-23 CROND[51623]: (root) CMDOUT (No billing data for month: 2024-04)
May  8 09:45:03 ip-10-0-6-23 CROND[51623]: (root) CMDEND (metrics-utility build_report)
May  8 09:45:19 ip-10-0-6-23 crontab[51619]: (root) END EDIT (root)
May  8 09:45:34 ip-10-0-6-23 crontab[51659]: (root) BEGIN EDIT (root)
May  8 09:46:01 ip-10-0-6-23 CROND[51688]: (root) CMD (metrics-utility gather_automation_controller_billing_data --ship --until=10m)
May  8 09:46:03 ip-10-0-6-23 CROND[51669]: (root) CMDOUT (/tmp/9e3f86ee-c92e-4b05-8217-72c496e6ffd9-2024-05-08-093402+0000-2024-05-08-093602+0000-0.tar.gz)
May  8 09:46:03 ip-10-0-6-23 CROND[51669]: (root) CMDEND (metrics-utility gather_automation_controller_billing_data --ship --until=10m)
May  8 09:46:26 ip-10-0-6-23 crontab[51659]: (root) END EDIT (root)
    Copy to Clipboard Toggle word wrap

    The generated report will have the default name CCSP-<YEAR>-<MONTH>.xlsx and is saved in the ship path that you specified in step 1a.

metrics-utility is included in the OpenShift Container Platform image beginning with version 4.12, 4.512, and 4.6. If your system does not have metrics-utility installed, update your OpenShift image to the latest version.

Complete the following steps to configure the run schedule for metrics-utility on OpenShift Container Platform using the Ansible Automation Platform operator:

To inject the metrics-utility cronjobs with configuration data, use the following procedure to create a ConfigMap in the OpenShift UI YAML view:

Prerequisites:

  • A running OpenShift cluster
  • An operator-based installation of Ansible Automation Platform on OpenShift Container Platform.
Note

metrics-utility runs as indicated by the parameters you set in the configuration file. You cannot run the utility manually on OpenShift Container Platform.

Procedure

  1. From the navigation panel, select ConfigMaps.
  2. Click Create ConfigMap.
  3. On the next screen, select the YAML view tab.

  4. In the YAML field, enter the following parameters with the appropriate variables set: 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: automationcontroller-metrics-utility-configmap
data:
  METRICS_UTILITY_SHIP_TARGET: directory
  METRICS_UTILITY_SHIP_PATH: /metrics-utility
  METRICS_UTILITY_REPORT_TYPE: CCSP
  METRICS_UTILITY_PRICE_PER_NODE: '11' # in USD
  METRICS_UTILITY_REPORT_SKU: MCT3752MO
  METRICS_UTILITY_REPORT_SKU_DESCRIPTION: "EX: Red Hat Ansible Automation Platform, Full Support (1 Managed Node, Dedicated, Monthly)"
  METRICS_UTILITY_REPORT_H1_HEADING: "CCSP Reporting <Company>: ANSIBLE Consumption"
  METRICS_UTILITY_REPORT_COMPANY_NAME: "Company Name"
  METRICS_UTILITY_REPORT_EMAIL: "email@email.com"
  METRICS_UTILITY_REPORT_RHN_LOGIN: "test_login"
  METRICS_UTILITY_REPORT_COMPANY_BUSINESS_LEADER: "BUSINESS LEADER"
  METRICS_UTILITY_REPORT_COMPANY_PROCUREMENT_LEADER: "PROCUREMENT LEADER"
    Copy to Clipboard Toggle word wrap
  5. Click Create.

Verification

  • To verify that you created the ConfigMap and metrics-utility is installed, select ConfigMap from the navigation panel and look for your ConfigMap in the list.

12.1.2.2. Deploy automation controller
Copy link

To deploy automation controller and specify variables for how often metrics-utility gathers usage information and generates a report, use the following procedure:

Procedure

  1. From the navigation panel, select Installed Operators.
  2. Select Ansible Automation Platform.
  3. In the Operator details, select the automation controller tab.
  4. Click Create automation controller.

  5. Select the YAML view option. The YAML now shows the default parameters for automation controller. The relevant parameters for metrics-utility are the following:

    Expand
    ParameterVariable

    metrics_utility_enabled

    True.

    metrics_utility_cronjob_gather_schedule

    @hourly or @daily.

    metrics_utility_cronjob_report_schedule

    @daily or @monthly.

  6. Find the metrics_utility_enabled parameter and change the variable to true.
  7. Find the metrics_utility_cronjob_gather_schedule parameter and enter a variable for how often the utility should gather usage information (for example, @hourly or @daily).
  8. Find the metrics_utility_cronjob_report_schedule parameter and enter a variable for how often the utility generates a report (for example, @daily or @monthly).
  9. Click Create.

12.2. Fetching a monthly report
Copy link

Fetch a monthly report from Ansible Automation Platform to gather usage metrics and create a consumption-based billing report. To fetch a monthly report on Red Hat Enterprise Linux or on OpenShift Container Platform, use the following procedures:

Use the following procedure to fetch a monthly report on Red Hat Enterprise Linux:

Procedure

  • Run: scp -r username@controller_host:$METRICS_UTILITY_SHIP_PATH/data/<YYYY>/<MM>/ /local/directory/

The system saves the generated report as CCSP-<YEAR>-<MONTH>.xlsx in the ship path that you specified.

Use the following playbook to fetch a monthly consumption report for Ansible Automation Platform on OpenShift Container Platform: 

- name: Copy directory from Kubernetes PVC to local machine
  hosts: localhost

  vars:
    report_dir_path: "/mnt/metrics/reports/{{ year }}/{{ month }}/"

  tasks:
    - name: Create a temporary pod to access PVC data
      kubernetes.core.k8s:
        definition:
          apiVersion: v1
          kind: Pod
          metadata:
            name: temp-pod
            namespace: "{{ namespace_name }}"
          spec:
            containers:
            - name: busybox
              image: busybox
              command: ["/bin/sh"]
              args: ["-c", "sleep 3600"]  # Keeps the container alive for 1 hour
              volumeMounts:
              - name: "{{ pvc }}"
                mountPath: "/mnt/metrics"
            volumes:
            - name: "{{ pvc }}"
              persistentVolumeClaim:
                claimName: automationcontroller-metrics-utility
            restartPolicy: Never
      register: pod_creation

    - name: Wait for both initContainer and main container to be ready
      kubernetes.core.k8s_info:
        kind: Pod
        namespace: "{{ namespace_name }}"
        name: temp-pod
      register: pod_status
      until: >
        pod_status.resources[0].status.containerStatuses[0].ready
      retries: 30
      delay: 10

    - name: Create a tarball of the directory of the report in the container
      kubernetes.core.k8s_exec:
        namespace: "{{ namespace_name }}"
        pod: temp-pod
        container: busybox
        command: tar czf /tmp/metrics.tar.gz -C "{{ report_dir_path }}" .
      register: tarball_creation

    - name: Copy the report tarball from the container to the local machine
      kubernetes.core.k8s_cp:
        namespace: "{{ namespace_name }}"
        pod: temp-pod
        container: busybox
        state: from_pod
        remote_path: /tmp/metrics.tar.gz
        local_path: "{{ local_dir }}/metrics.tar.gz"
      when: tarball_creation is succeeded

    - name: Ensure the local directory exists
      ansible.builtin.file:
        path: "{{ local_dir }}"
        state: directory

    - name: Extract the report tarball on the local machine
      ansible.builtin.unarchive:
        src: "{{ local_dir }}/metrics.tar.gz"
        dest: "{{ local_dir }}"
        remote_src: yes
        extra_opts: "--strip-components=1"
      when: tarball_creation is succeeded

    - name: Delete the temporary pod
      kubernetes.core.k8s:
        api_version: v1
        kind: Pod
        namespace: "{{ namespace_name }}"
        name: temp-pod
        state: absent
Copy to Clipboard Toggle word wrap

12.3. Modifying the run schedule
Copy link

You can configure metrics-utility to run at specified times and intervals. Run frequency is expressed in cronjobs. For more information on the cron utility, see How to schedule jobs using the Linux ‘Cron’ utility.

To modify the run schedule on Red Hat Enterprise Linux and on OpenShift Container Platform, use one of the following procedures:

Procedure

  1. From the command line, run:

    crontab -e

  2. After the code editor has opened, update the gather and build parameters using cron syntax as shown below:

    */2 * * * * metrics-utility gather_automation_controller_billing_data --ship --until=10m

    */5 * * * * metrics-utility build_report

  3. Save and close the file.

To adjust the execution schedule of the metrics-utility within your Ansible Automation Platform deployment running on OpenShift Container Platform, use the following procedure:

Procedure

  1. From the navigation panel, select Workloads Deployments.
  2. On the next screen, select automation-controller-operator-controller-manager.
  3. Beneath the heading Deployment Details, click the down arrow button to change the number of pods to zero. This pauses the deployment so you can update the running schedule.
  4. From the navigation panel, select Installed Operators.
  5. From the list of installed operators, select Ansible Automation Platform.
  6. On the next screen, select the automation controller tab.
  7. From the list that appears, select your automation controller instance.
  8. On the next screen, select the YAML tab.

  9. In the YAML file, find the following parameters and enter a variable representing how often metrics-utility should gather data and how often it should produce a report:

    metrics_utility_cronjob_gather_schedule:

    metrics_utility_cronjob_report_schedule:

  10. Click Save.
  11. From the navigation menu, select Deployments and then select automation-controller-operator-controller-manager.
  12. Increase the number of pods to 1.

  13. To verify that you have changed the metrics-utility running schedule successfully, you can take one or both of the following steps:

    1. Return to the YAML file and ensure that the previously described parameters reflect the correct variables.
    2. From the navigation menu, select Workloads Cronjobs and ensure that your cronjobs show the updated schedule.

12.4. Supported storage
Copy link

Supported storage is available for storing the raw data obtained by using the metrics-utility gather_automation_controller_billing_data command and storing the generated reports obtained by using the metrics-utility build_report command. Apply the environment variables to this storage based on your Ansible Automation Platform installation.

12.4.1. Local disk
Copy link

For an installation of Ansible Automation Platform on Red Hat Enterprise Linux, the default storage option is a local disk. Using an OpenShift deployment of OpenShift Container Platform, default storage is a path inside the attached Persistent Volume Claim.

+ 

# Set needed ENV VARs for gathering data and generating reports
export METRICS_UTILITY_SHIP_TARGET=directory
# Your path on the local disk
export METRICS_UTILITY_SHIP_PATH=/path_to_data_and_reports/...
Copy to Clipboard Toggle word wrap

12.4.2. Object storage with S3 interface
Copy link

To use object storage with S3 interface, for example, with AWS S3, Ceph Object storage, or Minio, you must define environment variables for data gathering and report building commands and cronjobs.

+ 

################
export METRICS_UTILITY_SHIP_TARGET=s3
# Your path in the object storage
export METRICS_UTILITY_SHIP_PATH=path_to_data_and_reports/...

################
# Define S3 config
export METRICS_UTILITY_BUCKET_NAME=metricsutilitys3
export METRICS_UTILITY_BUCKET_ENDPOINT="https://s3.us-east-1.amazonaws.com"
# For AWS S3, define also a region
export METRICS_UTILITY_BUCKET_REGION="us-east-1"

################
# Define S3 credentials
export METRICS_UTILITY_BUCKET_ACCESS_KEY=<access_key>
export METRICS_UTILITY_BUCKET_SECRET_KEY=<secret_key>
Copy to Clipboard Toggle word wrap

12.5. Report types
Copy link

This section provides additional configurations for data gathering and report building based on a report type. Apply the environment variables to each report type based on your Ansible Automation Platform installation.

12.5.1. CCSPv2
Copy link

CCSPv2 is a report which shows the following:

  • Directly and indirectly managed node usage
  • The content of all inventories
  • Content usage

The primary use of this report is for partners under the CCSP program, but all customers can use it to obtain on-premise reporting showing managed nodes, jobs and content usage across their automation controller organizations.

Set the report type using METRICS_UTILITY_REPORT_TYPE=CCSPv2.

12.5.2. Optional collectors for gather command
Copy link

You can use the following optional collectors for the gather command:

  • main_jobhostsummary

    • If present by default, this incrementally collects data from the main_jobhostsummary table in the automation controller database, containing information about jobs runs and managed nodes automated.

  • main_host

    • This collects daily snapshots of the main_host table in the automation controller database and has managed nodes and hosts present across automation controller inventories.

  • main_jobevent

    • This incrementally collects data from the main_jobevent table in the automation controller database and contains information about which modules, roles, and Ansible collections are being used.

  • main_indirectmanagednodeaudit

    • This incrementally collects data from the main_indirectmanagednodeaudit table in the automation controller database and contains information about indirectly managed nodes. 

      # Example with all optional collectors
export METRICS_UTILITY_OPTIONAL_COLLECTORS="main_host,main_jobevent,main_indirectmanagednodeaudit"
      Copy to Clipboard Toggle word wrap

12.5.3. Optional sheets for build_report command
Copy link

You can use the following optional sheets for the build_report command:

  • ccsp_summary

    • This is a landing page specifically for partners under CCSP program. This report takes additional parameters to customize the summary page. For more information, see the following example: 

      export METRICS_UTILITY_PRICE_PER_NODE=11.55 # in USD
export METRICS_UTILITY_REPORT_SKU=MCT3752MO
export METRICS_UTILITY_REPORT_SKU_DESCRIPTION="EX: Red Hat Ansible Automation Platform, Full Support (1 Managed Node, Dedicated, Monthly)"
export METRICS_UTILITY_REPORT_H1_HEADING="CCSP NA Direct Reporting Template"
export METRICS_UTILITY_REPORT_COMPANY_NAME="Partner A"
export METRICS_UTILITY_REPORT_EMAIL="email@email.com"
export METRICS_UTILITY_REPORT_RHN_LOGIN="test_login"
export METRICS_UTILITY_REPORT_PO_NUMBER="123"
export METRICS_UTILITY_REPORT_END_USER_COMPANY_NAME="Customer A"
export METRICS_UTILITY_REPORT_END_USER_CITY="Springfield"
export METRICS_UTILITY_REPORT_END_USER_STATE="TX"
export METRICS_UTILITY_REPORT_END_USER_COUNTRY="US"
      Copy to Clipboard Toggle word wrap

  • jobs

    • This is a list of automation controller jobs launched. It is grouped by job template.

  • managed_nodes

    • This is a deduplicated list of managed nodes automated by automation controller.

  • indirectly_managed_nodes

    • This is a deduplicated list of indirect managed nodes automated by automation controller.

  • inventory_scope

    • This is a deduplicated list of managed nodes present across all inventories of automation controller.

  • usage_by_organizations

    • This is a list of all automation controller organizations with several metrics showing the organizations usage. This provides data suitable for doing internal chargeback.

  • usage_by_collections

    • This is a list of Ansible collections used in a automation controller job runs.

  • usage_by_roles

    • This is a list of roles used in automation controller job runs.

  • usage_by_modules

    • This is a list of modules used in automation controller job runs.

  • managed_nodes_by_organization

    • This generates a sheet per organization, listing managed nodes for every organization with the same content as the managed_nodes sheet.

  • data_collection_status

    • This generates a sheet with the status of every data collection done by the gather command for the date range the report is built for.

To outline the quality of data collected it also lists:

  • unusual gaps between collections (based on collection_start_timestamp)

  • gaps in collected intervals (based on since vs until) 

    # Example with all optional sheets
export METRICS_UTILITY_OPTIONAL_CCSP_REPORT_SHEETS='ccsp_summary,jobs,managed_nodes,indirectly_managed_nodes,inventory_scope,usage_by_organizations,usage_by_collections,usage_by_roles,usage_by_modules,data_collection_status'
    Copy to Clipboard Toggle word wrap

12.5.4. Filtering reports by organization
Copy link

To filter your report so that only certain organizations are present, use this environment variable with a semicolon separated list of organization names.

export METRICS_UTILITY_ORGANIZATION_FILTER="ACME;Organization 1"

This renders only the data from these organizations in the built report. This filter currently does not have any effect on the following optional sheets:

  • usage_by_collections
  • usage_by_roles
  • usage_by_modules

The default behavior of the CCSPv2 report is to build a report for the previous month. The following examples describe how to override this default behavior to select a specific date range for your report: 

# Build report for a specific month
metrics-utility build_report --month=2025-03

# Build report for a specific date range, icluding the prvided days
metrics-utility build_report --since=2025-03-01 --until=2025-03-31

# Build report for a last 6 months from a current date
metrics-utility build_report --since=6months

# Build report for a last 6 months from a current date overriding an exisitng report
metrics-utility build_report --since=6months --force
Copy to Clipboard Toggle word wrap

12.5.6. RENEWAL_GUIDANCE
Copy link

The RENEWAL_GUIDANCE report provides historical usage from the HostMetric table, applying deduplication and showing real historical usage for renewal guidance purposes.

To generate this report, set the report type to METRICS_UTILITY_REPORT_TYPE=RENEWAL_GUIDANCE.

Important

This report is currently a tech preview solution. It is designed to provide more information than automation controller when built in the awx-manage host_metric command.

12.5.6.1. Storage and invocation
Copy link

The RENEWAL_GUIDANCE report supports the use of only local disk storage to store the report results. This report does not have a gather data step. It reads directly from the controller HostMetric table, so it does not store any raw data under the METRICS_UTILITY_SHIP_PATH. 

# All parameters the RENEWAL_GUIDANCE report needs
export METRICS_UTILITY_SHIP_TARGET=controller_db
export METRICS_UTILITY_REPORT_TYPE=RENEWAL_GUIDANCE
export METRICS_UTILITY_SHIP_PATH=/path_to_built_report/...

# Will generate report for 12 months back with epehemeral nodes being nodes
# automated for less than 1 month.
metrics-utility build_report --since=12months --ephemeral=1month
Copy to Clipboard Toggle word wrap

12.5.6.2. Showing ephemeral usage
Copy link

The RENEWAL_GUIDANCE report has the capability to list additional sheets with ephemeral usage if the –ephemeral parameter is provided. Using the parameter --ephemeral=1month, you can define ephemeral nodes as any managed node that has been automated for a maximum of one month, then never automated again. Using this parameter, the total ephemeral usage of the 12-month period is computed as maximum ephemeral nodes used over all 1-month rolling date windows. This sheet is also added into the report. 

# Will generate report for 12 months back with epehemeral nodes being nodes
# automated for less than 1 month.
metrics-utility build_report --since=12months --ephemeral=1month
Copy to Clipboard Toggle word wrap

The RENEWAL_GUIDANCE report requires a since parameter as the parameter is not supported due to the nature of the HostMetric data and is always set to now. To override a report date range that has already been built, use parameter –force with the command. For more information, see the following examples: 

# Build report for a specific date range, including the provided days
metrics-utility build_report --since=2025-03-01

# Build report for a last 12 months from a current date
metrics-utility build_report --since=12months

# Build report for a last 12 months from a current date overriding an existing report
metrics-utility build_report --since=12months --force
Copy to Clipboard Toggle word wrap

12.5.7. CCSP
Copy link

CCSP is the original report format. It does not include many of the customization of CCSPv2, and it is intended to be used only for the CCSP partner program.

12.5.8. Optional collectors for gather command
Copy link

You can use the following optional collectors for the gather command:

  • main_jobhostsummary

    • If present by default, this incrementally collects the main_jobhostsummary table from the automation controller database, containing information about jobs runs and managed nodes automated.

  • main_host

    • This collects daily snapshots of the main_host table from the automation controller database and has managed nodes/hosts present across automation controller inventories,

  • main_jobevent

    • This incrementally collects the main_jobevent table from the automation controller database and contains information about which modules, roles, and ansible collections are being used.

  • main_indirectmanagednodeaudit

    • This incrementally collects the main_indirectmanagednodeaudit table from the automation controller database and contains information about indirectly managed nodes, 
# Example with all optional collectors
export METRICS_UTILITY_OPTIONAL_COLLECTORS="main_host,main_jobevent,main_indirectmanagednodeaudit"
Copy to Clipboard Toggle word wrap

12.5.9. Optional sheets for build_report command
Copy link

You may use the following optional sheets for the build_report command:

  • ccsp_summary

    • This is a landing page specifically for partners under the CCSP program. It shows managed node usage by each automation controller organization.

    • This report takes additional parameters to customize the summary page. For more information, see the following example: 

      export METRICS_UTILITY_PRICE_PER_NODE=11.55 # in USD
export METRICS_UTILITY_REPORT_SKU=MCT3752MO
export METRICS_UTILITY_REPORT_SKU_DESCRIPTION="EX: Red Hat Ansible Automation Platform, Full Support (1 Managed Node, Dedicated, Monthly)"
export METRICS_UTILITY_REPORT_H1_HEADING="CCSP Reporting <Company>: ANSIBLE Consumption"
export METRICS_UTILITY_REPORT_COMPANY_NAME="Company Name"
export METRICS_UTILITY_REPORT_EMAIL="email@email.com"
export METRICS_UTILITY_REPORT_RHN_LOGIN="test_login"
export METRICS_UTILITY_REPORT_COMPANY_BUSINESS_LEADER="BUSINESS LEADER"
export METRICS_UTILITY_REPORT_COMPANY_PROCUREMENT_LEADER="PROCUREMENT LEADER"
      Copy to Clipboard Toggle word wrap

  • managed_nodes

    • This is a deduplicated list of managed nodes automated by automation controller.

  • indirectly_managed_nodes

    • This is a deduplicated list of indirect managed nodes automated by automation controller.

  • inventory_scope

    • This is a deduplicated list of managed nodes present across all inventories of automation controller.

  • usage_by_collections

    • This is a list of Ansible collections used in automation controller job runs.

  • usage_by_roles

    • This is a list of roles used in automation controller job runs. *usage_by_modules
    • This is a list of modules used in automation controllerjob runs. 
# Example with all optional sheets
export METRICS_UTILITY_OPTIONAL_CCSP_REPORT_SHEETS='ccsp_summary,managed_nodes,indirectly_managed_nodes,inventory_scope,usage_by_collections,usage_by_roles,usage_by_modules'
Copy to Clipboard Toggle word wrap

The default behavior of this report is to build a report for the previous month. The following examples describe how to override this default behavior to select a specific date range for your report: 

# Builds report for a previous month
metrics-utility build_report

# Build report for a specific month
metrics-utility build_report --month=2025-03

# Build report for a specific month overriding an existing report
metrics-utility build_report --month=2025-03 --force
Copy to Clipboard Toggle word wrap
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat