[receiver/systemd]: Scrape unit CPU time#44646
Merged
atoulme merged 1 commit intoopen-telemetry:mainfrom Nov 30, 2025
Merged
Conversation
SquidDev
force-pushed
the
systemd-cpu
branch
from
04d00cd to
4a1d736
Compare
atoulme
pushed a commit
that referenced
this pull request
Nov 30, 2025
#### Description This promotes the systemd receiver to alpha stability. While this is by no means feature complete (e.g. per-unit CPU and memory usage, unit uptime), its current functionality is still useful (for observability around unit failures), and it's clear there is demand for it (e.g. #44420). There are still some open questions about the shape of the exported metrics, such as whether to represent each unit as a resource or not (as discussed in #33532, and what units to default to (see #44646), but I think we'll be better able to answer those once this is used in the wild. #### Documentation Additional examples have been added to the receiver's README.
atoulme
approved these changes
Nov 30, 2025
Contributor
|
Thank you for your contribution @SquidDev! 🎉 We would like to hear from you about your experience contributing to OpenTelemetry by taking a few minutes to fill out this survey. If you are getting started contributing, you can also join the CNCF Slack channel #opentelemetry-new-contributors to ask for guidance and get help. |
atoulme
pushed a commit
that referenced
this pull request
Dec 19, 2025
#### Description When scraping non-service units, the systemd receiver would still attempt to fetch the unit's control group, which would fail. We now guard this by checking the unit is actually a service[^1]. [^1]: This is done by checking the unit ends with `.service`. Ideally we'd check for the presence of the "Service" interface instead, but the only way to do that is parsing the dbus introspection XML. For better or worse, just checking the suffix seems to be common practice, and is much easier. To match this, we also rename the `systemd.unit.cpu.time` metric to `systemd.service.cpu.time`. This is a breaking change, but the metric still has a stability of "development", so I don't believe needs to go through the normal notification cycle? Really sorry about this! I deliberately namespaced the initial `systemd.unit.state` metric, to allow for separate `systemd.service.*` metrics, and then entirely forgot about this when implementing #44646.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
systemd.unit.cpu.timemetric. This has acpu.mode, tracking both system and user time. Unlike other CPU time metrics (e.g.process.cpu.time) which use seconds, this metric uses microseconds (us), as that is the native unit that systemd works with. Feedback is welcome on whether we should convert this to seconds.Link to tracking issue
Part of #33532, but does not close it.
Testing
Documentation
None beyond the generated documentation right now.