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?