Este contenido no está disponible en el idioma seleccionado.

Chapter 5. Systems lifecycle in the inventory application


Learn about system lifecycle management and configure custom staleness thresholds for your inventory.

5.1. System lifecycle states

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.

5.2. Determining system state in inventory

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:

  • Viewer access - Users with Inventory Hosts viewer access can view system state on the Systems page by filtering by status.
  • Administrator access - Users with Inventory Hosts administrator access can view system state from the Dashboard and access detailed system information.

5.3. Determine system state using viewer access

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.

Prerequisites

  • You are logged in to the Hybrid Cloud Console as a user who is a member of a User Access group with at least the Inventory Hosts viewer role.

Procedure

  1. On the Hybrid Cloud Console, navigate to Inventory Systems.
  2. Click the Filter drop-down list, and select Status.
  3. Click the Filter by status drop-down, and choose the states you want to include in your query.
  4. Click Reset filters to clear your query.

5.4. Determine system state using administrator access

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.

Prerequisites

  • You are logged in to the Hybrid Cloud Console as a user who is a member of a User Access group with the Inventory Hosts administrator role.

Procedure

  1. On the Hybrid Cloud Console, navigate to the Red Hat Lightspeed dashboard page.
  2. Go to the top left of the screen where you can examine the total number of systems that are registered with Red Hat Lightspeed.
  3. After the total number, towards the right side of this value, you will see the number of stale systems and the number of systems to be removed.
  4. Click either:

    • The stale systems link.
    • The systems to be removed link, if applicable.

Results

The inventory page displays with detailed system information.

5.5. Modify system staleness and deletion time limits in inventory

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

By default, system states have the following time limits:

  • Systems are labeled stale if they are not reported in one day. A warning icon displays at the top of the Systems page in the Last seen: field.
  • Systems are labeled stale warning if they are not reported within 7 days. In this case, the Last seen: field displays with a warning indicator, indicating the system is at risk of deletion.
  • Systems that are not reported in 30 days are deleted.

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.

Prerequisites

  • You are logged in to the Hybrid Cloud Console as a user who is a member of a User Access group with at least one of the following roles:

    • Organization staleness and deletion administrator
    • RHEL administrator

Procedure

  1. On the Hybrid Cloud Console, navigate to Inventory System Configuration Staleness and Deletion.
  2. Click Edit. The drop-down arrows next to each value are now enabled.
  3. Click the arrow next to the value that you want to change and then select a new value.

    Note

    The system stale warning value must be less than the system deletion value.

  4. Optional: To revert to the default values for the organization, click Reset.
  5. Click Save.

    Note

    Setting the system deletion maximum time to less than the current maximum time deletes systems that have been stale for longer than the new maximum time.

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.

Default staleness and deletion limits
By default, if a system has been stale for at least 30 days, it becomes subject to automatic deletion. A scheduled system process runs hourly to automatically delete stale hosts from inventory if they have reached their deletion limit.

5.6.1. System staleness properties

Staleness properties define the time intervals between system states and can be customized using the Red Hat Lightspeed API.

Important

Using the Red Hat Lightspeed API to set custom staleness and deletion limits can lead to non-standard outcomes. If you experience unexpected results, revert to the default staleness and deletion limits for your systems.

You can use the Red Hat Lightspeed API to change the length of time allowed between system states by passing a staleness object to the /api//inventory/v1/account/staleness API endpoint.

A staleness object is an API payload (JSON object) that contains values for the system staleness properties. When you change the value of a property, you trigger the change of that property for all systems in your Inventory.

The staleness object contains the following properties:

  • conventional_time_to_stale — the time period of inactivity before stale_warning comes on. Default: 29 hours (104400 seconds).
  • conventional_time_to_stale_warning — the time period showing stale_warning. Default: 7 days (604800 seconds).
  • conventional_time_to_delete — the time remaining before the system is deleted from the database. Default: 30 days (2592000 seconds).

To change the default values by using the Red Hat Lightspeed API, create a custom staleness object and then edit the time value for the property that you want to change.

Important

The time values in the UI for staleness are expressed in days, but times in the API objects are expressed in seconds.

Important

The value of conventional_time_to_stale must be lower than the conventional_time_to_stale_warning. The value of conventional_time_to_stale_warning must be lower than the conventional_time_to_delete value.

5.6.2. Available API operations

The Managed Inventory API provides operations to manage custom staleness and deletion values for your system inventory.

The Managed Inventory API offers the following operations:

  • GET /account/staleness — Reads the custom staleness and deletion values set in your system inventory
  • GET /account/staleness/defaults — Returns the default staleness values that are used when custom staleness is not set
  • POST /account/staleness — Set custom staleness and deletion values for your system inventory
  • PATCH /account/staleness — Update your custom staleness and deletion values
  • DELETE /account/staleness — Delete your custom staleness values
Note

The first time you create a custom configuration, use the POST operation to create the configuration. Once you have created a custom configuration, you can use the PATCH operation to change the values. If you remove the configuration with DELETE, the system reverts to the default staleness configuration.

Retrieve default staleness configuration values by using the API Catalog with sample code in your preferred programming language to understand baseline system lifecycle settings.

Prerequisites

  • You have the programming language you want to use (for example, python) installed on your system.
  • You have a service account set up and configured for authentication in the application or system that will be performing the API calls. For more information about authentication, see Configuring Authentication with Red Hat Lightspeed APIs.
  • You have an access token that you obtained from your service account or from an offline access token.
  • You have the staleness:staleness:read RBAC permission.

Procedure

  1. Open the Red Hat Lightspeed API Catalog in a web browser.
  2. Select Managed Inventory from the catalog. The Red Hat Lightspeed Host Inventory REST Interface page displays.
  3. Under the Operations list, click the drop-down arrow next to GET /account/staleness/defaults. The description for the operation includes expected responses from the server. In addition, the panel on the right side of the page generates an example API call for the GET operation in multiple languages.
  4. In the panel, click the drop-down and select the language you prefer (for example, python) from the list of options. The panel displays sample code for the GET operation, formatted in python syntax.
  5. Copy the sample code and paste it into a python code file where you want to call the GET command. For example:

    import requests
    
    url = "https://console.redhat.com/account/staleness/defaults"
    
    headers = {
       "Authorization": "Bearer <token>",
       "Content-Type": "application/json"
    }
    
    response = requests.get(url, headers=headers)
    
    print(response.json())
  6. Paste your access token for authentication in place of <token>.
  7. Run your code. If the server returns a response of 200, your API call was successful. In addition to a successful response and an optional description of the operation, the server returns the data you requested. The response looks similar to the following:

    {
    "id": "system_default",
    "org_id": "7931872",
    "conventional_time_to_stale": 104400,
    "conventional_time_to_stale_warning": 604800,
    "conventional_time_to_delete": 1209600,
    "created": null,
    "updated": null
    }
    Tip

    If the code returns a response other than 200, refer to Response Codes to determine how the API call failed and how to remedy the reason for the failure.

5.6.4. Check default values by using the Legacy API documentation

Retrieve default staleness configuration values by using the Legacy API documentation interface in the Red Hat Hybrid Cloud Console.

Prerequisites

  • You are logged in to the Hybrid Cloud Console.
  • You have the necessary permissions to perform the queries.
  • You have the staleness:staleness:read RBAC permission.

Procedure

  1. On the Hybrid Cloud Console, navigate to the API documentation page. The API Documentation page displays.
  2. Select Managed Inventory from the list of services. The Detail page displays, and shows the operations you can perform using the https://console.redhat.com/api/inventory/v1 endpoint.
  3. Click the drop-down arrow next to the GET /accounts/staleness/defaults operation. The GET request does not need input, so the list of parameters reads No parameters.
  4. Click Try It Out. The page displays the format of a successful server response.
  5. Click Execute. The page displays a curl request to the server, the request URL, and the server response.
  6. To copy the curl request to the clipboard to reuse later, click the clipboard icon on the right side of the curl request. If needed, paste it into a text editor and save it.
  7. To copy the server response to the clipboard, click the clipboard icon in the top right corner. If needed, paste it into a text editor and save it.
  8. To download the server response as a JSON file, click Download.

    Note

    If the server returns a response of 403 or another unsuccessful response, check to make sure you have the correct RBAC permissions and try the request again.

    Optional: To clear the server response and retry the command, click Clear.

Create custom staleness configuration values by using the API Catalog to define when systems move to stale, warning, or delete states.

Prerequisites

  • You have the programming language you want to use (for example, python) installed on your system.
  • You have a service account set up and configured for authentication in the application or system that will be performing the API calls. For more information about authentication, see Configuring Authentication with Red Hat Lightspeed APIs.
  • You have an access token that you obtained from your service account or from an offline access token.
  • You have the staleness:staleness:write User Access permission.

Procedure

  1. Open the Red Hat Lightspeed API Catalog in a web browser.
  2. Select Managed Inventory from the catalog. The Red Hat Lightspeed Host Inventory REST Interface page displays.
  3. Click the drop-down arrow next to the POST /account/staleness operation. The description for the operation includes parameters you can use to refine your API call and expected responses from the server. In addition, the panel on the right side of the page generates an example API call for the POST request in multiple languages.
  4. In the panel, click the drop-down and select the language you prefer (for example, python) from the list of options. The panel displays sample code for the POST request, formatted in python syntax.
  5. Copy the sample code and paste it into a python code file where you want to call the POST request. For example:

    import requests
    
    url = "https://console.redhat.com/account/staleness"
    
    payload = {
          "conventional_time_to_delete": 1,
       "conventional_time_to_stale": 1,
       "conventional_time_to_stale_warning": 1,
    }
    headers = {
       "Authorization": "Bearer <token>",
       "Content-Type": "application/json"
    }
    
    response = requests.post(url, json=payload, headers=headers)
    
    print(response.json())
  6. Add the custom staleness times you want to use in seconds in place of the values of 1 shown in the sample. Remember that a value of 1 in the API equals one second, not one day.
  7. Paste your access token for authentication in place of <token>.
  8. Run your code.

Results

If the server returns a response of 201, your API call was successful.

Create custom staleness configuration values by using the Legacy API documentation to control system state transitions in inventory.

Prerequisites

  • You are logged in to the Red Hat Hybrid Cloud Console as a user who is an Organization Administrator (member of the Default admin access group) or who has at least the staleness:staleness:write User Access role permission.

Procedure

  1. On the Hybrid Cloud Console, navigate to the API documentation page. The API Documentation page displays.
  2. Select Managed Inventory from the list of services. The Detail page displays, and shows the operations you can perform using the link:https://console.redhat.com/api/inventory/v1 endpoint.
  3. Click the drop-down arrow next to the POST /accounts/staleness operation.
  4. Click Try It Out. The page displays the format of a successful server response.
  5. Add custom staleness values in place of the number 1 for each parameter in the request body. Remember that the value of 1 in the API equals 1 second, not 1 day.
  6. Click Execute. The page displays a curl request to the server, the request URL, and the server response.
  7. To copy the curl request to the clipboard, click the clipboard icon on the right side of the curl request.
  8. To copy the server response to the clipboard, click the clipboard icon in the top right corner.
  9. To download the server response as a JSON file, click Download.

    Note

    If the server returns a response of 403 or another unsuccessful response, check to make sure you have the correct RBAC permissions and try the request again.

    Optional: To clear the server response and retry the command, click Clear.

Red Hat logoGithubredditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de la documentación de Red Hat

Legal Notice

Theme

© 2026 Red Hat
Volver arriba