Start with the question, not the tracer
A traffic graph can answer where bytes moved. It may not tell you which executable opened the socket. A process event can name the binary and parent. It may not show the final service after address translation or a proxy hop.
The useful move is to write the question first. If the question is "which child process called connect?" capture process identity at the socket call. If the question is "which cluster service received it?" inspect the network flow where workload identity exists.
Network proof gets stronger when each witness keeps its own job.
The socket layer catches intent early
The eBPF socket-address program type can run when a process in an attached cgroup calls socket operations. The documented connect hooks cover IPv4 and IPv6. The context exposes the requested address, port, address family, socket type, protocol, and socket pointer.
This is a good point to observe or enforce an outbound destination for a bounded process group. It still needs a process record. A destination alone does not tell you whether the IDE, the agent, or a child command initiated the call.
Process filters cut the noise
Tetragon tracing-policy selectors can filter by binary path, parent binary, process ID, command arguments, namespaces, capabilities, and workload. The actions can post a matching event. Socket tracking can map sockets to processes, but the documentation requires a matching untrack action so stale entries do not break the map.
That warning belongs in every long-running witness plan. State that is added must have a removal path. A trace that quietly accumulates stale socket ownership can produce a confident answer about the wrong process.
Cluster flow tools answer a different question
Hubble observes traffic seen by Cilium. Its local API covers one node by default. Hubble Relay widens visibility across a cluster or Cluster Mesh. The CLI can filter by workload, protocol, dropped verdict, encryption state, and reply direction.
Those fields help explain what the cluster saw. They do not reconstruct a laptop process tree outside that cluster. If the agent runs on a workstation and reaches a remote service, pair a process-side witness with the service or cluster record. Keep their clocks and identifiers in the receipt.
Do not capture payload by default
Process name, parent, destination, port, protocol, direction, time, and policy verdict answer many routing questions. Payload capture can expose prompts, source code, credentials, and customer data. Add it only when the question requires content and the owner has approved the scope.
The first pass should prefer metadata. Record how the trace starts, what it can see, how it stops, how long records remain, and who can read them.
Build a matched witness packet
- Pin the executable, parent, cgroup or workload, and exact time window.
- Capture the requested destination before proxying or translation.
- Capture the observed flow and verdict at the service boundary.
- Join records with time, process identity, socket identity, and destination.
- Stop the tracer, remove temporary policy, and record the cleanup result.