Red Hat SummitManaging devices
Managing Red Hat Edge Manager devices
Abstract
Chapter 1. Managing devices
You can manage your devices individually or in a fleet. The Red Hat Edge Manager allows you to manage a whole fleet of devices as a single object instead of managing many devices individually.
You only need to specify the desired configuration once and then the Red Hat Edge Manager applies the configuration to all devices in the fleet.
Understanding individual device management is the foundation for managing devices in a fleet. You might want to manage your devices individually in the following scenarios:
- If a few devices have significantly different configurations.
- If you use external automation for updating the devices.
Required access: Cluster administrator
The following documentation focuses on managing individual devices:
To learn more about managing your devices in a fleet, see Managing device fleets.
1.1. Enrolling devices
To manage your devices with Red Hat Edge Manager, you must enroll the devices to the Red Hat Edge Manager service.
The first time Red Hat Edge Manager agents runs on a device, the agent prepares for the enrollment process by generating a cryptographic key pair. The cryptographic key pair of the device consists of a public and a private key. The private key never leaves the device, so that the device cannot be duplicated or impersonated. The key pair is registered with the Red Hat Edge Manager service during enrollment and is deleted during decommissioning of the device.
When the device is not yet enrolled, the agent performs service discovery to find its Red Hat Edge Manager service instance. Then, the device establishes a secure, mTLS-protected network connection to the service. The device uses its X.509 enrollment certificate that the device acquired during image building or device provisioning. The device submits an enrollment request to the service that includes the following:
- a description of the device hardware and operating system
- an X.509 Certificate Signing Request which includes the cryptographic identity of the device to obtain the initial management certificate
The device is not considered trusted and remains quarantined in a device lobby until an authorized user approves or denies the request.
For more information, read the following sections:
1.1.1. Prerequisites
- You must install the Flight Control CLI. See Installing the Flight Control CLI.
- You must log in to the Red Hat Edge Manager service.
1.1.2. Enrolling devices using the Flight Control CLI
You must enroll devices into the Red Hat Edge Manager service before you can manage them. Complete the following steps:
List all devices that are currently waiting for approval by running the following command:
flightctl get enrollmentrequests --field-selector="status.approval.approved != true"See the following example output:
NAME APPROVAL APPROVER APPROVED LABELS <device_name> Pending <none> <none>Note: The unique device name is generated by the agent and cannot be changed. The agent chooses a base32-encoded hash of its public key as device name.
Approve an enrollment request by specifying the name of the enrollment request. Optionally, you can add labels to the device by using the
or--labelflags. See the following example:-lflightctl approve -l region=eu-west-1 -l site=factory-berlin enrollmentrequest/54shovu028bvj6stkovjcvovjgo0r48618khdd5huhdjfn6raskgSee the following example output:
NAME APPROVAL APPROVER APPROVED LABELS <device_name> Approved user region=eu-west-1,site=factory-berlin
After you approve the enrollment request, the service issues the management certificate and registers the device in the inventory. The device is now ready to be managed.
1.2. Viewing devices
To obtain more information about the devices in your inventory, you can use the Flight Control CLI.
1.2.1. Prerequisites
- You must install the Flight Control CLI. See Installing the Red Hat Edge Manager CLI.
- You must log in to the Red Hat Edge Manager service.
- You must enroll at least one device.
1.2.2. View device inventory and device details
View devices in your device inventory. Complete the following steps:
View the devices in the device inventory by running the following command:
flightctl get devicesSee the following example output:
NAME ALIAS OWNER SYSTEM UPDATED APPLICATIONS LAST SEEN <device_name> <none> <none> Online Up-to-date <none> 3 seconds agoView the details of this device in YAML format by running the following command:
flightctl get device/<device_name> -o yamlSee the following example output:
apiVersion: flightctl.io/v1alpha1 kind: Device metadata: name: <device_name> labels:1 region: eu-west-1 site: factory-berlin spec: os: image: quay.io/flightctl/rhel:9.52 config: - name: my-os-configuration3 gitRef: path: /configuration repository: my-configuration-repo targetRevision: production status: os: image: quay.io/flightctl/rhel:9.54 config: renderedVersion: "1"5 applications: []6 applicationsSummary: status: Unknown7 resources:8 cpu: Healthy disk: Healthy memory: Healthy systemInfo:9 architecture: amd64 bootID: 037750f7-f293-4c5b-b06e-481eef4e883f operatingSystem: linux summary: info: "" status: Online10 updated: status: UpToDate11 [...]- 1
- User-defined labels assigned to the device.
- 2
- The target OS image version of the device.
- 3
- The target OS configuration of the device.
- 4
- The current OS image version of the device
- 5
- The current OS configuration version of the device.
- 6
- The current list of deployed applications on the device (array of application status objects).
- 7
- The health status summary of all applications on the device.
- 8
- The availability of CPU, disk, and memory resources.
- 9
- Basic system information.
- 10
- The health status of the device.
- 11
- The update status of the device.
1.3. Labels and label selectors
You can organize your resources, including individual devices, fleets and any other resources, by assigning them labels. For example, you can use labels to record location, hardware type, or purpose. The Red Hat Edge Manager labels follow the same syntax, principles, and operators as Kubernetes labels and label selectors.
You can select devices with labels when viewing the device inventory or applying operations to the devices.
Labels follow the
key=valuesite=<location>You can also use labels that only consist of keys.
Labels must adhere to the following rules to be valid:
- Keys and value must each be 63 characters or less.
-
Keys and values can consist of alphanumeric characters (,
a-z,A-Z).0-9 -
Keys and values can also contain dashes (), underscores (
-), dots (_) but not as the first or last character.. - Value can be omitted.
You can apply labels to resources in the following ways:
- Define a set of default labels during image building that are automatically applied to all devices during deployment.
- Assign initial labels during enrollment.
- Assign labels post-enrollment.
When resources are labeled, you can select a subset of resources by writing a label selector. A label selector is a comma-separated list of labels for selecting resources that have the same set of labels.
See the following examples:
| Example label selector | Selected devices |
|---|---|
|
| All devices with a |
|
| All devices with a |
|
| All devices with a |
For more information, see Labels and Selectors.
1.4. Using labels
You can organize your devices by using labels.
1.4.1. Viewing devices and their labels using the Flight Control CLI
View devices and their associated labels. You can use labels to organize your devices and device fleets.
Complete the following steps:
View devices in your inventory by using the
option:-o wideflightctl get devices -o wideSee the following example output:
NAME ALIAS OWNER SYSTEM UPDATED APPLICATIONS LAST SEEN LABELS <device1_name> <none> <none> Online Up-to-date <none> 3 seconds ago region=eu-west-1,site=factory-berlin <device2_name> <none> <none> Online Up-to-date <none> 1 minute ago region=eu-west-1,site=factory-madridView devices in your inventory with a specific label or set of labels by using the
option:-l <key=value>flightctl get devices -l site=factory-berlin -o wideSee the following example output:
NAME ALIAS OWNER SYSTEM UPDATED APPLICATIONS LAST SEEN LABELS <device1_name> <none> <none> Online Up-to-date <none> 3 seconds ago region=eu-west-1,site=factory-berlin
1.4.2. Updating labels using the CLI
Update labels on your devices using the CLI. Complete the following steps:
Export the current definition of the device into a file by running the following command:
flightctl get device/<device1_name> -o yaml > my_device.yamlUse your preferred editor to edit the
file. See the following example:my_device.yamlapiVersion: flightctl.io/v1alpha1 kind: Device metadata: labels: some_key: some_value some_other_key: some_other_value name: <device1_name> spec: [id="..."]Save the file and apply the updated device definition by running the following command:
flightctl apply -f my_device.yamlVerify that the changes are applied by running the following command
NAME ALIAS OWNER SYSTEM UPDATED APPLICATIONS LAST SEEN LABELS <device1_name> <none> <none> Online Up-to-date <none> 3 minutes ago some_key=some_value,some_other_key=some_other_value <device2_name> <none> <none> Online Up-to-date <none> 4 minutes ago region=eu-west-1,site=factory-madrid
1.5. Field selectors
Field selectors filter a list of Red Hat Edge Manager resources, including individual devices, fleets and any other resources, based on specific resource field values.
Field selectors follow the same syntax, principles, and operators as Kubernetes field and label selectors with additional operators available for more advanced search use cases.
1.5.1. Supported fields
The Red Hat Edge Manager resources give a set of metadata fields that you can select.
Each resource supports the following metadata fields:
-
metadata.name -
metadata.owner -
metadata.creationTimestamp
Note: To query labels, use label selectors for advanced and flexible label filtering.
For more information, see Labels and label selectors.
1.5.2. List of additional supported fields
In addition to the metadata fields, each resource has its own unique set of fields that you can select, offering further flexibility in filtering and selection based on resource-specific attributes.
The following table lists the fields supported for filtering for each resource kind:
| Kind | Fields |
| Certificate Signing Request |
|
| Device |
|
| Enrollment Request |
|
| Fleet |
|
| Repository |
|
| Resource Sync |
|
1.5.3. Field discovery
Some Red Hat Edge Manager resources might expose additional supported fields. You can discover the supported fields by using the
flightctl--field-selectorSee the following examples:
flightctl get device --field-selector='text'Error: listing devices: 400, message: unknown or unsupported selector: unable to resolve selector name "text". Supported selectors are: [metadata.alias metadata.creationTimestamp metadata.name metadata.nameOrAlias metadata.owner status.applicationsSummary.status status.lifecycle.status status.summary.status status.updated.status]The field
text--field-selectorDeviceYou can then use one of the supported fields:
flightctl get devices --field-selector 'metadata.alias contains cluster'The
metadata.aliascontainscluster1.5.3.1. Examples
Excluding a specific device by name
The following command filters out a specific device by its name:
flightctl get devices --field-selector 'metadata.name!=<device_name>'Filter by owner, labels, and creation timestamp
The following command retrieves devices that are owned by
Fleet/pos-fleetus2024flightctl get devices --field-selector 'metadata.owner=Fleet/pos-fleet, metadata.creationTimestamp >= 2024-01-01T00:00:00Z, metadata.creationTimestamp < 2025-01-01T00:00:00Z' -l 'region=us'Filter by owner, labels, and device status
The following command retrieves devices that are owned by
Fleet/pos-fleetusstatus.updated.statusUnknownOutOfDateflightctl get devices --field-selector 'metadata.owner=Fleet/pos-fleet, status.updated.status in (Unknown, OutOfDate)' -l 'region=us'1.5.4. Supported operators
| Operator | Symbol | Description |
| Exists |
| Checks if a field exists. For example, the |
| DoesNotExist |
| Checks if a field does not exist. |
| Equals |
| Checks if a field is equal to a value. |
| DoubleEquals |
| Another form of equality check. |
| NotEquals |
| Checks if a field is not equal to a value. |
| GreaterThan |
| Checks if a field is greater than a value. |
| GreaterThanOrEquals |
| Checks if a field is greater than or equal to a value. |
| LessThan |
| Checks if a field is less than a value. |
| LessThanOrEquals |
| Checks if a field is less than or equal to a value. |
| In |
| Checks if a field is within a list of values. |
| NotIn |
| Checks if a field is not in a list of values. |
| Contains |
| Checks if a field has a value. |
| NotContains |
| Checks if a field does not contain a value. |
1.5.5. Operators usage by field type
Each field type supports a specific subset of operators:
| Field Type | Supported Operators | Value |
| String |
| Text string |
| Timestamp |
| RFC 3339 format |
| Number |
| Number format |
| Boolean |
| Boolean format ( |
| Array |
| Array element |
1.6. Updating the operating system
You can update the operating system of a device by updating the target operating system image name or version in the device specification.
When the Red Hat Edge Manager agent communicates with the service, the agent detects the requested update. Then, the agent automatically starts downloading and verifying the new operating system version in the background.
The Red Hat Edge Manager agent schedules the actual system update according to the update policy. At the scheduled update time, the agent installs the new version without disrupting the currently running operating system.
Finally, the device reboots into the new version.
The Red Hat Edge Manager currently supports the following image type and image reference format:
| Image Type | Image Reference |
| bootc | An OCI image reference to a container registry. Example: |
During the process, the agent sends status updates to the service. You can monitor the update process by viewing the device status. For more information, see Viewing devices.
1.6.1. Updating the operating system of a device using the Flight Control CLI
UTo update the operating system of a device using the
flightctlGet the current resource manifest of the device by running the following command:
flightctl get device/<device_name> -o yaml > my_device.yamlEdit the
resource to specify the new operating system name and version target.DeviceapiVersion: flightctl.io/v1alpha1 kind: Device metadata: name: <device_name> spec: [id="..."] os: image: quay.io/flightctl/rhel:9.5 [id="..."]Apply the updated
resource by running the following command:Deviceflightctl apply -f <device_name>.yaml
1.7. Operating system configuration for edge devices
You can include an operating system-level host configuration in the image to provide maximum consistency and repeatability.
To update the configuration, you create a new operating system image and update devices with the new image.
However, updating devices with a new image can be impractical in the following cases:
- The configuration is missing in the image.
- The configuration needs to be specific to a device.
- The configuration needs to be updateable at runtime without updating the operating system image and rebooting.
For these cases, you can declare a set of configuration files that is present on the file system of the device. The Red Hat Edge Manager agent applies updates to the configuration files while ensuring that either all files are successfully updated in the file system, or rolled back to their pre-update state. If the user updates both an operating system and configuration set of a device at the same time, the Red Hat Edge Manager agent updates the operating system first, then applies the specified set of configuration files.
You can also specify a list of configuration sets that the Red Hat Edge Manager agent applies in sequence. In case of a conflict, the last applied configuration set is valid.
Important: After the Red Hat Edge Manager agent updates the configuration on the disk, the running applications need to reload the new configuration into memory for the configuration to become effective. If the update involves a reboot,
systemd1.7.1. Configuration providers
You can provide configuration from multiple sources, called configuration providers, in Red Hat Edge Manager. The Red Hat Edge Manager currently supports the following configuration providers: A repository used by a provider must be set up once and can then be used for multiple devices or fleets.
- Git Config Provider
- Fetches device configuration files from a Git repository.
- Kubernetes Secret Provider
- Fetches a secret from a Kubernetes cluster and writes the content to the file system of the device.
- HTTP Config Provider
- Fetches device configuration files from an HTTP(S) endpoint.
- Inline Config Provider
- Allows specifying device configuration files inline in the device manifest without querying external systems.
Read more about the configuration providers in the following sections:
1.7.1.1. Configuration from a Git repository
You can store device configuration in a Git repository such as GitHub or GitLab. You can then add a Git Config Provider so that the Red Hat Edge Manager synchronizes the configuration from the repository to the file system of the device.
The Git Config Provider takes the following parameters:
| Parameter | Description |
|
| The name of a |
|
| The branch, tag, or commit of the repository to checkout. |
|
| The absolute path to the directory in the repository from which files and subdirectories are synchronized to the file system of the device. The |
|
| Optional. The absolute path to the directory in the file system of the device to write the content of the repository to. By default, the value is the file system root ( |
The
Repository1.7.1.2. Secrets from a Kubernetes cluster
The Red Hat Edge Manager can query only the Kubernetes cluster that the Red Hat Edge Manager is running on for a Kubernetes secret. The content of that secret can be written to a path on the device file system.
You can manage Kubernetes Secret Provider configurations via the CLI or API. Kubernetes Secret Provider configurations are displayed in the UI as read-only.
The Kubernetes Secret Provider takes the following parameters:
| Parameter | Description |
|
| The name of the secret. |
|
| The namespace of the secret. |
|
| The directory in the file system of the device to write the secret contents to. |
To apply a Kubernetes secret to a device, add a config entry with
secretRefExample: Device spec with secretRef
spec:
config:
- name: my-secret
secretRef:
name: my-secret-name
namespace: my-secret-namespace
mountPath: /etc/my-secret Run
flightctl apply -f <file>.yamlThe Red Hat Edge Manager worker needs permission to read secrets from the cluster. You can either allow cluster-wide access at install time or grant namespace-scoped access with RBAC (least-privilege):
-
Cluster-wide access: Set to
global.worker.clusterLevelSecretAccessin the Helm values when installing Red Hat Edge Manager on OpenShift. See Installing Red Hat Edge Manager on OpenShift.true -
Namespace-scoped access: Create a and
Rolein the namespace where the secrets are stored so theRoleBindingservice account canflightctl-workersecrets in that namespace only. For details, see the OpenShift RBAC documentation.get
Example: Role and RoleBinding for flightctl-worker secret access
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: <secret_namespace>
name: flightctl-worker-secret-reader
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
namespace: <secret_namespace>
name: flightctl-worker-secret-reader
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: flightctl-worker-secret-reader
subjects:
- kind: ServiceAccount
name: flightctl-worker
namespace: <worker_namespace> Apply the manifest with
oc apply -f <file>.yaml1.7.1.3. Configuration from an HTTP server
The Red Hat Edge Manager can query an HTTP server for configuration. The HTTP server can serve static or dynamically generated configuration for a device.
The HTTP Config Provider takes the following parameters:
| Parameter | Description |
|
| The name of a |
|
| The suffix to append to the base URL defined in the |
|
| The absolute path to the file in the file system of the device to write the response of the HTTP server to. |
The
Repository1.7.1.4. Configuration inline in the device specification
You can specify configuration inline in a device specification. When using the inline device specification, the Red Hat Edge Manager does not need to connect to external systems to fetch the configuration.
The Inline Config Provider takes a list of file specifications, where each file specification takes the following parameters:
| Parameter | Description |
|
| The absolute path to the file in the file system of the device to write the content to. If a file already exists in the specified path, the file is overwritten. |
|
| The UTF-8 or base64-encoded content of the file. |
|
| Defines how the contents are encoded. Must be either |
|
| Optional. The permission mode of the file. You can specify the octal with a leading zero, for example |
|
| Optional. The owner of the file. Specified either as a name or numeric ID. Default value is set to |
|
| Optional. The group of the file. Specified either as a name or numeric ID. |
1.7.2. Additional resources
- For more information about device lifecycle hooks and the default rules used by the Red Hat Edge Manager agent, see Device lifecycle hooks.
1.8. Configuring fleets to auto-register MicroShift clusters
If you have fleets of devices that are running an operating system image that includes MicroShift, you can configure your fleets to auto-register MicroShift clusters with Red Hat Advanced Cluster Management.
1.8.1. Configuring your device template
To enable auto-registration in a fleet, add configuration to the device template. Complete the following steps:
Add the
resource configuration, which includes theacm-crdfor yourfilePathfile, yourcrd.yaml, andrepositoryto yoursuffixresource. See the following example:FleetapiVersion: flightctl.io/v1alpha1 kind: Fleet metadata: name: fleet-acm spec: selector: matchLabels: fleet: acm template: spec: os: image: <your os image> config: - name: acm-crd httpRef: filePath: /var/local/acm-import/crd.yaml repository: acm-registration suffix: /agent-registration/crds/v1Add the
resource configuration with theacm-import,filePath, andrepository, as you see in the following example:suffixconfig: - name: acm-import httpRef: filePath: /var/local/acm-import/import.yaml repository: acm-registration suffix: /agent-registration/manifests/{{.metadata.name}}Optional: If your MicroShift cluster did not pull the Red Hat Advanced Cluster Management images, add the
resource, as you see in the following addition to the template:pull-secretconfig: - name: pull-secret inline: - path: "/etc/crio/openshift-pull-secret" content: "{\"auths\":{...}}"Add the
resource with the following conditionalapply-acm-manifestsrequirements to runifon yourkubectl apply -ffile, and yourcrd.yamlfile:import.yamlconfig: - name: apply-acm-manifests inline: - path: "/etc/flightctl/hooks.d/afterupdating/50-acm-registration.yaml" content: | - if: - path: /var/local/acm-import/crd.yaml op: [created] run: kubectl apply -f /var/local/acm-import/crd.yaml envVars: KUBECONFIG: /var/lib/microshift/resources/kubeadmin/kubeconfig - if: - path: /var/local/acm-import/import.yaml op: [created] run: kubectl apply -f /var/local/acm-import/import.yaml envVars: KUBECONFIG: /var/lib/microshift/resources/kubeadmin/kubeconfig-
In the console, label the device and click Approve, which automatically selects the
fleet:acmfleet. See Managing device fleets for information about managing devices with labels.fleet-acm
1.9. Managing the device configuration from a Git repository on the CLI
Create and apply a device configuration in a Git repository.
Complete the following steps:
Create a file, for example
, that contains the following definition for asite-settings-repo.yamlresource, namedRepository:site-settingsapiVersion: flightctl.io/v1alpha1 kind: Repository metadata: name: site-settings spec: type: git url: https://github.com/<your_org>/<your_repo>.gitCreate the
resource by running the following command:Repositoryflightctl apply -f site-settings-repo.yamlVerify that the resource has been correctly created and is accessible by Red Hat Edge Manager by running the following command:
flightctl get repository/site-settingsSee the following example output:
NAME TYPE REPOSITORY URL ACCESSIBLE site-settings git https://github.com/<your_org>/<your_repo>.git TrueApply the
configuration to a device by update the device specification:example-siteapiVersion: flightctl.io/v1alpha1 kind: Device metadata: name: <device_name> spec: [id="..."] config:1 - name: example-site gitRef: repository: site-settings targetRevision: production path: /etc/example-site2 [...]- 1
- The example configuration takes all the files from the
example-sitedirectory from theproductionbranch of thesite-settingsrepository and places the files in the root directory (/). - 2
- Ensure that the target path is writeable by creating your directory structure. The root directory (
/) is not writeable inbootcsystems.
1.10. Device lifecyle hooks
The Red Hat Edge Manager agent can run user-defined commands at specific points in the device lifecycle by using device lifecycle hooks. For example, you can add a shell script to your operating system images that backs up your application data. You can then specify that the script must run and complete successfully before the agent can start updating the operating system.
As another example, certain applications or system services do not automatically reload their configuration file when the file changes on the disk. You can manually reload the configuration file by specifying a command as another hook, which is called after the agent completes the update process.
The following device lifecycle hooks are supported:
| Lifecycle hook | Description |
|
| The hook is called after the agent completes preparing for the update, but before changing the operating system. If an action in this hook returns with a failure, the agent cancels the update. |
|
| The hook is called after the agent writes the update to disk. If an action in this hook returns with a failure, the agent cancels and rolls back the update. |
|
| The hook is called before the system reboots. The agent blocks the reboot until the action completes or times out. If any action in this hook returns with a failure, the agent cancels and rolls back the update. |
|
| The hook is called when the agent first starts after a reboot. If any action in this hook returns with a failure, the agent reports the failure but continues starting up. |
1.10.1. Rule files
You can define device lifecycle hooks by adding rule files to one of the following locations in the device file system:
-
Rules in the drop-in directory are read-only. To add rules to the
/usr/lib/flightctl/hooks.d/<lifecycle_hook_name>/directory, you must add them to the operating system image during image building./usr -
Rules in the drop-in directory are read-writable. You can update the rules at runtime by using several methods.
/etc/flightctl/hooks.d/<lifecycle_hook_name>/
When creating and placing the files, you must consider the following practices:
- The name of the rule must be all lower case.
- If you define rules in both locations, the rules are merged.
- If you add more than one rule files to a lifecycle hook directory, the files are processed in lexical order of the file names.
-
If you define files with identical file names in both locations, the file in the folder takes precedence over the file of the same name in the
/etcfolder./usr
A rule file is written in YAML format and contains a list of one or more actions. An action can be an instruction to run an external command.
When you specify many actions for a hook, the actions are performed in sequence, finishing one action before starting the next.
If an action returns with a failure, the following actions are skipped.
A
run| Parameter | Description |
|
| The absolute path to the command to run, followed by any flags or arguments, for example |
|
| Optional. A list of key-value pairs to set as environment variables for the command. |
|
| Optional. The directory the command is run from. |
|
| Optional. The maximum duration that is allowed for the action to complete. Specify the duration as a single positive integer followed by a time unit. The |
|
| Optional. A list of conditions that must be true for the action to be run. If not provided, actions run unconditionally. |
By default, actions are performed every time the hook is triggered. However, for the
afterUpdatingIfFor example, to run an action only if a given file or directory changes during the update, you can define a path condition that takes the following parameters:
| Parameter | Description |
|
| An absolute path to a file or directory that must change during the update as condition for the action to be performed. Specify paths by using forward slashes ( |
|
| A list of file operations, such as |
If you specify a path condition for an action in the
afterUpdating| Variable | Description |
|
| The absolute path to the file or directory specified in the path condition. |
|
| A space-separated list of absolute paths of the files that changed during the update and are covered by the path condition. |
|
| A space-separated list of absolute paths of the files that were created during the update and are covered by the path condition. |
|
| A space-separated list of absolute paths of the files that were updated during the update and are covered by the path condition. |
|
| A space-separated list of absolute paths of the files that were removed during the update and are covered by the path condition. |
The Red Hat Edge Manager agent includes a built-in set of rules defined in
/usr/lib/flightctl/hooks.d/afterupdating/00-default.yaml| File | Command | Description |
|
|
| Changes to |
|
|
| Changes to |
|
|
| Changes to the permanent configuration of |
1.10.2. Additional resources
1.11. Monitoring device resources
You can set up resource monitors for device resources and create alerts when the utilization of resources crosses a defined threshold. When the agent alerts the Red Hat Edge Manager service, the service sets the device status to
degradederrorResource monitors take the following parameters:
| Parameter | Description |
|
| The resource to monitor. The |
|
| The interval in which the monitor samples usage, specified as a positive integer followed by a time unit: |
|
| A list of alert rules. |
|
| For |
Alert rules take the following parameters:
| Parameter | Description |
|
| The severity of the alert rule can be |
|
| The duration that resource usage is measured and averaged over when sampling, specified as a positive integer followed by a time unit: |
|
| The usage threshold that triggers the alert, as percentage value. The value ranges from 0 to 100 without the % sign. |
|
| A human-readable description of the alert. Add details about the alert to help with debugging. By default, the alert description is |
1.11.1. Monitoring device resources using the CLI
Monitor the resources of your device through the CLI, providing you with the tools and commands to track performance and troubleshoot issues.
Complete the following steps:
Add resource monitors in the
section of the device specification. For example, add the following monitor for your disk:spec.resourcesapiVersion: flightctl.io/v1alpha1 kind: Device metadata: name: <device_name> spec: [id="..."] resources: - monitorType: Disk samplingInterval: 5s1 path: /application_data2 alertRules: - severity: Warning3 duration: 30m percentage: 75 description: Disk space for application data is >75% full for over 30m. - severity: Critical4 duration: 10m percentage: 90 description: Disk space for application data is >90% full over 10m. [id="..."]
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}