🚅Search before asking

I have searched for issues similar to this one.

🚅Description

Currently, since the runc container shares kernel with each other and host, information about the host will be collected under the runc container

🏕Solution(optional)

we need a way to filter it to support cloud-native environments.

A duetector running inside a container should only report on the in-container process.

The duetector running on the host should be able to distinguish whether a process is coming from a container or not.

Reference:

https://github.com/cilium/cilium
https://github.com/deepflowio/deepflow

🍰Detail(optional)

Currently bcc does not provide cgroup related helper, a possible idea is to get the cgroup knid through task_struct :

task_struct->cgroups->subsys[CGROUP_SUBSYS_COUNT]->cgroup->kn->id.id

But at the same time we want to get more information for tracking and analysis. For example, a docker's cgrop:

0::/system.slice/docker-56f9992608a558ef5dbe28317de44f3459dd5968035e30508a3f1c160bb5744b.scope

56f9992608a558ef5dbe28317de44f3459dd5968035e30508a3f1c160bb5744b is container's id

Once we have the information about the process crgoup, we can clearly conclude whether the process is running in a runc container or not.

So we need to get more information from the user-space program. Or maybe we can get all the information we need from userspace alone, without relying on the ebpf

One possible way is cat /proc/{pid}/cgroup. However, given the current trigger mechanism of poller, we may not be able to get readability information for short-lived processes. And once we've implement #44, front-end programs can then run with lower latency.

🍰Example(optional)

How to get cgroup path of task in an eBPF program?