expose systemd's MemoryCurrent value in metrics

[evgeni]

No description provided.

[SuperQ]

Implementation seems fine. But doesn't this overlap with a number of different cAdvisor metrics? We've been trying to keep the systemd_exporter from also becoming a new cAdvisor.

[evgeni]

Partially, I guess. You can certainly get the same numbers from cAdvisor (by looking at the cgroup systemd created), but given that systemd already has this data it felt natural to also export it here for setups that don't want/need all other features of cAdvisor?

(The old, broken memory metrics were removed in #68 and you said "Keep only metrics provided by systemd itself." :) )

[yangxiangyu]

need this feature.

[frittentheke]

Partially, I guess. You can certainly get the same numbers from cAdvisor (by looking at the cgroup systemd created), but given that systemd already has this data it felt natural to also export it here for setups that don't want/need all other features of cAdvisor?

(The old, broken memory metrics were removed in #68 and you said "Keep only metrics provided by systemd itself." :) )

@SuperQ I was just about to quote this exact commit when wondering about resource metrics for systemd units being gone in the recent master. I suppose it boils down to the question whether the systemd exporter should expose any resource metrics (and their limits) belonging to units?

If you invoke systemctl show some.service you see e.g.

[...]
CPUUsageNSec=34524810546022
MemoryCurrent=82944000
IOReadBytes=18446744073709551615
IOReadOperations=18446744073709551615
IOWriteBytes=18446744073709551615
IOWriteOperations=18446744073709551615
IPIngressBytes=[no data]
IPIngressPackets=[no data]
IPEgressBytes=[no data]
IPEgressPackets=[no data]
[...]

provided accounting is enabled for the particular resources via e.g.

[...]
CPUAccounting=yes
IOAccounting=no
BlockIOAccounting=yes
MemoryAccounting=no
TasksAccounting=yes
IPAccounting=no
[...]

Yes most if not all of those metrics will likely be available via cAdvisor since that exposes all of them cgroups. But it does so without any context of the system unit, apart from the slice name, right?
Having the systemd exporter to selectively export resource metrics for units which have them enabled, will greatly reduce cardinality and maybe also makes it easier to correlate with other unit metrics?

There even is a switch (https://github.com/google/cadvisor/blob/fbd519ba03978d54cb54ea7ed8ab9d6e3dd64590/docs/runtime_options.md?plain=1#L14) to disable exporting anything but "real" containers since cAdvisor is actually all about "containers".

[sturmf]

I also would vote for this PR 👏

I am running systemd-exporter with this patch and it works great and I now have a trifecta of exporters working hand in hand:

• The node_exporter gives me the memory consumption overview of the whole system
• The systemd_exporter gives me the memory consumption overview by systemd unit
• And finally the process_exporter can be used to drill down to individual processes.

It really would be great if this can be merged into the codebase!

[shamil]

Hey guys,

Just to understand the intention of this exporter. I came accross this exporter due it's capability to provide resource usage metrics (e.g. CPU and Memory) per systemd unit, apperantly this is not the case any longer. If we won't add support for CPU/Memory (such as this PR does), I'm wondering what's the scope of this exporter and how it is any better to what is exported by the node_exporter?

[jcgl17]

I'd like to reiterate the questions and ideas of basically everyone else in this thread. What is the scope of this exporter? As a concrete example, why are memory accounting stats (apparently) not in-scope, whereas IP accounting stats are? Particularly when this PR fetches mem stats over DBus in basically the same way as IP stats are fetched (afaiu; see collectIPAccountingMetrics()).

As a new user of this exporter, I'm very much interested in surfacing unit stats that systemd presents to the user via its command-line and DBus interfaces. I can certainly understand the purity argument that bringing cgroup stats into this exporter is some kind of redundancy or layering violation. But I would argue in response that having such stats in this exporter is very useful in a way that (from my user perspective) should surely outweigh the purity/layering considerations. The systemd people evidently thought so too when they decided to include these stats in systemd's own interfaces.

At this point, I'd be quite happy to bring this PR up-to-date with HEAD and even add any other dbus-provided metrics that people here would be interested in. However, it'd be really helpful to hear from the maintainer(s) about the possibility of actually merging this functionality. @SuperQ?

[jcgl17]

@evgeni, I've rebased this PR against main on my fork: feature/cgroup-metrics

If you want to force-push my rebased version to your branch for this PR, please feel free to do that or suggest any other route your prefer.

In the meantime, I think I'll start adding CPU accounting.

[evgeni]

I don't care/need this anymore. Feel free to open a new PR and use my code.

[jcgl17]

I've opened #172 with CPU, Memory, and IO Accounting. Any feedback there would certainly be welcome!