此内容没有您所选择的语言版本。
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 复制链接链接已复制到粘贴板!
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
Create two scripts in your user’s home directory to set correct variables to ensure that
metrics-utility
gathers all relevant data.In
/home/my-user/cron-gather
:Copy to Clipboard Copied! Toggle word wrap Toggle overflow In
/home/my-user/cron-report
:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
To ensure that these files are executable, run:
chmod a+x /home/my-user/cron-gather /home/my-user/cron-report
To open the cron file for editing, run:
crontab -e
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, thegather
command is configured to run every hour at 00 minutes. Thebuild_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
- Save and close the file.
Verification
Use the following verification steps to ensure correct configuration:
To confirm that your
cron
job entries have been saved correctly, run:crontab -l
crontab -l
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Inspect the
cron
log to verify that thecron
daemon is executing the commands and thatmetrics-utility
is producing output:cat /var/log/cron
cat /var/log/cron
Copy to Clipboard Copied! Toggle word wrap Toggle overflow For reference, see the following example output:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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.
Time and date might vary depending on how your configure the run schedule.
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.
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
- From the navigation panel, select .
- Click .
- On the next screen, select the YAML view tab.
In the YAML field, enter the following parameters with the appropriate variables set:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Click .
Verification
-
To verify that the ConfigMap was created and
metrics-utility
is installed, select ConfigMap from the navigation panel and search for your ConfigMap in the list.
12.1.2.2. Deploy automation controller 复制链接链接已复制到粘贴板!
To deploy automation controller and specify variables for how often metrics-utility
gathers usage information and generates a report, use the following procedure:
Procedure
- From the navigation panel, select Installed Operators.
- Select Ansible Automation Platform.
- In the Operator details, select the automation controller tab.
- Click .
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 Parameter Variable metrics_utility_enabled
True.
metrics_utility_cronjob_gather_schedule
@hourly
or@daily
.metrics_utility_cronjob_report_schedule
@daily
or@monthly
.-
Find the
metrics_utility_enabled
parameter and change the variable to true. -
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
). -
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
). - Click .
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:
Use the following steps to configure metrics-utility
on a manual containerized installation of Ansible Automation Platform:
- Prepare host directories and scripts.
- Make scripts executable.
- Configure cron jobs.
Prerequisites
- An active Ansible Automation Platform subscription
Minimum resource requirements
Using the metrics-utility tool on a containerized installation of Ansible Automation Platform requires the following resources:
CPU: 1 dedicated CPU core
- 100% of 1 core is used during execution
Memory:
- Minimum: 256 MB RAM (supports up to ~10,000 job host summaries)
- Recommended: 512 MB RAM (standard deployments)
Large-scale: 1 GB RAM (supports up to ~100,000 job host summaries)
NoteMemory requirements scale with the number of hosts and jobs being processed.
- Execution time: Report generation typically completes within 10-30 seconds, depending on data volume
12.1.3.1. Preparing host directories and scripts 复制链接链接已复制到粘贴板!
To prepare host directories and scripts, create two shell scripts on your host machine to execute metrics-utility
commands inside your running container.
Procedure
Modify your inventory file to enable metrics-utility container deployment by adding the following line under the [all:vars] section:
metrics_utility_enabled=true
metrics_utility_enabled=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow This setting instructs the installer to create and configure a dedicated
automation-controller-metrics-utility
container as part of your Ansible Automation Platform deployment. Be sure to place this line under the[all:vars]
header in your inventory file, alongside your other global variables. Re-run the installer script to activate the container if your Ansible Automation Platform deployment has already been configured.Run the following command to create the host report destination directory:
mkdir -p /home/my-user/aap/controller/data/
mkdir -p /home/my-user/aap/controller/data/
Copy to Clipboard Copied! Toggle word wrap Toggle overflow This directory on your host machine stores the final generated reports.
Create a file named
/home/my-user/cron-gather
(replace/home/my-user/
with your desired path) and add the following content to create thecron-gather
script:Copy to Clipboard Copied! Toggle word wrap Toggle overflow This script runs
metrics-utility
to gather billing data from your Ansible Automation Platform instance and store it temporarily inside the container.Create a file named
/home/my-user/cron-report
(replace/home/my-user/
with your desired path) and add the following content to create thecron-report
script:Copy to Clipboard Copied! Toggle word wrap Toggle overflow This script METRICS_UTILITY_REPORT_SKU_DESCRIPTION
metrics-utility
to build a report from the gathered data and then copy the final report from the container to your specified host directory.
12.1.3.2. Making the scripts executable 复制链接链接已复制到粘贴板!
Ensure that both scripts you created are executable by using the following procedure:
Procedure
Run the following command:
chmod a+x /home/my-user/cron-gather /home/my-user/cron-report
chmod a+x /home/my-user/cron-gather /home/my-user/cron-report
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteEnsure that you have replaced
/home/my-user/
with your actual path.
12.1.3.3. Configuring cron jobs 复制链接链接已复制到粘贴板!
Configure cron
to schedule the metrics-utility
commands to run automatically by using the following procedure:
Procedure
Open the
cron
file for editing:crontab -e
crontab -e
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Add the following lines to the end of the
crontab
file to addcron
schedule entries:0 */1 * * * /home/my-user/cron-gather 0 4 2 * * /home/my-user/cron-report
0 */1 * * * /home/my-user/cron-gather 0 4 2 * * /home/my-user/cron-report
Copy to Clipboard Copied! Toggle word wrap Toggle overflow These examples configure the
gather
command to run every hour at 00 minutes and thebuild_report
command to run on the second day of each month at 4:00 AM.Adjust the cron syntax as needed to fit your desired schedule. For example:
-
0 */1 * * *
: Runs at minute 0 of every hour. -
0 4 2 * *
: Runs at 04:00 on day-of-month 2.
-
- Save and close the file.
Verification
Use the following verification steps to ensure correct configuration:
To confirm that your
cron
job entries have been saved correctly, run:crontab -l
crontab -l
Copy to Clipboard Copied! Toggle word wrap Toggle overflow If your
cron
job entries have been saved correctly, you will see the two lines you added forcron-gather
andcron-report
.Inspect the
cron
log to check if thecron
daemon is executing the commands and ifmetrics-utility
is producing output:cat /var/log/cron
cat /var/log/cron
Copy to Clipboard Copied! Toggle word wrap Toggle overflow For reference, see the following example output:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Locate generated reports:
-
The generated report has a default name format of
CCSP-<YEAR>-<MONTH>.xlsx
(for example,CCSP-2024-07.xlsx
). The report is deposited in theMETRICS_UTILITY_SHIP_PATH
with the prefixed path you specified in Step 2 (for example,/home/my-user/aap/controller/data/metrics_utility/data
).
-
The generated report has a default name format of
12.2. Fetching a monthly report 复制链接链接已复制到粘贴板!
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.
Procedure
Use the following playbook to fetch a monthly consumption report for Ansible Automation Platform on OpenShift Container Platform:
NoteTo use this playbook, you must have the
kubernetes.core.k8s
collection to be installed on your machine.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.3. Modifying the run schedule 复制链接链接已复制到粘贴板!
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
From the command line, run:
crontab -e
After the code editor has opened, update the
gather
andbuild
parameters using cron syntax as shown below:*/2 * * * * metrics-utility gather_automation_controller_billing_data --ship --until=10m
*/5 * * * * metrics-utility build_report
- 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
-
From the navigation panel, select
. - On the next screen, select automation-controller-operator-controller-manager.
- 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.
- From the navigation panel, select Installed Operators.
- From the list of installed operators, select Ansible Automation Platform.
- On the next screen, select the automation controller tab.
- From the list that appears, select your automation controller instance.
-
On the next screen, select the
YAML
tab. In the
YAML
file, find the following parameters and enter a variable representing how oftenmetrics-utility
should gather data and how often it should produce a report:metrics_utility_cronjob_gather_schedule:
metrics_utility_cronjob_report_schedule:
- Click .
- From the navigation menu, select automation-controller-operator-controller-manager. and then select
- Increase the number of pods to 1.
To verify that you have changed the
metrics-utility
running schedule successfully, you can take one or both of the following steps:-
Return to the
YAML
file and ensure that the previously described parameters reflect the correct variables. -
From the navigation menu, select
and ensure that your cronjobs show the updated schedule.
-
Return to the
12.4. Supported storage 复制链接链接已复制到粘贴板!
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 复制链接链接已复制到粘贴板!
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 Your path on the local disk
# 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/...
12.4.2. Object storage with S3 interface 复制链接链接已复制到粘贴板!
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.
12.5. Report types 复制链接链接已复制到粘贴板!
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 复制链接链接已复制到粘贴板!
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 复制链接链接已复制到粘贴板!
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.
-
If present by default, this incrementally collects data from the
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.
-
This collects daily snapshots of the
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.
-
This incrementally collects data from the
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
# Example with all optional collectors export METRICS_UTILITY_OPTIONAL_COLLECTORS="main_host,main_jobevent,main_indirectmanagednodeaudit"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.5.3. Optional sheets for build_report command 复制链接链接已复制到粘贴板!
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:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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.
infrastructure_summary
This additional tab summarizes the infrastructure taxonomy for indirect nodes in three levels:
- Infrastructure
- Device category
- Device type
Taxonomy mapping is dependent on the facts column in the raw data.
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,
data_collection_status
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
# 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 Copied! Toggle word wrap Toggle overflow
-
This generates a sheet with the status of every data collection done by the
12.5.4. Filtering reports by organization 复制链接链接已复制到粘贴板!
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
12.5.5. Selecting a date range for your CCSPv2 report 复制链接链接已复制到粘贴板!
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:
12.5.6. RENEWAL_GUIDANCE 复制链接链接已复制到粘贴板!
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
.
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 复制链接链接已复制到粘贴板!
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
.
12.5.6.2. Showing ephemeral usage 复制链接链接已复制到粘贴板!
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 ephemeral nodes being nodes automated for less than 1 month.
# Will generate report for 12 months back with ephemeral nodes being nodes
# automated for less than 1 month.
metrics-utility build_report --since=12months --ephemeral=1month
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:
12.5.7. CCSP 复制链接链接已复制到粘贴板!
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 复制链接链接已复制到粘贴板!
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.
-
If present by default, this incrementally collects the
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,
-
This collects daily snapshots of the
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.
-
This incrementally collects the
main_indirectmanagednodeaudit
-
This incrementally collects the
main_indirectmanagednodeaudit
table from the automation controller database and contains information about indirectly managed nodes,
-
This incrementally collects the
Example with all optional collectors
# Example with all optional collectors
export METRICS_UTILITY_OPTIONAL_COLLECTORS="main_host,main_jobevent,main_indirectmanagednodeaudit"
12.5.9. Optional sheets for build_report command 复制链接链接已复制到粘贴板!
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:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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 controller job runs.
Example with all optional sheets
# 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'
12.5.10. Selecting a date range for your CCSP report 复制链接链接已复制到粘贴板!
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:
12.6. Deduplication of hosts for metrics-utility reports 复制链接链接已复制到粘贴板!
Deduplication changes how metrics-utility
merges individual host records into countable managed nodes when building reports. Deduplication identifies identical hosts to ensure an accurate count of unique hosts.
metrics-utility
tracks individual hosts based on their hostnames. Any entries that use the same hostname are tracked as the same host. Additional deduplication strategies are also available using the following environment variable: METRICS_UTILITY_DEDUPLICATOR=
.
12.6.1. Deduplication in the RENEWAL_GUIDANCE report 复制链接链接已复制到粘贴板!
The default value for METRICS_UTILITY_DEDUPLICATOR=renewal
. This is the original method, which analyzes host_name
, ansible_host
, ansible_product_serial
, and ansible_machine_id
separately, and merges entries when any of these items are duplicated.
METRICS_UTILITY_DEDUPLICATOR=renewal
applies deduplication in multiple iterations. It is limited by the REPORT_RENEWAL_GUIDANCE_DEDUP_ITERATIONS
environment variable, which defaults to 3
.
You can also run METRICS_UTILITY_DEDUPLICATOR
with the following environment variables:
-
METRICS_UTILITY_DEDUPLICATOR=renewal-hostname
. This is similar toccsp
, again preferringansible_host
overhost_name
when present. No other fields are considered. -
METRICS_UTILITY_DEDUPLICATOR=renewal-experimental
. This is similar toccsp-experimental
, which first applies the hostname-based deduplication, then deduplicates again, merging when both of the serials match.
12.6.2. Deduplication in the CCSP or CCSPv2 reports 复制链接链接已复制到粘贴板!
The default value for METRICS_UTILITY_DEDUPLICATOR=ccsp
. This limits deduplication to hostnames only.
The ansible_host
variable, from main_host.variables
, is preferred over host_name
, from main_jobhostsummary
, when present.
You can also set METRICS_UTILITY_DEDUPLICATOR=ccsp-experimental
. This setting merges entries when both their ansible_product_serial
and ansible_machine_id
facts are present and duplicated.