PSI detection relies on /proc/self/cgroup heuristic and may try to read cpu.pressure when PSI files are unavailable

[ktrntrsv]

Hello,

We are seeing the following log on application startup when using github.com/VictoriaMetrics/metrics:

INFO: metrics: disable exposing PSI metrics because of failed init: open /sys/fs/cgroup/cpu.pressure: no such file or directory

After looking into the code, it seems PSI initialization flow is roughly:

• getPSIMetrics() calls getCgroupV2Path()
• getCgroupV2Path() reads /proc/self/cgroup
• if the content contains ::, it assumes cgroup v2 path is available
• then PSI initialization tries to read:
  • /sys/fs/cgroup/.../cpu.pressure
  • /sys/fs/cgroup/.../memory.pressure
  • /sys/fs/cgroup/.../io.pressure

The problem is that getCgroupV2Path() appears to use a very lightweight heuristic:

func getCgroupV2Path() string {
	data, err := ioutil.ReadFile("/proc/self/cgroup")
	if err != nil {
		return ""
	}
	tmp := strings.SplitN(string(data), "::", 2)
	if len(tmp) != 2 {
		return ""
	}
	path := "/sys/fs/cgroup" + strings.TrimSpace(tmp[1])

	// Drop trailing slash if it exsits. This prevents from '//' in the constructed paths by the caller.
	return strings.TrimSuffix(path, "/")
}

This does not seem to validate that:

1. /sys/fs/cgroup is actually a usable cgroup v2 mount for PSI access
2. the computed cgroup path really contains PSI files
3. cpu.pressure, memory.pressure, and io.pressure are available in the current environment

As a result, the library may conclude that cgroup v2 is present and then attempt to read cpu.pressure, only to fail with no such file or directory.

In our case this happens in a Kubernetes container. The application starts and works correctly, but PSI initialization logs an INFO message on every startup. So this is not a functional failure, but the detection looks overly optimistic and produces noisy logs in environments where PSI files are not exposed.

Expected behavior

It would be helpful if PSI support detection were stricter, for example by additionally checking that the expected pressure files actually exist before attempting PSI initialization.

At minimum, it may be better to treat missing *.pressure files as “PSI not available in this environment” without logging a prominent startup message.

Suggested improvement

Possible options:

• validate that the resolved cgroup path actually contains PSI files before enabling PSI collection
• explicitly check for availability of cpu.pressure, memory.pressure, and io.pressure
• reduce log level for this case, since it is a non-fatal environment limitation rather than an actual startup problem

Thanks.