Skip to content

Conversation

@mkabischev
Copy link

Description: currently InternalTracesToJaegerProto deletes service.name attribute during conversion to jaeger proto. It causes problems if you want to export trace data via several exporters.

@codecov-io
Copy link

Codecov Report

Merging #884 into master will increase coverage by 0.03%.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #884      +/-   ##
==========================================
+ Coverage   85.97%   86.00%   +0.03%     
==========================================
  Files         162      162              
  Lines       12948    12949       +1     
==========================================
+ Hits        11132    11137       +5     
+ Misses       1395     1393       -2     
+ Partials      421      419       -2     
Impacted Files Coverage Δ
translator/trace/jaeger/traces_to_jaegerproto.go 79.80% <100.00%> (+0.09%) ⬆️
translator/internaldata/resource_to_oc.go 76.47% <0.00%> (+2.94%) ⬆️
receiver/opencensusreceiver/octrace/opencensus.go 93.33% <0.00%> (+3.33%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c7c58b3...2ce19ec. Read the comment docs.

@tigrannajaryan
Copy link
Member

Good catch. The current behavior is a bug and does not match our data ownership guidelines: https://github.com/open-telemetry/opentelemetry-collector/tree/master/exporter#data-ownership

@dmitryax FYI.

@tigrannajaryan tigrannajaryan changed the title don't modify process attributes in jaeger translator Don't modify process attributes in jaeger translator Apr 28, 2020
attrs.ForEach(func(key string, attr pdata.AttributeValue) {
if key == conventions.AttributeServiceName {
return
}
Copy link
Member

@dmitryax dmitryax Apr 29, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for fixing it!

The only concern I have is that now we scatter handling of conventions.AttributeServiceName across many functions, it doesn't seem right especially having attributesToJaegerProtoTags function being called in other places. Probably we could add another argument to attributesToJaegerProtoTags like skipKeys map[string]bool that can be used to filter particular keys out. What do you think?

cc @tigrannajaryan

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

attributesToJaegerProtoTags is used in several places, so it makes sense.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not like this. Map lookup is going to have cost. Translation functions need to be fast, and this one loop is the most frequently called one. I would like to see performance profile before accepting this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think map lookups should be pretty fast. map initialization is the most expensive, but here it's handled perfectly, only two initializations. Otherwise we can just duplicate the function and create resourceAttributesToJaegerProtoTags for now in order to not block the fix. @tigrannajaryan what do you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we want a quick fix let's pass a single bool parameter that controls AttributeServiceName specifically.

If we want the map I can be easily convinced by a CPU profile that shows it is not significant. :-)

Copy link
Member

@tigrannajaryan tigrannajaryan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Performance impact is unclear.

@bogdandrutu
Copy link
Member

This bug was fixed in #907

@bogdandrutu bogdandrutu closed this May 1, 2020
swiatekm pushed a commit to swiatekm/opentelemetry-collector that referenced this pull request Oct 9, 2024
Bumps [actions/checkout](https://github.com/actions/checkout) from 3 to 4.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](actions/checkout@v3...v4)

---
updated-dependencies:
- dependency-name: actions/checkout
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants