tracer: translate PIDs from descendant namespaces

[simonepri]

Context

PIDNamespaceTranslation, introduced in #1538, uses bpf_get_ns_current_pid_tgid to obtain the current task's PID and TGID in a specified PID namespace. This eBPF helper only supports an exact active-namespace match.

Problem

In nested setups such as Kind, normal Pods run in child PID namespaces. The profiler starts, but discards their samples because the helper cannot translate their PIDs into the profiler's namespace. This PR implements the child PID namespace follow-up proposed for #620.

Solution

PIDNamespaceTranslation remains the master switch, and PIDNamespaceTranslationMode now defaults to Auto. We can keep the existing helper for exact matches and, when it cannot translate a task, walk the PID hierarchy if the required BTF fields are available. If those fields cannot be resolved, Auto keeps exact matching. Descendants makes support mandatory and returns an actionable startup error, while Exact does not require the PID namespace BTF layout.

The fallback finds the profiler namespace by inode and returns the IDs visible from it. Tasks outside that namespace tree are discarded rather than reported with host PIDs.

Validation

CI ran in fork PR #1. The CI run passed all 37 jobs, including the amd64 and arm64 QEMU kernel matrix. The eBPF reproducibility check also passed.

[opentelemetry-pr-dashboard]

Pull request dashboard status

Waiting on reviewers · refreshed 2026-09-08 23:06 UTC

Review the latest changes.

Status above doesn't look right?

• Just replied or pushed? Anything around or after the refresh time above may not be picked up yet — give it a few minutes.
• Anything look wrong? Report it with what you expected; it helps us improve the dashboard.

[florianl]

Just sharing my initial impressions:

It looks like BTF becomes a hard requirement with this change. I’m okay with that, though it might be worth explicitly pointing it out for users.

Manually configuring PIDNamespaceTranslation alongside TranslateDescendantPIDs could get tricky—wondering if an auto setting might be cleaner?

Curious to get your thoughts on how this compares to #1657?

[simonepri]

Thanks for the review!

Re BTF, is only needed for descendant translation, same-namespace translation still works without it. There's a note in tracer.Config, but happy to document it somewhere more user-facing if you have a place in mind.

RE auto setting, descendant mode needs is only needed in certain scenarios and not sure we should force BTF everywhere (but you might have more context here).

In general, I agree tho that two boolean is a code smell. I've changed that to an enum and renamed it to PIDNamespaceTranslationMode and documented that the setting is ignored when translation is disabled (ideally we could delete the boolean but I guess we want to be backward compatible).

[rockdaboot]

RE auto setting, descendant mode needs is only needed in certain scenarios and not sure we should force BTF everywhere (but you might have more context here).

How much overhead would it be if descendant mode is always on, given that BTF and the required BTF descriptions are available? If I understand the eBPF loop correctly, the CPU overhead is negligible (loop early exit).

I am asking because in a mixed/complex environment, the nesting of namespaces is not always obvious and/or it's complex/tedious to configure manually.

[simonepri]

If by “always on” you mean enabling it when the BTF fields resolve and otherwise keeping exact translation, that makes sense.

I agree the CPU sampling overhead should be negligible: same-namespace tasks skip the loop, and a direct child only checks two levels. Off-CPU profiling may be different because this runs on scheduler hooks, but we can measure that separately.

We’d still need a strict mode for Kind so missing BTF fails instead of silently dropping child workloads.

[simonepri]

I've added an auto mode with the logic I mentioned above and made it the default. Let me know what you think

[rockdaboot]

TY, sounds good to me!

[rockdaboot]

Curious to get your thoughts on how this compares to #1657?

@florianl TY for asking this Q! #1811 helped me to get some better understanding, so sharing it here.

[simonepri]

I don't think the comparison is accurate for #1801 versus #1657.

Both address the same Kind topology: the profiler runs in the node container's PID namespace and workloads run in descendant namespaces.

#1657 selects a PID using the profiler's namespace depth. However, sibling Kind nodes can exist at the same depth, and a PID from one sibling is not valid in another.

#1801 matches the actual profiler namespace, translates both PID and TID, and rejects sibling namespaces.

So #1801 is functionally the same as #1657 just without the sibling-attribution issue.

[simonepri]

@florianl @rockdaboot any blocker for getting this in!?

[florianl]

any blocker for getting this in!?

My availability is currently limited, so I won't be able to dive into these edge cases or provide detailed feedback right now. Since a few different proposed changes seem to address the same core issue, I’ve left my initial feedback with #1801 (comment)