What is the problem you're trying to solve
The current lack of Trace IDs in logrus fields creates a significant visibility gap across the container stack. While the LogrusHook currently records logs as span events, the log entries themselves remain disconnected from the tracing context in the actual log output.
This deficiency prevents:
- Component Correlation: It is difficult to link a single operation across
kubelet, containerd, and external plugins (like custom snapshotters) without a shared identifier in the logs.
- Concurrency Filtering: Operators cannot reliably isolate interleaved logs for a single request using simple text filtering or basic log queries.
Describe the solution you'd like
I would like an opt-in configuration (e.g., in the [debug] section) to inject the current Trace ID into log entries.
The solution should:
- Extract the Trace ID from the context if a span is active.
- Add the ID as a field (e.g., trace_id) to the log entry.
- Be disabled by default to avoid log volume/format changes for existing users.
- Be implemented in a way that preserves the stability of the pkg/tracing public API.
Additional context
No response
What is the problem you're trying to solve
The current lack of Trace IDs in logrus fields creates a significant visibility gap across the container stack. While the LogrusHook currently records logs as span events, the log entries themselves remain disconnected from the tracing context in the actual log output.
This deficiency prevents:
kubelet,containerd, and external plugins (like custom snapshotters) without a shared identifier in the logs.Describe the solution you'd like
I would like an opt-in configuration (e.g., in the [debug] section) to inject the current Trace ID into log entries.
The solution should:
Additional context
No response