[DRAFT - DO NOT MERGE] Basic OpenTelemetry integration #1201
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
nshalman
force-pushed
the
otel-tracing
branch
from
508eb58 to
76af80a
Compare
nshalman
commented
Dec 12, 2024
nshalman
force-pushed
the
otel-tracing
branch
3 times, most recently
from
c86d59b to
1db15e7
Compare
|
As I've been struggling to make this cleaner I think I have had a realization. I want to be able to trace futures which means I need to use |
Handler panics in HandlerTaskMode::Detached were incorrectly being reported as 499 (Client Closed Request) instead of 500 (Internal Server Error) in telemetry and traces. This occurred because the panic handling code called panic::resume_unwind(), which caused the request handling task to panic and trigger the disconnect guard, leading to incorrect status code assignment. Changes: - Extract panic message from JoinError and convert to HttpError - Return 500 Internal Server Error instead of propagating panic - Add integration test to verify panic handling returns proper 500 status - Preserve existing behavior for HandlerTaskMode::CancelOnDisconnect 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
Add an optional "tracing" feature that enables a bridge between the tracing crate and slog, allowing users to use tracing macros while maintaining slog's structured logging and bunyan format output. Key changes: - Add optional tracing dependencies behind "tracing" feature flag - Implement SlogTracingBridge that converts tracing events to slog records - Preserve structured data types (numbers, booleans) in log output - Use proper detection with tracing::dispatcher::has_been_set() - Initialize bridge automatically when feature is enabled - Add comprehensive tests for bridge functionality The bridge maintains backwards compatibility - existing slog usage continues to work unchanged, and tracing is only available when explicitly enabled via the feature flag. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
Co-Authored-By: Claude <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
OpenTelemetry for Dropshot
This is now version 2. It has leaned into the use of
tokio-tracingandopentelemetry-tracing.The
tracingfeature funnels tracing logs out toslogfor unified logging.The
otel-tracingfeature enables shipping traces via OTLP.They can be used together or individually.
Checklist of things that are needed (note that much of it is currently incomplete):
Known Issues
- If a handler panics, currently we get a 499 error span. I don't really like that.See #1359dtrace.conf(24) References
Slides:
https://docs.google.com/presentation/d/1AW_ugVrmkXDTROgPbEt7bCLrLhFo8-z13PoJAdfPO78/
Raw video link:
https://www.youtube.com/watch?v=KQN1t2qlhaw&t=11760s
Screenshot