Sorry if this has been posted before but couldn’t found it in my searches. (It’s from September 25)

The new systemd-report collects system facts and runtime metrics into unified, timestamped JSON reports for monitoring and fleet management.

systemd is getting a new reporting subsystem designed to collect both static system information and dynamic runtime metrics in one place.

Called systemd-report, the new tool gathers data from multiple metric provider services via a generic Varlink interface and combines it into a single timestamped JSON report. The work targets system and fleet management, where administrators need a consistent view of many machines.

The collected information is split into two groups. The first covers relatively static system “facts,” such as CPU architecture, hostname, kernel version, OS identification, installed RAM, CPU count, virtualization technology, TPM information, and other hardware or platform details.

The second covers changing runtime metrics like CPU and memory use, load averages, disk I/O, swap usage, system pressure, cgroup statistics, network interface states, systemd unit states, restart counters, queued jobs, and high-priority journal messages.

According to Lennart Poettering, the underlying metrics service was initially contributed by Meta with a focus on dynamic runtime information. The same interface was later extended to handle more static system facts as well, something Amutable is using for areas such as operating system deployment management.

Once gathered, systemd-report compiles all of this information into a consistent snapshot representing the state of the machine at a particular point in time.

The subsystem is designed for remote fleet management. Reports can be uploaded directly to an HTTPS server using PUT requests, letting organizations send system information to a central control plane. The setup includes periodic uploads via a systemd timer and reports triggered by events like system boot, reboot, or shutdown.

For security, reports can be cryptographically signed before being sent, and systemd currently provides three signing methods.

The simplest uses a software-generated asymmetric key stored locally. Systems with TPM hardware can produce a TPM quote covering platform measurements and the report data. A third option supports confidential-computing environments by generating a CPU TSM quote that ties the report to measurements of the secure virtual machine.

This makes systemd-report different from traditional monitoring tools like Prometheus and its node_exporter. While both expose similar information, systemd obtains data directly from lower-level OS components instead of relying on a separate scraping model.

More importantly, systemd-report focuses on complete, signed, timestamped snapshots rather than independent streams of metrics. Poettering notes that the two approaches are not mutually exclusive, and the new infrastructure could eventually provide the basis for integration between them.

The architecture is also intentionally extensible. Third-party projects can provide additional metrics or signing mechanisms simply by exposing the appropriate Varlink socket. These providers can be written in any programming language and only need to implement a small interface.

In other words, systemd-report is not just another command for displaying system information. It is shaping up as a broader reporting framework built directly into systemd, combining system facts, runtime metrics, secure signing, and remote reporting in a format suitable for managing everything from individual Linux machines to large server fleets.

For additional details, see Poettering’s announcement.