Feat/cgroup v2 support (#276)

[DhanashreePetare]

Cgroup v1/v2 Monitoring Support

Overview

Adds comprehensive cgroup (container) resource monitoring to prmon with automatic detection of cgroup v1, v2, and hybrid environments.

Changes

• New monitor: cgroupmon with 17 metrics across CPU, memory, I/O, and process counts
• Auto-detection: Detects cgroup version at runtime and adapts accordingly
• Parser: Handles cpu.stat, memory.stat, io.stat for both v1 and v2
• Tests: Python integration test + GTest skeleton with precooked fixtures
• Docs: README section, ADDING_MONITORS example, CONTRIBUTING Windows guide
• Disable flag: --disable cgroupmon if needed

Benefits

• Better container/Kubernetes workload monitoring
• More accurate I/O stats in containerized environments
• Backward compatible with existing prmon deployments
• Graceful degradation if cgroups unavailable

Testing

Python linting passes. CI will verify build and tests in Linux environments.

[amete]

Thanks a lot for the PR @DhanashreePetare.

Before we go further, I’d like to better understand the motivation and concrete use cases behind this change. The PR adds a fairly substantial amount of new code, and as maintainers we try to be cautious about introducing functionality unless there’s a clear and compelling need, since it also increases the long-term maintenance burden.

Could you elaborate a bit on the scenarios this is meant to support, and whether there are existing users or workflows that would benefit from it? That context would really help us evaluate how to move forward.

[DhanashreePetare]

Thanks for the thoughtful review and for asking about motivation.

This PR is aimed at containerized and scheduler‑managed workloads where /proc no longer reflects actual resource limits or usage. On modern Linux distributions, cgroup v2 is now the default (e.g., Ubuntu 22.04+, Alma/RHEL 9+), and many HEP/HTC workflows run under Kubernetes, HTCondor, Slurm, or LSF, all of which enforce limits via cgroups. In those environments, prmon’s current /proc view can over‑report memory and under‑report I/O. The cgroup data is the authoritative source for the container’s real quota/usage.

Concrete scenarios this helps:

• Grid jobs in containers (CVMFS/HTCondor/Singularity/Apptainer): cgroup v2 is increasingly common, and without it prmon misreports memory and I/O relative to enforced limits.
• Kubernetes batch workflows: resource requests/limits are enforced by cgroups, so cgroup stats provide the correct signal for monitoring and post‑mortem accounting.
• WLCG/HEP production pipelines: large‑scale job monitoring benefits from accurate cgroup I/O and memory data to avoid false alarms.

The implementation is automatic and safe: it detects v1/v2/hybrid, gracefully degrades when cgroups are absent, and can be disabled with --disable cgroupmon if not desired. The aim is to make prmon accurate in modern container environments while remaining backward‑compatible.

It would be great to hear on it, and I’m happy to adjust further implementation/changes if required based on maintainer's guidance.

[graeme-a-stewart]

Hello @DhanashreePetare thank you for the explanations. @amete and I will look in more detail at the code and get back to you.

[graeme-a-stewart]

Hello @DhanashreePetare

Thank you again for submitting this PR and apologies that many other constraints on our time prevented a more prompt review.

Serhan and I decided on a strategic approach to this that should inform the most significant changes to the PR:

• We are in favour of this, having discussed with site colleagues, as cgroups definitely provides extra and useful information.
• We decided to make this a future oriented PR, so we will only support cgroups v2. We have lived for a long time without it and most WLCG sites have now migrated to RHEL/Alma/Rocky 9 distributions, where cgroups v2 is supported. This means that cgroups v1 is a declining tail, we can live without it.
  • This will simplify the logic and reduce the number of lines of code, so it will be easier to maintain
• We should report on focused metrics that are of interest to the payload owners. The current prmon metrics are the ones that have proven useful so we would include most of what you report, but exclude the following metrics that are less useful for the application owner:
  • "cgroup_mem_slab"
  • "cgroup_mem_pgfault"
  • "cgroup_mem_pgmajfault"

Can you update the PR along these lines and then we will do a more detailed review of the code?

Thank you!

[graeme-a-stewart]

See comment above for restructuring changes.