Menu Close
Settings Close

Language and Page Formatting Options

Chapter 5. Using system facts in comparisons

System facts are important components that help you understand your system comparisons. Examining them reveals detailed information about the performance and changes in your Insights for RHEL system inventory. System facts also alert you to system components whose state is unknown, as well as identifying parts of your systems that require attention.

5.1. The role of system facts in comparisons

Comparison states based on observed fact values can help you manage your system. The drift service identifies facts whose behavior differs from expectations and facts whose state is unknown. It also alerts you to facts that require attention.

The drift service displays the observed fact values in different colors.

  • A red icon indicates an issue you should examine.

    img drift red examine icon

  • A green icon denotes an expected state or value.

    img drift good expected icon

  • A state shown in black, marked with a question mark icon, indicates that the expected state of the fact is unknown.

    img drift question mark

Some facts are system-specific and are considered unique. Their state is marked in red if values are equal for a given comparison. For example, if facts for fqdn and IP addresses are marked in red, they require your attention.

The drift service expects other facts, such as last_boot_time, to be different for all compared systems. For such facts, it does not highlight the differences. The service marks the comparison state as unknown (no opinion).

5.2. How facts are used in comparisons

Comparison states based on observed fact values provide guidance in managing your system. The drift service identifies facts whose behavior differs from expectations, facts whose state is unknown, and alerts users to facts that require attention.

5.3. Filtering system facts using the user interface (UI)

You can filter system facts in multiple ways:

  • by the fact comparison state
  • by fact name
  • by fact category.

Procedure

  1. Navigate to the Red Hat Enterprise Linux > Drift > Comparison page. The Comparison screen opens.
  2. On the Comparison screen, click Add systems or baselines.
  3. On the Add to Comparison screen, select the Systems tab to see the systems that are checked into your Insights for RHEL inventory.
  4. In the Name column, select the checkboxes for two or more systems and click Submit. The Comparison screen opens, showing the state of facts in the systems.

Comparison results can also be filtered by baseline facts. This feature allows you to focus on the most relevant data when creating comparisons.

  1. Click the Fact Name drop down and choose Fact type.
  2. Next, click on the Show drop down and then check the box next to Baseline facts only.

Filtering by comparison state: Click the View drop-down list and select Same to show only the facts for which values are the same, Different to show only the facts that are different, or Incomplete Data to show only the facts where the information is incomplete. You can also select a combination of Same, Different, and Incomplete data states, and clear selections as necessary. When you first add systems for comparison, all three options are selected by default.

+ img filter view options

+ * Filtering by fact name: Enter your first fact name in the search box at the top. For example, entering kernel as a filter displays all facts with names that contain kernel. To view all packages, enter installed_packages in the search box. * To add additional fact names, type the fact name in the search box and press *Enter. You can add as many fact names as you need for your filter.

+ * Filtering by fact category: Enter your first fact category in the search box to compare systems by that category. Examples include installed_packages, installed_services, kernel_modules, network_interfaces, yum_repos, cpu_flags, and enabled_services. To add additional fact categories, type the category name in the search box and press Enter. You can add as many fact categories as you need for your filter.

In the following example screen, you can see the system comparison data filtered by facts that show a difference across systems. Some facts, such as the fqdn, are expected to be different for each system, but the installed packages are expected to remain the same. Over time, some packages have been upgraded on system 1, but not on system 2 and system 3. To see these changes, expand the fact category installed_packages.

img drift comparison with diffs screen

To lock in multiple filters on facts, type the fact name in the text box and press Enter. This functionality is powered by an "OR" operator that allows you to filter out anything that does not match any of the facts you selected.

In the following example, the filtered list of facts shows only facts with names that match bios or arch.`

img drift multi fact filtering

Using the UI to sort system facts

You can sort system facts in the UI in alphabetical order. To switch sorting between ascending and descending alphabetical order, click the arrow next to Fact ( img fact sort1 ). The list of system facts appears in ascending order by default.

You can also sort system facts by the comparison State. To switch to sortng by state, click the arrow next to State ( img drift state sort ).

If you have any search filters applied to the list of system facts, the search filters are also applied to the list.

5.4. Filtering system facts using uniform resource locator (URL) parameters

The drift service enables multi-fact filtering, which enables you to create custom comparisons. You can filter system facts in several ways:

  • by the fact comparison state
  • by fact name, or
  • by fact category

Sorting by editing the URL

To expedite filtering, edit the URL parameters. The following example displays a sample URL and its parameters. The numbers of the parameters correspond to the numbered items in the parameter descriptions.

insights/drift/?baseline_ids=<baseline-id>&system_ids=<system-id>&hsp_ids=<hsp-id>&reference_id=<reference-id>&filter[name]=bios,arch&filter[state]=same,different,incomplete_data&sort=-state,fact

Parameters

  1. insights/drift/
  2. ?
  3. baseline_ids=<baseline-id>&system_ids=<system-id>&hsp_ids=<hsp-id>
  4. &reference_id=<reference-id>
  5. &filter[name]=bios,arch
  6. &filter[state]=same,different,incomplete_data
  7. &sort=-state,fact
  8. &filter[show]=baseline

Parameter descriptions

You can manually enter these parameters if desired, but changes that you make in the UI automatically populate to this parameter list.

  • App service: This reflects the Red Hat Insights for Red Hat Enterprise Linux you are using. This example uses the drift service on Red Hat Insights for Red Hat Enterprise Linux.
  • Search parameter: This is the character that tells drift you want to search on the parameters that follow.
  • IDs of systems/baselines/historical profiles: These are the IDs of the systems, baselines and historical profiles in your comparison. Each is preceded by the & symbol after the first ? symbol, and the respective parameter type (baseline_ids, system_ids or hsp_ids).
  • ID of system/baseline/historical profile to use as reference: This is the ID of the system, baseline or historical system profile used as a reference to which all other facts compare. The reference-id must be specified in one of the parameters (baseline_ids, system_ids or hsp_ids). If it is not specified, the parameter does not set a reference for comparison.
  • Fact name filters: This fact name filter takes the format &filter[name]=fact. For example, &filter[name]=bios,arch To specify multiple facts, separate them with commas and no spaces.
  • State filters: These filters take a format similar to as fact name filters, but use &filter[state]. Valid values for filter[state] are: same, different, and incomplete_data. To specify multiple facts, separate them with commas and no spaces.
  • Table sorting: This parameter uses the form &sort=state. To specify multiple facts, separate them with commas and no spaces. To sort in descending order, add a minus sign (-); for example, &sort=-fact. If no minus sign appears, the sort occurs in ascending order. To omit state sort ("no sort"), omit state sort from the parameter. You cannot omit fact sorting. If you do not specify a value for fact sorting, the sort defaults to ascending order.

5.5. Sorting system facts

You can sort system facts in the same way that you can sortusing the User Interface (UI) or by editing URL parameters.

Sorting using the UI

You can sort system facts in the UI alphabetically. Click the arrow next to Fact ( img fact sort1 ) to switch sorting between ascending and descending order. Note that facts are shown in ascending order by default. You can also sort system facts by the comparison State. Click the arrow next to State ( img drift state sort ) to switch to sorting by state.

Note

Sorting works in combination with any applied filters. That is, if you have filtered for installed packages or viewing facts by comparison state, the filtered data can be sorted alphabetically or by comparison state.

Sorting by editing the URL

Sorting can be expedited by editing the URL parameters. Examine the following URL for an explanation of how to use this functionality:

insights/drift/?baseline_ids=<baseline-id>&system_ids=<system-id>&hsp_ids=<hsp-id>&reference_id=<reference-id>&filter[name]=bios,arch&filter[state]=same,different,incomplete_data&sort=-state,fact

Parameters

  1. insights/drift/
  2. ?
  3. baseline_ids=<baseline-id>&system_ids=<system-id>&hsp_ids=<hsp-id>
  4. &reference_id=<reference-id>
  5. &filter[name]=bios,arch
  6. &filter[state]=same,different,incomplete_data
  7. &sort=-state,fact

How to use parameters

  1. App service: This reflects the app service you are using. In this case, drift on Red Hat Insights for Red Hat Enterprise Linux.
  2. Search parameter: This is the character that tells drift you want to search on the parameters that follow.
  3. IDs of systems/baselines/historical profiles: These are the IDs of the systems, baselines and historical profiles in your comparison. Each is preceded by the & symbol after the first ? symbol, and the respective parameter type (baseline_ids, system_ids or hsp_ids).
  4. ID of system/baseline/historical profile to use as reference: This is the ID of the system, baseline or historical system profile that will be used as a reference to compare all other facts to. The reference-id must be specified in one of the parameters (baseline_ids, system_ids or hsp_ids). If not specified, no reference is set for the comparison.
  5. Fact name filters: Begins with the & symbol and filter[name]. Each fact name filter applied is added after the = symbol and separated by a comma with no spaces.
  6. State filters: Same as fact name filters, but preceded by filter[state]. Valid values for filter[state] are: same, different and incomplete_data. Multiple values can be specified by separating them with a comma and no space.
  7. Table sorting: Preceded by the & symbol, state and/or fact are added after sort= and are comma separated. If state or fact is preceded by a - symbol, then it is sorted in descending order; otherwise, it sorts in ascending order. State sort has the ability to have no sort. In this case, state will not be added in the url parameter. Fact sorting, on the other hand, if left off, will default to ascending order.

These parameters can be entered manually, but their primary function is to auto-populate as you make changes in the UI.

5.6. Using obfuscated values in comparisons

The Insights client provides both IP address obfuscation and host name obfuscation.

If one of your fact values has been redacted to protect sensitive information, drift informs you that your comparison contains hidden (obfuscated) data.

Obfuscated fact values show the following characteristics:

  • The value cell is grayed out.
  • A lock icon appears in the grayed-out cell, along with a tooltip that states that the value has been redacted.
  • A tooltip appears on the "state" icon that describes why the row has the "incomplete data" state.

img drift obfuscated 1 img drift obfuscated 2

If one of the values in the comparison is redacted, the state of the comparison for that fact shows "incomplete data."

Additional resources

5.7. Understanding multi-value facts

Multi-value facts provide more detailed information to help troubleshoot system issues.

For example, drift stores a list of all installed versions for a given package name. This results in multi-value facts being available for the package. Inventory and drift APIs also provide facts with multiple values.

The following example shows a system with two kernel packages. Multi-value fact support makes it possible to view values for both packages on one system.

img drift multifact kernel

With this enhanced level of detail, you can correctly evaluate and compare all installed versions when performing an analysis.

The example below shows a system that contains a package compiled for two architectures. It has glibc packages for both i686 and x86_64 architectures.

img drift 2 architectures multi value fact

Additional resources

5.8. Using multi-fact filtering

Use multi-fact filtering to create custom comparisons for your systems. You can filter your comparison queries by specific groups of facts and tags.

You can use multi-fact filtering to:

  • Have multiple inputs in the fact name field.
  • Avoid swapping back and forth between multiple filters.
  • Exclude irrelevant facts.
  • Compare facts related to a specific issue for improved troubleshooting.
  • Share comparisons with other administrators or colleagues.

5.9. Available facts and their functions

The following table below lists the system facts that you can use in system comparisons.

Table 5.1. System Facts

Fact NameDescriptionExample Value

Ansible

Category with a list of Ansible-related facts

controller_version with a value of 4.0.0

arch

System architecture

x86_64

bios_release_date

BIOS release date; typically MM/DD/YYYY

01/01/2011

bios_vendor

BIOS vendor name

LENOVO

bios_version

BIOS version

1.17.0

cloud_provider

Cloud vendor. Values are google, azure, aws, alibaba, or empty

google

cores_per_socket

Number of CPU cores per socket

2

cpu_flags

Category with a list of CPU flags. Each name is the CPU flag (ex: vmx), and the value is always enabled.

vmx, with a value of enabled.

enabled_services

Category with a list of enabled services. Each name in the category is the service name (ex: crond), and the value is always enabled .

crond, with a value of enabled.

fqdn

System Fully Qualified Domain Name

system1.example.com

infrastructure_type

System infrastructure; common values are virtual or physical

virtual

infrastructure_vendor

Infrastructure vendor; common values are kvm, vmware, baremetal, etc.

kvm

installed_packages

List of installed RPM packages. This is a category.

bash, with a value of 4.2.46-33.el7.x86_64.

installed_services

Category with a list of installed services. Each name in the category is the service name (ex: crond), and the value is always installed.

crond, with a value of installed.

kernel_modules

List of kernel modules. Each name in the category is the kernel module (ex: nfs), and the value is enabled.

nfs, with a value of enabled.

last_boot_time

The boot time in YYYY-MM-DDTHH:MM:SS format. Informational only; we do not compare boot times across systems.

2019-09-18T16:54:56

mssql

Category with a list of MSSQL-related facts

mssql_version with a value of 15.0.4153.1

network_interfaces

List of facts related to network interfaces.

 
 

There are six facts for each interface: ipv6_addresses, ipv4_addresses, mac_address, mtu, state and type. The two address fields are comma-separated lists of IP addresses. The state field is either UP or DOWN. The type field is the interface type (ex: ether, loopback, bridge, etc.).

 
 

Each interface (ex: lo, em1, etc) is prefixed to the fact name. For example, em1’s mac address would be the fact named em1.mac_address.

 
 

Most network interface facts are compared to ensure they are equal across systems. However, ipv4_addresses, ipv6_addresses, and mac_address are checked to ensure they are different across systems. A subexception for lo should always have the same IP and mac address on all systems.

 

number_of_cpus

Total number of CPUs

1

number_of_sockets

Total number of sockets

1

os_kernel_version

Kernel version

4.18.0

os_release

Kernel release

8.1

running_processes

List of running processes. The fact name is the name of the process, and the value is the instance count.

crond, with a value of 1.

sap_instance_number

SAP instance number

42

sap_sids

SAP system ID (SID)

A42

sap_system

Boolean field that indicates if SAP is installed on the system

True

sap_version

SAP version number

2.00.052.00.1599235305

satellite_managed

Boolean field that indicates is a system is registered to a Satellite server.

FALSE

selinux_current_mode

Current SELinux mode

enforcing

selinux_config_file

SELinux mode set in the config file

enforcing

system_memory

Total system memory in human-readable form

3.45 GiB

tuned_profile

Current profile resulting from the command tuned-adm active

desktop

yum_repos

List of yum repositories. The repository name is added to the beginning of the fact. Each repository has the associated facts base_url,enabled, and gpgcheck.

Red Hat Enterprise Linux 7 Server (RPMs).base_url would have the value https://cdn.redhat.com/content/dist/rhel/server/7/$releasever/$basearch/os