What the agent collects

On every scheduled run, the agent connects to each managed host and collects a set of properties that Luumen stores as the current state of that host. These properties drive:

• Filters and host groups (“show me all hosts where vendor = AWS and os_family = Linux”).
• Compliance checks (“RAM > 12 GB”, “OS version contains SLES 15”).
• System alerts (NVD matching uses OS version and installed packages; SAP Security Note matching uses installed SAP components when the SAP integration is enabled).

The exact set of properties the agent gathers is configurable. The list below is a representative cross-section, not an exhaustive reference.

​

Operating system

On Linux, OS properties are collected via standard tooling (uname, dmidecode, getenforce, tuned-adm, etc.) using the agent’s service user with the sudo access listed in Prerequisites. On Windows, OS properties come from WMI queries and the registry: Get-CimInstance, Get-WmiObject, Get-Process, Get-Service, and registry reads for installed-software data.

​

Packages and dependencies

For NVD vulnerability matching, the agent collects:

• System packages with versions, from the native package manager (e.g., rpm -qa, dpkg -l).
• Python dependencies with versions, for environments where Python tooling is relevant.

If a host is missing either property, NVD matching for that host has nothing to compare against. See Vulnerabilities.

​

Application-specific properties

Beyond the standard OS data set, the agent can collect properties specific to the applications running on a host. The current first-class application integration is SAP — when enabled, the agent collects installed components, kernel versions, profile parameters, transport state, and related properties from SAP hosts. See SAP integration for the full scope. Other application-specific collectors can be added during white-glove setup based on what your environment runs.

​

Custom properties

The list of properties the agent collects is not fixed. During white-glove setup we can configure the agent to collect additional properties specific to your environment — anything reachable from the service-user’s permissions on the host. Common examples:

• Output of an internal compliance script your team already runs.
• Specific file contents or hashes (e.g., the contents of /etc/sshd_config, a checksum of a configuration baseline).
• Custom registry keys on Windows.
• Application-specific configuration values not in the default set.

If you want a property that isn’t currently collected, raise it with your account team. Adding new collectors usually requires an agent upgrade, which we’ll coordinate. See Support.

​

Where to see what’s collected

To see what properties exist for any host, open the Hosts page in the Luumen UI and click a host. The detail view lists every property the agent has reported for that host, grouped by category. To see the raw data the agent reads on each run, open the per-host log on the Patch server at log/[date]/checks/[host_ip].log. Property names in the log are the agent’s internal names and are close to but not always identical to the UI labels.

​

How the data is used downstream

Captured properties feed several parts of the platform: That coupling is why missing properties cause downstream effects (no alert matches, no NVD findings). The troubleshooting flows in Common issues all start by checking whether the property in question made it from the host into Luumen.