Lightning Talk: Who Are You? Solving the Container ID Resolution With Cgroupv2
Lightningat Observability Day 2025 · on Tuesday, 2025-04-01· at 17:00· Level 1 | Hall Entrance S10 | Room B·
summary
Problem: with cgroupv2 and private cgroup namespaces /proc shows just “/” so the old trick of reading /proc/self/cgroup no longer yields container IDs. Common workaround reading mountinfo is unreliable (returns volume IDs or differs by runtime). Two concrete solutions: inject Pod UID+container name via a mutating webhook (works in Kubernetes but races on container restart), or have the app read the cgroup inode and let an agent that mounts host cgroupfs map that inode back to the container ID. Datadog implements both and this mapping is running in production since early last year.
AI-written summary · about
chapters (10)
- 0:00Container monitoring challenges
- 1:04Container identification in observability
- 2:09cgroup v1 vs v2 differences
- 3:34Container ID resolution requirements
- 4:36Limitations of cgroup.procs in v2
- 5:19Webhook solution drawbacks
- 6:23Universal container ID proxy
- 7:30cgroup v2 iode solution
- 8:56Implementation and fallback
- 10:01Production use and availability
related talks
06mLightning Talk: Who Are You? A Heuristic Approximation to Service Identification
06mLightning Talk: Parsing CRI JSON logs with Fluent Bit
13mTalk Deep Dive
22mTraceloop: Tracing containers syscalls using BPF
30mMix Kubernetes with Linux Kernel Tracing to Boost the Observability of Your Cluster
07mLightning Talk: My Job Says 'Running' but Nothing's Running: Kubernetes Status Reality...
05mMichael Ducy - DevOpsDays NYC 2018 Ignite
42mPanel - Klustered: eBPF Edition