We didn't find any metric that surfaced zombie cgroups, presumably because the kernel mostly tries to hide them from user space since they have been deleted, but haven't been cleaned up. The only way we found at the time to track them was via a BCC script and observing the latency on reading the /sys/fs/cgroup/memory/memory.stat file.