editoast: 'OtelAxumLayer' act as 'INFO' level #10113
Conversation
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## dev #10113 +/- ##
==========================================
- Coverage 79.81% 79.81% -0.01%
==========================================
Files 1053 1053
Lines 105483 105485 +2
Branches 727 727
==========================================
- Hits 84196 84188 -8
- Misses 21245 21255 +10
Partials 42 42
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
By default, the 'AxumOtelLayer' only creates span at 'TRACE' level. That means that if you try `tracing::Span::current()` in a handler, you will get a `Span::none()` in response. This span is useless (it doesn't have a subscriber, no metadata): it can't be used with OpenTelemetry since all interactions between 'tracing' and 'opentelemetry' happens through `Span::with_subscriber()`. Signed-off-by: Jean SIMARD <[email protected]>
woshilapin
force-pushed
the
wsl/editoast/otel-layer-info
branch
from
e7cacc0 to
a10bb7a
Compare
There was a problem hiding this comment.
LGTM.
As discussed yesterday, I wonder if we should really rely on trace IDs for our non logging-related features. I believe editoast should behave the same way regardless of the current RUST_LOG value. As you said, a middleware ensuring a trace ID is created could fix this issue.
I agree. But in the case of STDCM debug logging, it's actually a logging functionality so I find it fine to tie this functionality to the logging framework. Actually, the STDCM debug logging functionality is configured (activated or not) through That said, I believe the current PR has not relation with the STDCM logging functionality, we should not create traces only at |
woshilapin
changed the title
By default, the 'OtelAxumLayer' only creates span at 'TRACE' level. That means that if you try
tracing::Span::current()in a handler, you will get aSpan::none()in response. This span is useless (it doesn't have a subscriber, no metadata): it can't be used with OpenTelemetry since all interactions between 'tracing' and 'opentelemetry' happens throughSpan::with_subscriber().