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.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Populate Zipkin remoteEndpoint #4933
Populate Zipkin remoteEndpoint #4933
Changes from all commits
5855a24
cddd6a6
53b04a1
9eb08c2
505a7da
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a bummer that these are kinda redundant (duplicated) now -- they exist both in the
remoteEndpoint
and in the tags. Should we filter these specific keys out of the tags when mapping the attributes over?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fyi: there will be lots of things to filter out: https://opentelemetry.io/docs/reference/specification/trace/sdk_exporters/zipkin/#otlp---zipkin
What happens in this class seems wrong to me (but I guess now it's too late for that); I think the span (
SpanData
?) should have these as separate fields not as attributes. I'm biased though: I prefer having type-safe fields instead of pouring everything into a "hashmap".Also, just an fyi: as a user of OTel, I would consider this as a breaking change (a tag will be removed from the span). I'm not sure if doing such a change is even allowed here (maybe it is since semconv is unstable so deleting/renaming attributes and breaking users that way is possible at this point here).
It might worth to check other exporters too, i.e.: will those tags be shipped to Jaeger/OTLP/etc?
Because of these, I think deleting (filtering out) those attributes should happen in a separate issue/pr.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume the decision to model fields in map-like structure instead of in top level fields is because it affords more ability to experiment without the consequences of adding a top level field we later wish to remove / rename / or change. This relieves bikeshedding (to some extent anyway 😄).
Additionally, since spans can potentially be used to model many many domains, the top level fields could easily get bogged down as more and more top level fields were added.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I see the intent but doing this will also give a false sense of not introducing a breaking change when this happens. Indeed, source and binary compatibility are kept but unfortunately it is still a breaking change since behavioral compatibility is not.
I totally agree with not adding fields for everything (that's what attributes are for) but I also think that this is such a fundamental field that it should be there (like the name of the span or the localEndpoint).
I just wanted to call these out, they don't really belong to the scope of this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a "fundamental" field for one type of span, but certainly not universally applicable, which is why it shouldn't be a top level field on the Span, or the SpanData.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess that's why it should be optional/
@Nullable
but to me that does not make it less important.The fact that it is optional/not universally applicable does not justify "stringly" typing to me; if something is optional, it usually does not go into a hashmap.
I guess this is true for other parts of the OTel API/SDK, there are things that are optional but they have their own fields and they are not stringy typed, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're arguing with the wrong crowd here... this would be something that would need to be added in the specification, and not something we would or could unilaterally add to the java APIs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yepp, that's why I wrote that I think now it's too late for that.