Chapter 11. Download and review the results of completed scan reports
Maintain a unified inventory and create a complete picture of your subscription usage in connected or disconnected networks by downloading and sending scan reports to the Red Hat Hybrid Cloud Console.
11.1. Scan report types Copy linkLink copied to clipboard!
Reports for a scan are available in two formats, a comma-separated variable (CSV) format and a JavaScript Object Notation (JSON) format. They are also available in two content types, raw output from the scan as a details report and processed content as a deployments report.
A third type of report is available, the insights report, but this report can be generated only through the Discovery command line interface. Downloading the insights report provides a .tar.gz file that you can transfer to the Red Hat Hybrid Cloud Console at cloud.redhat.com. Transferring this file allows the report data to be used in the Red Hat Lightspeed Subscriptions Inventory and in Subscription Services.
11.2. Download reports locally Copy linkLink copied to clipboard!
From the Scans view, you can select one or more reports and download them to view the report data.
Prerequisites
- The most recent scan job for the scan that you want to download has completed successfully.
Procedure
- From the Scans view, navigate to the row of the scan for which you want to download the report.
- Click Download for that scan.
Verification
The downloaded report is saved to the downloads location for your browser as a .tar.gz file, for example, report_id_224_20190702_173309.tar.gz. The filename format is report_id_ID_DATE_TIME.tar.gz. In this format, ID is the unique report ID assigned by the server, DATE is the date in yyyymmdd format, and TIME is the time in hhmmss format based on the 24-hour system. The date and time data is determined by the interaction of the browser running the client with the server APIs.
To view the report, uncompress the .tar.gz file into a report_id_ID directory. The uncompressed report bundle includes five report files: two details reports in CSV and JSON formats, two deployments reports in CSV format, and one summary report in JSON format.
While you can view and use the output of these reports for your own internal processes, the Discovery documentation does not provide any information to help you interpret report results. Red Hat Support can provide some basic assistance related to the installation and use of Discovery. However, the support team does not provide assistance to help you understand the reports. The reports and their format are designed for use by the Red Hat Subscription Education and Awareness Program (SEAP) team during customer engagements. They are also used for other Red Hat internal processes, such as providing data to various Red Hat Hybrid Cloud Console services.
11.3. View scan summary reports in the graphical user interface Copy linkLink copied to clipboard!
After a scan job completes, you can view a summary of the scan results directly in the Discovery graphical user interface. This eliminates the need to download and extract report files manually, offering a more efficient way to assess key results.
Prerequisites
- The most recent scan job for the scan that you want to view has completed successfully.
Procedure
- In the Scans view, locate the row for a completed scan.
- Click More Options.
- Click Scan summary.
Verification
A window opens with summary data extracted from the summary report. The summary displays a subset of the full summary report, with selected fields organized into two columns:
- Results: Results include status counts and totals, such as success rate, failure rate, or instance type.
Diagnostics: Issues or missing data identified during inspection.
Each entry includes a human-readable label and the associated count. Fields are sorted alphabetically within each column.
A scan summary might include such information as:
- Managed Ansible nodes
- Failed or unreachable inspections
- Virtual or physical instances
- Missing system metadata
11.4. Report creation process Copy linkLink copied to clipboard!
The scan process discovers the systems in your IT infrastructure and inspects them to gather information about their nature and contents. It then creates a report from the information gathered during the inspection of each system.
A system is any entity that can be interrogated by the inspection tasks through an SSH connection, vCenter Server data, the Satellite Server API, or the Red Hat OpenShift cluster API. A system can be a physical or virtual machine, or it can be a different type of entity, such as a container or a cluster.
11.4.1. Facts and fingerprints Copy linkLink copied to clipboard!
During a scan, a collection of facts is gathered for each system in each source. A fact is a single piece of data about a system. Examples include the operating system version, the number of CPU cores, or a consumed entitlement for a Red Hat product.
Facts are processed to create a summarized set of data for each system, known as a fingerprint. A fingerprint is the set of facts that identifies a unique system and its characteristics. This includes the architecture, operating system, installed products and their versions, entitlements in use, and other attributes.
Fingerprinting data is generated when you run a scan job, but the data is used to create only one type of report. When you request a details report, you receive the raw facts for that scan without any fingerprinting. When you request a deployments report, you receive the fingerprinting data that includes the results from the deduplication, merging, and post-processing processes. These processes identify installed products and versions from the raw facts, find consumed entitlements, find and merge duplicate product instances from different sources, and locate products in nondefault locations.
11.4.2. System deduplication and system merging Copy linkLink copied to clipboard!
A single system can be found in multiple sources during a scan. For example, a virtual machine on vCenter Server could be running a Red Hat Enterprise Linux operating system installation that is also managed by Satellite. If you construct a scan that contains each type of source, vCenter, satellite, and network, that single system is reported by all three sources during the scan.
Currently, you cannot combine an OpenShift or Red Hat Ansible Automation Platform source with any other type of source in a scan. As a result, deduplication and merging processes do not apply for an OpenShift or Red Hat Ansible Automation Platform scan.
To resolve this issue and build an accurate fingerprint, Discovery feeds unprocessed system facts from the scan into a fingerprint engine. The fingerprint engine matches and merges data for systems that are found in more than one source by using the deduplication and merge processes.
The system deduplication process uses specific facts about a system to identify duplicate systems. The process moves through several phases, using these facts to combine duplicate systems in successively broader sets of data:
-
All systems from network sources are combined into a single network system set. Systems are considered to be duplicates if they have the same value for the
subscription_manager_idorbios_uuidfacts. -
All systems from vCenter sources are combined into a single vCenter system set. Systems are considered to be duplicates if they have the same value for the
vm_uuidfact. -
All systems from satellite sources are combined into a single satellite system set. Systems are considered to be duplicates if they have the same value for the
subscription_manager_idfact. -
The network system set is merged with the satellite system set to form a single network-satellite system set. Systems are considered to be duplicates if they have the same value for the
subscription_managerfact or matching MAC address values in themac_addressesfact. -
The network-satellite system set is merged with the vCenter system set to form the complete system set. Systems are considered duplicates if they have matching MAC addresses in the
mac_addressesfact. They are also duplicates if the vCentervm_uuidvalue matches the networkbios_uuidvalue.
11.4.3. System merging Copy linkLink copied to clipboard!
After the deduplication process determines that two systems are duplicates, the next step is to perform a merge of those two systems. The merged system has a union of system facts from each source. When a fact that appears in two systems is merged, the merge process uses the following order of precedence to merge that fact, from highest to lowest:
- network source fact
- satellite source fact
- vCenter source fact
A system fingerprint contains a metadata dictionary that captures the original source of each fact for that system.
11.4.4. System post-processing Copy linkLink copied to clipboard!
After deduplication and merging are complete, there is a post-processing phase that creates derived system facts. A derived system fact is a fact that is generated from the evaluation of more than one system fact. The majority of derived system facts are related to product identification data, such as the presence of a specific product and its version.
The following example shows how the derived system fact system_creation_date is created.
The system_creation_date fact is a derived system fact that contains the real system creation time. The value for this fact is determined by the evaluation of the following facts. The value for each fact is examined in the following order of precedence, based on accuracy of the match to the real system creation time. The highest non-empty value determines the system_creation_date fact value.
-
date_machine_id -
registration_time -
date_anaconda_log -
date_filesystem_create -
date_yum_history
11.4.5. Report creation Copy linkLink copied to clipboard!
After report data processing is complete, the report creation process builds two reports in two formats: JavaScript Object Notation (JSON) and comma-separated variable (CSV). The details report for each format contains the raw facts with no processing. The deployments report for each format contains the output after the raw facts have passed through the fingerprinting, deduplication, merge, and post-processing processes.
The report format is designed to be used by the Red Hat Subscription Education and Awareness Program (SEAP) team during customer engagements and for other Red Hat internal processes.
You can view and use the output of these reports for your own internal processes. However, the Discovery documentation does not provide information to help you interpret report results. Red Hat Support can provide basic assistance with the installation and use of Discovery, but does not provide assistance with understanding the reports. The reports and their format are designed for use by the Red Hat Subscription Education and Awareness Program (SEAP) team during customer engagements. They are also used for other Red Hat internal processes, such as providing data to various Red Hat Hybrid Cloud Console services.
11.4.6. A fingerprint example Copy linkLink copied to clipboard!
A fingerprint is a set of facts about a single system, including data about products, entitlements, sources, and metadata. The following example shows a partial fingerprint.
Example
{
"os_release": "Red Hat Enterprise Linux Atomic Host 7.4",
"cpu_count": 4,
"products": [
{
"name": "JBoss EAP",
"version": null,
"presence": "absent",
"metadata": {
"source_id": 5,
"source_name": "S62Source",
"source_type": "satellite",
"raw_fact_key": null
}
}
],
"entitlements": [
{
"name": "Satellite Tools 6.3",
"entitlement_id": 54,
"metadata": {
"source_id": 5,
"source_name": "S62Source",
"source_type": "satellite",
"raw_fact_key": "entitlements"
}
}
],
"metadata": {
"os_release": {
"source_id": 5,
"source_name": "S62Source",
"source_type": "satellite",
"raw_fact_key": "os_release"
},
"cpu_count": {
"source_id": 4,
"source_name": "NetworkSource",
"source_type": "network",
"raw_fact_key": "os_release"
}
},
"sources": [
{
"id": 4,
"source_type": "network",
"name": "NetworkSource"
},
{
"id": 5,
"source_type": "satellite",
"name": "S62Source"
}
]
}
The first several lines of a fingerprint show facts about the system, including facts about the operating system and CPUs. In this example, the os_release fact describes the installed operating system and release as Red Hat Enterprise Linux Atomic Host 7.4.
Next, the fingerprint lists the installed products in the products section. A product has a name, version, presence, and metadata field. In the JBoss EAP section, the presence field shows absent as the value, so the system in this example does not have Red Hat JBoss Enterprise Application Platform installed.
The fingerprint also lists the consumed entitlements for that system in the entitlements section. Each entitlement in the list has a name, ID, and metadata that describes the original source of that fact. In the example fingerprint, the system has the Satellite Tools 6.3 entitlement.
In addition to the metadata fields that are in the products and entitlements sections, the fingerprint contains a metadata section that is used for system fact metadata. For each system fact, there is a corresponding entry in the metadata section of the fingerprint that identifies the original source of that system fact. In the example, the os_release fact was found in Satellite Server, during the scan of the satellite source.
Lastly, the fingerprint lists the sources that contain this system in the sources section. A system can be contained in more than one source. For example, for a scan that includes both a network source and a satellite source, a single system can be found in both parts of the scan.