Skip to main content
The question: which container sent this file, when many containers share one host? Filetrace runs on the host and sees the host’s processes. Two filters map those processes back to a container: --cgroup and --namespace. Both are first-class filters on files, transfers, processes, connections, flows and watch.

​
Run the agent on the host, not in a container

The agent loads eBPF programs and needs the host’s PID namespace to see every container’s processes. Run filetrace-agent as the packaged service on the node. An agent inside a container, even privileged, sees only its own namespace.

​
Find a container’s cgroup

Every process has a cgroup, and its directory in the cgroup tree identifies it:
Pass the directory, and Filetrace uses its inode number, or pass the numeric ID directly:

​
Filter by namespace

--namespace takes the inode number of a network, PID or mount namespace:
This is the quickest way to answer “what did this pod’s network namespace send”, because the network namespace is per pod.

​
Rank containers by egress

--include-children matters in containers: a shell, a runtime and a worker are separate processes, and folding descendants into the parent’s totals shows the pod, not the pieces.

​
What the metrics show

The process_executable_name label is the kernel’s name for the process, at most 15 bytes. It does not carry the container or pod name. To get per-container metrics, join the Filetrace series with your container metadata on the host and the process:
The reliable per-container key is in the log records and the API: process.pid, plus filetrace.socket.id to follow a transfer to its endpoints. Join process.pid against container_process-style metrics from cAdvisor or the kubelet, or against the cgroup ID, to attribute transfers to a pod.

​
A worked example

A node runs an upload service and a database. Something is sending a large backup off the node.
The report names the cgroup and the namespace; compare them with the pod spec. The transfer is INFERRED because pg_dump reads the file and writes it to the socket, which is expected for a dump stream.

​
Where the answer can mislead

  • Short-lived processes. A process that exits before the agent reads its cgroup can show without one. process_executable_name still names it.
  • Host networking. Pods that share the host network namespace cannot be told apart by --namespace; use --cgroup or the PID.
  • A sidecar proxy sends on behalf of the application. The transfer is attributed to the proxy’s process, so name the intended service by the socket’s local port or by the script.
  • Namespaces are reused after a pod restarts, so a namespace inode identifies a pod only for its lifetime. For long-term attribution, log the PID and cgroup with the transfer.