Summary
Start #1659 with a TCP-only experimental implementation. The goal is to build the first correlated TCP transport path needed to emit trace-correlated network flow spans, while keeping the scope small enough to validate the design before expanding to other thansport ( UDP and ICMP).
Motivation
OBI already has two pieces of this problem:
- a trace-correlated DNS path in the application instrumentation pipeline
- a TCP/UDP network flow pipeline that exports aggregated flow metrics
What is missing today is the bridge between them. The network flow pipeline currently exports metrics only, and the current flow record model does not carry trace/span correlation data. Starting with TCP lets us validate the correlation strategy, event/span model, and noise/cardinality controls on the most common transport protocol before taking on UDP and ICMP.
The SIG discussion also suggested starting simple: make the first implementation experimental, validate it with real traffic, and iterate from there.
Proposal
Add an experimental TCP-only path that:
- observes TCP flow activity from the existing network flow pipeline
- correlates a TCP flow to a known trace when correlation is available
- emits a bounded TCP network representation based on aggregated flow data rather than one span per packet
- keeps the feature disabled by default
This issue is intentionally smaller than #1659. The first implementation can focus on the correlated TCP event model if that keeps the change smaller, as long as it leaves a clear path to finalized TCP flow spans.
Scope
- TCP only
- experimental and opt-in
- only emit data when correlation to a known trace exists
- reuse aggregated flow semantics already present in the network pipeline
- preserve existing network metrics behavior
- carry the minimum TCP metadata needed for later span generation, such as endpoints, bytes, packets, flags, direction, and timing
Configuration
Initial target configuration could look like:
otel_traces_export:
instrumentations: ["network"]
network:
protocols: ["TCP"]
Acceptance criteria
- An experimental TCP-only correlated network path exists behind explicit opt-in configuration
- TCP data is emitted only when it can be correlated to a known trace
- The implementation uses aggregated flow data rather than packet-per-packet export
- Existing network metrics behavior remains unchanged
- Tests cover correlation, disabled-by-default behavior, and bounded span/event volume
Summary
Start #1659 with a TCP-only experimental implementation. The goal is to build the first correlated TCP transport path needed to emit trace-correlated network flow spans, while keeping the scope small enough to validate the design before expanding to other thansport ( UDP and ICMP).
Motivation
OBI already has two pieces of this problem:
What is missing today is the bridge between them. The network flow pipeline currently exports metrics only, and the current flow record model does not carry trace/span correlation data. Starting with TCP lets us validate the correlation strategy, event/span model, and noise/cardinality controls on the most common transport protocol before taking on UDP and ICMP.
The SIG discussion also suggested starting simple: make the first implementation experimental, validate it with real traffic, and iterate from there.
Proposal
Add an experimental TCP-only path that:
This issue is intentionally smaller than #1659. The first implementation can focus on the correlated TCP event model if that keeps the change smaller, as long as it leaves a clear path to finalized TCP flow spans.
Scope
Configuration
Initial target configuration could look like:
Acceptance criteria