The need for having these bespoke agents in the middle whose only job is to query metrics in some local, service specific way, and publish them in a a more generic, abstract way is something that always irked me.

systemd's own functionality for example is typically monitored via D-Bus, and the complexity of linking that up with things like prometheus, via purpose-written agents is just not that great.

With systemd v260 we are trying to move things into a better direction on this front:

instead of expecting those agents to understand every relevant services and their semantics individually, what if those services would all just implement the same, generic interface that allows pulling out the metrics you want in a normalized, unified way?

Hence, in systemd v260 we now introduced a very simple way to do this: there's now a new directory: /run/systemd/report/. Every local service can bind an AF_UNIX socket in there if they like, and implement the same, very…

…simple Varlink interface on it. A new tool "systemd-report" then iterates through those sockets, asks them all in parallel for their current metrics, compiles a single "report document" from it, and outputs it.

In v260 there are two services implementing this new interface like this: PID1 and systemd-networkd. In the coming releases we hope to grow this list, and make more and more services generically observable this way.

The metrics exposed are somewhat close to what Prometheus expects, …

… to make bridging to the prometheus world easy, however it's still distinct, because we needed both something more low-level and extensible.

Note that the new systemd-report tool is not supposed to be the only way to get the data: because the API is generic, and accessible to any service I'd expect that current agents could start using this directly too if they like to extract metrics data from systemd components, without involvement of systemd-report.

Besides implementing the metrics interface in more of the services systemd ships, we also are planning a number of other improvements in upcoming versions. For example, I plan to augment the metrics interface with a "facts" interface, that is structured similarly, but instead of retrieving time-series style data it retrieves "static" data about the system, that is worth reporting, such as identity, public key material and so on.