rework spanid (breaking change)#16
Open
Fishrock123 wants to merge 3 commits intoinanna-malick:masterfrom
Open
Conversation
Now can be any opaque string as specified by Honeycomb but will be generated as a UUID V4 and also prefer to be stored as a UUID. Adds many ways of converting to and from `TraceId`.
Honeycomb allows it's trace_id's to be _any arbitrary string_. Respect that, because we may be sent an id from some source we do not directly control, such as an edge proxy. This changes TraceId to avoid parsing, and to internally just hold a string. Unfortunately the tracing crate imposes restrictions that make this untenable for span ids. This also includes a rework of sampling, making it be deterministic for a given trace_id, and also allowing it to function on any string.
Instance ids appear unnecessary. Any span must already be associated with a trace, which has 128 bits (a very large space to avoid collisions). Given a span ids must only be unique in a given trace, 64 bits alone should be plenty. Also, honeycomb doesn't have any special way to represent full parallelism, the full span ids must be different anyways. This also changes the SpanId formatting to be hex by default. The parser has also been update to parse in hex.
0fd82cf to
c430fda
Compare
Contributor
Author
|
As noted in eaze/tracing-honeycomb#2, I cannot see CI, and so I have no idea what is failing here. I've already tested everything locally, and the same PR against my employer's fork with updated CI passes: eaze/tracing-honeycomb#2 |
Fishrock123
added a commit
to eaze/preroll
that referenced
this pull request
Feb 17, 2021
This fixes various issues with tracing-honeycomb. Refs: inanna-malick/tracing-honeycomb#15 Refs: inanna-malick/tracing-honeycomb#16 This also gets us other unreleased commits, allowing us to do per-trace sampling.
This was referenced Feb 17, 2021
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
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.
Instance ids appear unnecessary. Any span must already be associated with a trace, which has 128 bits (a very large space to avoid collisions). Given a span ids must only be unique in a given trace, 64 bits alone should be plenty. Also, honeycomb doesn't have any special way to represent full parallelism, the full span ids must be different anyways.
This also changes the
SpanIdformatting to be hex by default. The parser has been updated to also parse in hex.This fixes a critical issue interpreting parent spans from other honeycomb providers (such as beeline-nodejs).
Builds on #15