Check the cgroup version before using Docker metric paths

Bottom line: Identify the actual cgroup layout before interpreting a missing or surprising container metric. Keep container identity, host version and driver context together so an incorrect file path is not mistaken for a zero resource measurement.

Source fact: documented behavior

The Runtime metrics documentation is the primary reference.

The guide identifies cgroup v2 through the presence of /sys/fs/cgroup/cgroup.controllers and says the file layout differs significantly from v1. It labels the detailed metric-file examples as cgroup v1 and directs v2 users to their container controller files and the v2 kernel documentation for semantics. The documented per-container cgroup paths vary with both cgroup version and the cgroupfs or systemd driver, using the container’s full identity.

What the source does not establish

This article selects the correct observation context, not a universal memory formula or a recommendation to switch cgroup versions. It excludes the guide’s historical LXC collection techniques. Obtain controller semantics from the documentation for the actual installed environment before defining an alert.

Applicability questions

• Which Linux host and full container identity are being measured?
• Does the host expose the documented v2 indicator?
• Which cgroup driver and corresponding path apply?
• Does the collector distinguish an absent file or failed read from a measured zero?

DSE recommendation: bind the measurement to its collection context

DSE recommends a collector record with the host, full container identity, cgroup version, driver and selected controller path. Capture those inputs through the approved read-only administrative route before changing the application’s limits. Keep remote Docker contexts and the host being inspected attributable to the same workload.

Compare the configured metric path with the guide’s version-and-driver alternatives. Review any template that assumes one layout for every node. Mark an unavailable controller or failed read as a collection finding rather than substituting a numeric value to keep a dashboard populated.

Read the actual metric’s documented definition before choosing an alert threshold. Record its units, scope and the relevant controller documentation with the collector revision. Do not transfer a v1 example formula into a v2 deployment because the displayed label appears similar.

Test collector changes independently of workload resizing. Preserve the original observation and compare the selected file with the collector’s report under a small approved workload. Keep any actual resource shortage as its own finding, with the application owner involved before limits are changed. Avoid a host reboot or kernel configuration change solely to match a tutorial layout.

Verification and evidence

Proposed verification, not performed: use an approved Linux test host and harmless container. Record the observed version, driver and full identity, then inspect the corresponding controller path and compare it with the collector’s configured input. Predict the handling of an intentionally unavailable test path before exercising that collector branch.

If both v1 and v2 test hosts are available, treat them as separate cases with their own documented semantics. Retain the selected paths, raw nonsensitive observations, units, collector revision and actual error handling. Do not claim equivalence between unlike metrics or accept one successful read as proof that every node uses the same layout.

Official references

• Runtime metrics — Docker Docs.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.