Netdata Community

"cgroups to match as systemd services" config parameter - how to confirm it evaluates?

Support Netdata Agent Support
#1

Environment

netdata 1.29.x on Ubuntu

Problem/Question

We have modified which cgroups to match as systemd services as follows cgroups to match as systemd services = /system.slice/system-h*.slice/*.service !/system.slice/*/*.service /system.slice/*.service and after restarting netdata, we do not see the expected services appear in netdata charts.

What I expected to happen

After restarting netdata, we expected to see services listed from the slice we added. We’re not sure if we needed to modify another of the netdata config lines to allow the above parameter to evaluate.

#2

Hi @simpki , lets see

We’re not sure if we needed to modify another of the netdata config lines to allow the above parameter to evaluate.

Indeed, could the be case. First of all we need a cgroup get matched by enable by default cgroups matching (otherwise it is filtered out), then, to make it appear as systemd service, matched by cgroups to match as systemd services. @vlvkobal correct me if i am wrong.

If you know the exact cgroup id you can use Netdata command line to test it.

#3

No, you can’t exclude a systemd service from being monitored using enable by default cgroups matching. @simpki please show the full path to the service you want to add.

#4

here is the full path: /sys/fs/cgroup/systemd/system.slice/system-humio.slice/humio@0.service

#5

The cgroups plugin doesn’t read files from /sys/fs/cgroup/systemd. It reads

/sys/fs/cgroup/cpuacct
/sys/fs/cgroup/blkio
/sys/fs/cgroup/memory
/sys/fs/cgroup/devices
#6

Apparently you should use /system.slice/system-h*.slice, not /system.slice/system-h*.slice/*.service.

#7

I’m not sure what to make of this. In this case, an application has chosen the /system.slice/system-h*.slice/*.service path, and the pattern match succeeds in the CLI.

#8

Checking in - is this something we should create a bug for in the netdata GitHub?

1 Like
#9

Hey @simpki,

Thanks for pinging again. Not sure to be honest, let me check with @vlvkobal and @ilyam8 first!

#10

It doesn’t matter that the pattern match - you don’t have this path in your system.

#11

@simpki could you show a cgroup full path (lets take memory)

Default is

cgroups to match as systemd services =  !/system.slice/*/*.service  /system.slice/*.service

Result is the following cgroups are matched as systemd services

[ilyam@pc ~]$ ls -l /sys/fs/cgroup/memory/system.slice/ | awk '{ print $9 }' | grep "\.service"
apparmor.service
avahi-daemon.service
cronie.service
dbus.service
docker.service
kmod-static-nodes.service
lvm2-monitor.service
ModemManager.service
netdata.service
NetworkManager.service
NetworkManager-wait-online.service
polkit.service
rtkit-daemon.service
sddm.service
smartd.service
snapd.apparmor.service
sshd.service
systemd-binfmt.service
systemd-journald.service
systemd-journal-flush.service
systemd-logind.service
systemd-modules-load.service
systemd-random-seed.service
systemd-remount-fs.service
systemd-sysctl.service
systemd-tmpfiles-setup-dev.service
systemd-tmpfiles-setup.service
systemd-udevd.service
systemd-udev-trigger.service
systemd-update-utmp.service
systemd-user-sessions.service
tlp.service
udisks2.service
upower.service
wpa_supplicant.service

The following are not

[ilyam@pc ~]$ ls -l /sys/fs/cgroup/memory/system.slice/ | awk '{ print $9 }' | grep -v "\.service" | grep -v "memory."
avahi-daemon.socket
boot-efi.mount
cgroup.clone_children
cgroup.event_control
cgroup.procs
dbus.socket
dm-event.socket
docker.socket
lvm2-lvmpolld.socket
notify_on_release
run-user-1000-gvfs.mount
run-user-1000.mount
snapd.socket
systemd-coredump.socket
systemd-journald-audit.socket
systemd-journald-dev-log.socket
systemd-journald.socket
systemd-rfkill.socket
systemd-udevd-control.socket
systemd-udevd-kernel.socket
system-getty.slice
system-modprobe.slice
system-systemd\x2dcoredump.slice
system-systemd\x2dfsck.slice
tasks
tmp.mount