Very nice work on the new report interface. I finally had a chance to play with it in systemd 260 and 261.
Ref: https://mastodon.social/@pid_eins/116220986239256436 systemd already sits on a lot of valuable host and service health metrics, but unfortunately not many monitoring agents expose them comprehensively. In the embedded space, for example, we find Fluent Bit compact enough for our devices, but its systemd metrics support does not seem particularly mature yet (at least as far as I know). Having a standard interface should make it much easier to convince upstream agents to support these metrics properly. As argued in the Mastodon post, the agent’s primary responsibility is to collect and forward data. What are the upstream thoughts on offloading the agent role entirely to systemd-report? OpenTelemetry has become a widely adopted standard. One challenge, however, is that the OpenTelemetry metrics model is generally push-oriented, where services export metrics to a collector (local or remote). Retrofitting such a model onto some systemd metric providers, especially one-shot units, could be fairly complicated. systemd-report, on the other hand, is already in a position to aggregate metrics via Varlink. It could potentially act as the agent itself: collect report metrics from providers and export them using OTLP (the OpenTelemetry Protocol) to an OpenTelemetry collector. More generally, I am curious about the longer-term vision here. Is there interest upstream in moving beyond traditional monitoring agents, and what are the current thoughts on OpenTelemetry integration? Umut
