Viewing and managing system inventory

Red Hat Lightspeed collects minimal system metadata for analysis while providing data obfuscation, redaction, and automatic retention controls.

Red Hat Lightspeed helps to identify and address operational and vulnerability risks, before they result in system downtime. This functionality requires that Red Hat Lightspeed collects small pieces of system metadata for processing and analysis. Here is how we ensure the security of your data:

Data collectors upload system information to Red Hat Hybrid Cloud Console and are deduplicated to ensure each system is displayed only once in inventory.

Each system registered in inventory gets its data from one of many data collectors. Data collectors run on a regular cadence and synchronize their collected data with the Red Hat Hybrid Cloud Console.

A system can be reported by one or more collectors. When multiple collectors provide information for the same system, inventory uses a deduplication mechanism to merge the information. This process ensures that systems are displayed only once in inventory.

The following data collectors upload system information to the Red Hat Hybrid Cloud Console:

System facts are the metadata that data collectors collect about your RHEL systems that describe configuration, health, and performance for analysis and recommendations.

insights-client uses system facts to populate inventory data in Red Hat Lightspeed and to update existing data. Red Hat Lightspeed also uses system facts to analyze system performance and to create recommendations for services such as Advisor or remediations.

Red Hat Lightspeed performs initial and daily system analyses to monitor status, identify issues, and flag systems for deletion based on staleness criteria.

When you register systems, Red Hat Lightspeed performs an initial analysis and then runs daily analyses to monitor your system status. Red Hat Lightspeed stores the status information in inventory. You can view the system details from the Inventory Systems page in the Hybrid Cloud Console.

Red Hat Lightspeed analysis results can include alerts that identify issues in your systems, and recommendations about how to resolve those issues.

Red Hat Lightspeed also monitors for system staleness by using specific staleness criteria to flag systems that are not reporting regularly. If systems do not report for a specified period of time, Red Hat Lightspeed flags them for deletion.

Red Hat Lightspeed provides REST APIs with token-based authentication for secure interaction with applications to obtain system details and recommendations.

All Red Hat Lightspeed APIs are Representational State Transfer (REST) APIs. REST APIs are stateless, meaning servers do not save client data between requests. Token-based authentication provides granular control over access permissions and enhances security.

Filter inventory systems by name, status, operating system, data collector, RHC status, last seen, workspace, or tags to focus on specific systems.

There are several ways to refine your inventory view to help you focus on the issues and systems that matter the most. Using the following steps, you can filter your systems inventory by several criteria, including:

Each system in Red Hat Lightspeed has a display name that is assigned either automatically by data collectors or manually by users. Display names identify systems within the Red Hat Hybrid Cloud Console.

There are two ways to assign a display name to a system:

Data collectors assign display names to systems based on priority, with higher-priority collectors overriding lower-priority ones.

A data collector is a specific application or service responsible for sending host information, updates, or system profile data to Red Hat Lightspeed inventory. For example, Red Hat Subscription Manager (RHSM) and Red Hat Satellite act as data collectors for Red Hat Lightspeed.

A data collector can provide a display name to Red Hat Lightspeed during registration or a registration update. If the system has a manually assigned name, the data collector uses that name as the display name. Otherwise, the data collector does not provide a display name, so Red Hat Lightspeed uses the system fully qualified domain name (FQDN) as a display name.

Each data collector that interacts with Red Hat Lightspeed has an assigned priority. Red Hat Lightspeed inventory uses the display name provided by the data collector with the highest priority. That means that the display name reported by a higher-priority data collector overrides the display name set by a data collector with a lower priority.

The following table shows the data collectors in order of priority.

You can manually assign custom display names to systems in inventory by using the UI, insights-client, or API to override automatic naming conventions.

System display names that you assign through a data collector (for example, during registration with RHSM) receive the highest priority. This means that lower-priority data collectors cannot override names that you set manually.

You can assign display names by using three methods:

Manually assign a custom display name to a system in inventory by using the UI to override automatic naming conventions.

System display names that you assign manually receive the highest priority. This means that lower-priority data collectors cannot override names that you set manually.

Use the insights-client command-line tool to set a custom display name for a system in inventory.

With the insights-client, you can set the system display name on the system itself. This method is useful for automating display name assignment during system configuration or deployment.

Use the inventory API to programmatically set custom display names for systems to enable automation and bulk operations.

Red Hat Lightspeed tags systems that use the Red Hat Lightspeed proxy in inventory to help you identify proxy-connected systems and manage connectivity from a centralized location.

Red Hat Lightspeed detects systems that communicate through a proxy server. This helps you to ensure that all systems are routed through the proxy server in disconnected environments. You can manage connectivity in your environment from a single point.

When you use the configure-client.sh script to configure systems to use the Red Hat Lightspeed proxy, the script uses the Red Hat Lightspeed system tagging capability to identify the proxy server on the client systems.

insights-proxy: <rhproxy-hostname>

insights-proxy: myproxy-example

When a client system uses a proxy server to communicate with Red Hat Lightspeed, you can view the proxy server in inventory in the Red Hat Hybrid Cloud Console. The Filter by tags filter displays the proxy server tag grouped under the insights-client heading. You can select the proxy server tag to view the client systems connected to it.

To disable the proxy connection, unconfigure the client system. Unconfiguring the client system removes the system tags that connect to the proxy server.

Red Hat Lightspeed provides a unified view of RPM, image mode, and OSTree-based systems with filtering options for image-based systems.

Red Hat Lightspeed unifies all system types into a single, streamlined view. You can view and manage RPM (package mode), image mode, and OSTree-based systems from the same page in inventory. Red Hat Lightspeed also includes filters that you can use to select and display image-based systems.

You can connect an image-based system to Red Hat Lightspeed in the following ways:

Configure an image-based RHEL system to automatically connect to Red Hat Lightspeed by pre-configuring the image with an activation key so that systems automatically register with remote host configuration (rhc) on first boot.

You can manually connect an image-based RHEL system to Red Hat Lightspeed by using the rhc command with an activation key and Organization ID.

If your image-based system is directly connected to Red Hat services or connects through a proxy server, use rhc to connect the system to Red Hat Lightspeed.

Register image-based RHEL systems with Satellite by using your preferred method to enable centralized management and Red Hat Lightspeed monitoring.

Use the Image-based system filter to view image-based systems in inventory.

To show details for a system, click the system name. The System Details page includes the image URL and its corresponding hash value.

The bootc panel on the System Details page shows information about the following:

For more information about how to configure User Access permissions, see User Access configuration guide for role-based access control (RBAC).

Add an image-based RHEL system to a workspace to organize and manage systems according to your environment requirements.

Remove obsolete or decommissioned systems from inventory to maintain an accurate record of your active infrastructure.

Use the following procedure to remove obsolete or decommissioned systems from inventory.

Understand how the role-based access control (RBAC) User Access feature of the Red Hat Hybrid Cloud Console manages user permissions through roles instead of individual user assignments. User Access simplifies permission management by assigning specific permissions to roles, which can then be assigned to user groups.

You can also create custom groups and roles to provide more fine-tuned control over specific features of Red Hat Lightspeed to suit the needs of your organization.

If you are an Organization Administrator, you can use the User Access feature under Identity & Access Management in the Hybrid Cloud Console to:

Understand the two predefined groups available in User Access: Default access and Default admin access. Create custom groups to align permissions with specific personas, job functions, or teams in your organization.

The Default admin access group includes many (but not all) predefined roles that provide update and delete permissions. The roles in this group usually include administrator in their names.

Understand how predefined roles in Red Hat Hybrid Cloud Console bundle permissions across multiple Red Hat Lightspeed applications to align with common user personas. Use predefined roles to reduce administrative effort, or create custom roles for more fine-tuned control over specific features.

The predefined roles are a starting point to help you to control and manage user permissions. You can then use these roles to create custom roles that are tailored to your specific use cases and organization. For example, you can use the predefined granular roles to create custom roles that provide more fine-tuned control over specific features of Red Hat Lightspeed.

By default, Red Hat provides a set of consolidated roles and a set of granular roles in the Red Hat Hybrid Cloud Console User Access UI. The consolidated roles significantly reduce the administrative effort required to manage user permissions, while the granular roles provide more fine-tuned control over specific features of Red Hat Lightspeed.

You can use the predefined consolidated and granular roles in User Access simultaneously, but using consolidated roles can significantly reduce the administrative effort.

Verify your current permissions and the roles or groups assigned to you in the Red Hat Hybrid Cloud Console. Check your permissions to troubleshoot access issues or understand your level of access to Red Hat Lightspeed applications.

You can also filter your permissions by application, for example, by advisor, cost management, inventory, and remediations.

If you are an Organization Administrator, you can view and manage user permissions for all users in your organization. Control access to Red Hat Lightspeed and other Red Hat Hybrid Cloud Console services through the User Access interface.

Understand the predefined roles that control access to the inventory service of Red Hat Lightspeed. Use these role definitions to assign appropriate permissions to users based on their responsibilities.

The following roles enable standard or enhanced access to inventory features:

Control workspace access with custom User Access roles that define permissions for specific workspaces. Workspaces group systems by location, department, or purpose, with each system belonging to only one workspace, ensuring users access only relevant systems.

Workspaces support role-based access control (User Access) to restrict system visibility and management based on user roles and group membership. Use User Access settings to set custom permissions on workspaces according to user role.

Be aware that you can still view the workspace name assigned to the system for which you have read access, even if you do not have access to the workspace itself. To view the workspace that contains the system, you need to have at least the Workspaces Viewer role, the RHEL viewer role, or have Workspace view permissions assigned. Before making changes in the User Access settings UI, review the list of known limitations in the User Scenarios section of the documentation.

Workspace access control supports two common organizational needs: isolating infrastructure between multiple IT teams, and restricting users to ungrouped systems only. Understanding these patterns and their limitations helps you to plan effective workspace configurations.

Use custom User Access roles to restrict users to viewing only the systems in specific workspaces while preventing them from accessing other workspaces or ungrouped systems in your organization.

Use the Red Hat Lightspeed export service to export system inventory data to CSV or JSON format for offline analysis, integration with external tools, and custom reporting workflows. Exported files are retained for 7 days.

The export service runs asynchronously in the background, allowing you to continue working while your export request is processed. You can export data by using either the UI or the Export API, and choose between CSV or JSON output formats based on your analysis needs.

The service is available in both the Red Hat Lightspeed UI and through the export service API.

The exported content includes the following information about each system in your inventory:

The inventory export service works differently from the export function in other services, such as advisor. Some of the differences are:

The inventory export process creates a zip file containing the data file, a README manifest, and metadata about the export operation.

The zip file contains the following files:

Export inventory data directly from the Red Hat Lightspeed UI to download system information in CSV or JSON format for offline analysis, reporting, or integration with external tools.

The inventory data export service works differently from the export service for other Red Hat Lightspeed services, such as advisor. The UI export feature initiates the export request and automatically downloads the file to your browser when the export completes.

The Export Service API is an asynchronous REST API that enables programmatic export of inventory data in JSON or CSV format for integration with external tools and automated workflows.

The API supports the GET, POST, and DELETE HTTP methods and offers the following operations:

The API works asynchronously. You submit a POST /exports request to initiate the export and receive a reply with a unique ID for that export. You can then use that ID to monitor the progress of the export operation with the GET /exports/id/status request. When the generated export is complete, you can download it (GET /exports/id) or delete it (DELETE /exports/id).

Successful requests return the following HTTP response codes:

The server retains generated export files for 7 days.

Use the Export Service API to programmatically export inventory data by submitting requests, monitoring progress, and downloading completed files.

The inventory export service supports exporting data from multiple services in a single request, returning separate files for each service in a ZIP file archive.

You can use the inventory export service for multiple services within the same request, such as inventory and notifications. To request multiple services, include source information for each service that you want to request in your POST /exports request. For example:

{
  "name": "Inventory Export multiple sources",
  "format": "json",
  "sources": [
    {
      "application": "urn:redhat:application:inventory",
      "resource": "urn:redhat:application:inventory:export:systems",
      "filters": {}
    },
    {
      "application": "urn:redhat:application:notifications",
      "resource": "urn:redhat:application:notifications:export:events",
      "filters": {}
    }
  ]
}

The POST /exports request returns a unique id for each export.

The GET /exports request returns a ZIP file that includes several JSON or CSV files, one for each service that you request.

Use an Ansible playbook to automate the inventory export process. The playbook is a generic playbook for the export service that uses token-based service accounts for authentication.

Systems follow a lifecycle with fresh, stale, and stale warning states based on reporting activity to maintain an accurate inventory.

A system is a Red Hat Enterprise Linux (RHEL) host that is managed by the Red Hat Lightspeed inventory in the Red Hat Hybrid Cloud Console. System activity is automatically monitored by Red Hat. All systems registered with inventory follow a lifecycle that includes the following states: fresh, stale, and stale warning. The state that a system is in depends on the last time it was reported by a data collector to the inventory application. Systems are automatically deleted from inventory if they do not report within a given time frame. The goal of the deletion mechanism is to maintain an up-to-date, accurate view of your inventory.

The following list shows a description of each state:

Fresh

The default configuration requires systems to communicate with Red Hat daily. A system with the status of fresh is active and is regularly reported to the inventory application. The status is reported by one of the data collectors described in section 1.2. Most systems are in this state during typical operations.

Stale

A system with the status of stale has NOT been reported to the inventory application in the last 24 hours. A system can become stale due to inactivity, a lack of updates, disconnection, or decommissioning without proper retirement processes.

Stale warning

A system with the status of stale warning has NOT been reported to the inventory application in the last 30 days. When a system reaches this state, it is flagged for automatic deletion. After a system is removed from inventory, it will no longer appear in the inventory application and Red Hat Lightspeed data analysis results will no longer be available.

The System became stale event highlights potential system maintenance issues. It can automatically trigger actions, such as notifying administrators or initiating the first steps to diagnose and reactivate Red Hat Lightspeed on the system.

You can determine system state in inventory by using different methods depending on your access level as a viewer or administrator.

There are two ways to determine which state a system is currently in:

View system state by filtering the Systems page by status when you have Inventory Hosts viewer access.

If you have Inventory Hosts viewer access, you can view the system state on the Systems page.

View system state from the Dashboard and access detailed system information when you have Inventory Hosts administrator access.

If you have Inventory Hosts administrator access, you can get the system state of any system from the inventory Dashboard.

Modify system staleness and deletion time limits to prevent active offline systems from being deleted.

By default, system states have the following time limits:

There are situations where a system is offline for an extended time period but is still in use. For example, test environments are often kept offline except when testing. Submarines or Internet of Things (IoT) devices can be out of range of communication for extended time periods. You can modify the system staleness and deletion time limits to ensure that systems that are offline but still active do not get deleted. Staleness and deletion settings get applied to all of your systems.

Use the Red Hat Lightspeed Host Inventory API to configure custom staleness and deletion limits for your systems.

When you do not have custom staleness and deletion settings configured for your system, Red Hat Lightspeed uses the default values to determine whether the system is in a stale state, or whether it should be automatically deleted.

Workspaces in Red Hat Lightspeed organize systems based on criteria such as environment, application, or team ownership to streamline workflows and control access.

In Red Hat Lightspeed, workspaces are only for systems. By assigning systems to specific workspaces, you streamline workflows and ensure that users have access only to the systems relevant to their roles. Systems that are not assigned to a specific workspace are automatically grouped within the Ungrouped Hosts workspace.

Workspace limits and restrictions include a 120-workspace maximum per organization, naming conventions, and structural rules that ensure efficient system organization and access control.

On the Red Hat Hybrid Cloud Console, you can create a workspace to organize systems by environment, team ownership, application type, or geographical location. This enables you to filter system views across applications, control user access to specific systems, and streamline operational workflows.

Create a new workspace and add a system to it in a single operation from the Inventory Systems page to quickly organize a specific system without creating the workspace separately first.

Add systems to an existing workspace in the Red Hat Hybrid Cloud Console to organize them by team, environment, or application and to also control user access to those systems.

On the Hybrid Cloud Console, you can remove systems from a workspace when they no longer belong to that group. Removed systems automatically move to a workspace named Ungrouped Hosts.

On the Hybrid Cloud Console, you can rename a workspace to better reflect its purpose, such as when team ownership changes or system groupings are reorganized.

On the Hybrid Cloud Console, you can delete a workspace when you no longer need it to organize systems. This helps you manage workspace capacity and stay within the organization limit.

On the Hybrid Cloud Console, you might encounter errors when creating workspaces, such as workspace limit errors, permission issues, or duplicate name conflicts. Use this procedure to diagnose and resolve these errors.

Common workspace creation errors include:

The inventory service triggers event types for validation errors, system registration, deletion, and staleness changes.

Configure behavior groups to receive notifications when inventory events occur across your organization.

Configure user email preferences to receive notifications about inventory events such as system registration and deletion.