docker: keep metadata when containerd socket is unavailable

[U-S-jun]

Summary

Keep Docker metadata collection available when cAdvisor detects the
containerd snapshotter storage driver (overlayfs) but cannot connect to
the containerd socket.

This is a follow-up to #3709.

Problem

In the reproduced Docker Desktop environment, the Docker API is available
through /var/run/docker.sock and reports overlayfs as the storage
driver, but /run/containerd/containerd.sock is not exposed to the
cAdvisor container.

cAdvisor currently treats failure to create the containerd client as a
Docker factory registration failure:

Registration of the docker container factory failed:
unable to create containerd client:
containerd: cannot unix dial containerd api service:
dial unix /run/containerd/containerd.sock:
connect: no such file or directory

The raw cgroup handler continues to expose resource metrics, but Docker
metadata is unavailable because the Docker handler is never created.

Before this change, metrics only contained the cgroup path:

container_last_seen{id="/docker/<container-id>"}

The container name, image, Docker labels, and Compose labels were missing.

Fix

• Only create the containerd client when Docker disk usage metrics are enabled.
• If the containerd socket is unavailable, log a warning and disable
  DiskUsageMetrics for the Docker factory instead of aborting registration.
• Only resolve the container root filesystem when disk usage metrics are enabled.
• Continue creating Docker handlers so metadata can be collected through
  Docker ContainerInspect.
• Add a regression test covering an overlayfs Docker handler without a
  containerd client or disk usage metrics.

After this change, Docker factory registration succeeds and metadata is
restored:

container_last_seen{
  id="/docker/<container-id>",
  name="cadvisor_label_test_backend",
  container_label_com_docker_compose_service="backend",
  container_label_test_role="backend"
}

Degraded behavior

When the containerd socket is unavailable, per-container disk usage metrics
such as container_fs_usage_bytes, filesystem limits, and inode usage are
not reported.

CPU, memory, disk I/O, container names, images, and Docker/Compose labels
remain available.

Testing

• go test -count=1 ./container/docker
• cd lib && go test -count=1 ./container/... ./manager ./metrics
• Built the cAdvisor image with deploy/Dockerfile
• Verified with Docker Desktop 28.5.1, cgroup v2, and the overlayfs
  storage driver
• Confirmed Docker factory registration succeeds after the containerd
  connection warning
• Confirmed name, image, Compose service, and custom Docker labels are
  present in Prometheus metrics
• Confirmed no panic or repeated stats collection errors

[U-S-jun]

@dims Could you please approve the pending workflows and take a look when you have a chance? This is related to #3860 and complements #3892 by keeping Docker metadata and non-filesystem metrics available when the containerd socket is unavailable. Thanks.

[spskeldon]

Confirming this on a second runtime, OrbStack rather than Docker Desktop, on the current release. Same root cause, and in one configuration the outcome is worse than described.

Environment

cAdvisor        v0.60.5 (revision 44b8e30)
Docker Server   29.4.0
Operating Sys   OrbStack
Storage Driver  overlayfs
Cgroup Version  2  (driver: cgroupfs)
Kernel          7.0.14-orbstack-00380-ga7e0a2dc9535
Host            macOS, 40 running containers

The failure, verbatim

factory.go:222] Registration of the systemd container factory successfully
factory.go:220] Registration of the docker container factory failed: unable to create
                containerd client: containerd: cannot unix dial containerd api service:
                dial unix /run/containerd/containerd.sock: connect: no such file or directory
factory.go:220] Registration of the containerd container factory failed: (same)

OrbStack exposes a Docker socket but no containerd socket, so the Docker factory aborts even though ContainerInspect over the Docker API works fine. Exactly the situation this PR describes.

With --docker_only=true the degradation is total, not partial

The PR notes that users fall back to raw cgroup paths like /docker/<container-id>. That holds only without --docker_only. With it set (a common choice, since it suppresses systemd-slice noise) the Docker factory's absence means nothing is reported:

$ curl -s localhost:8080/metrics | grep '^container_memory_usage_bytes' | grep -o 'id="[^"]*"' | sort -u
id="/"

$ ... | grep -c 'id="/docker/'
0

$ docker ps -q | wc -l
40

One series, for the root cgroup, against 40 running containers. No names, no images, no labels, and no raw cgroup paths either. Every container_*{name=...} dashboard and alert silently reports nothing rather than reporting something unlabelled, which is a harder failure to notice.

The v0.52.1 → v0.60.5 transition may be useful to you

We had been pinned to v0.52.1 to dodge the earlier containerd regression. On that version the Docker factory did register here, and every container handler then died individually:

manager.go:1169] Failed to process watch event ...: failed to identify the read-write layer ID
  for container "<id>". - open /rootfs/var/lib/docker/image/overlayfs/layerdb/mounts/<id>/mount-id:
  no such file or directory

On v0.60.5 that error is completely gone (0 occurrences), so whatever gating landed for getRwLayerID is working on this storage driver. The factory-registration abort in this PR is now the only thing standing between us and working per-container metrics on OrbStack.

That is what makes this PR the blocker rather than one of two: the other wall is already down.

Offer

Happy to run a build of this branch against OrbStack and report back with before/after metric counts if that is useful for review. The reproduction is deterministic here and takes a container restart.