Skip to content
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

ext/jaeger - Transform resource to tags when exporting #645

Merged
merged 9 commits into from
May 19, 2020

Conversation

nirsky
Copy link
Contributor

@nirsky nirsky commented May 4, 2020

This PR implements the missing part of exporting the TraceProvider resource into Jaeger.
Same as in js.

@nirsky nirsky requested a review from a team May 4, 2020 12:22
Copy link
Member

@mauriciovasquezbernal mauriciovasquezbernal left a comment

Choose a reason for hiding this comment

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

Thanks a lot for the PR.

I have a suggestion about how we could improve the performance a bit.

@@ -197,6 +197,8 @@ def _translate_to_jaeger(spans: Span):
parent_id = span.parent.span_id if span.parent else 0

tags = _extract_tags(span.attributes)
if span.resource is not None:

Choose a reason for hiding this comment

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

I'm wondering how we can make this test more efficient. It looks to me that resource is never None but it is _EMPTY_RESOURCE.

resource: Resource = Resource.create_empty(),

def create_empty() -> "Resource":
return _EMPTY_RESOURCE

I think one solution could be to expose _EMPTY_RESOURCE (remove the _) and make a comparison using the is operator.

if span.resource is not ̣̣̣resources.EMPTY_RESOURCE:

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I made the suggested change.
Though notice, I had to create an empty resource in all of the spans used for the jaeger tests, as it is not created by default when accessing the trace.Span directly.

I guess that in the real flow it will always be created, but maybe it's something to consider and we should keep the is not None check nonetheless, just to play it safe.
What do you think?

Choose a reason for hiding this comment

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

Good point. TBH I'm not 100% what's the best approach here, I made that suggestion to make it more efficient, but probably it's not worthy as this check is very fast in both cases and we haven't done an optimization in other places yet. I'm fine with both solutions, let's see other people's opinions on this.

Copy link
Member

@mauriciovasquezbernal mauriciovasquezbernal left a comment

Choose a reason for hiding this comment

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

LGTM. Let's see what other reviewers think about this idea of exposing and using EMPTY_RESOURCE.

@mauriciovasquezbernal
Copy link
Member

Btw, there are some style fails. You can check those locally by running "tox -e lint".

@nirsky
Copy link
Contributor Author

nirsky commented May 17, 2020

Hey, @toumorokoshi could you please review this PR? 🙏🏻

Copy link
Member

@toumorokoshi toumorokoshi left a comment

Choose a reason for hiding this comment

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

Thanks for this PR! See my comments, there's a corner case that should be handled I believe.

@@ -197,6 +198,8 @@ def _translate_to_jaeger(spans: Span):
parent_id = span.parent.span_id if span.parent else 0

tags = _extract_tags(span.attributes)
if span.resource is not EMPTY_RESOURCE:
Copy link
Member

Choose a reason for hiding this comment

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

is this necessary? feels like it adds conditional logic for a very nominal (maybe 500ns on a modern processor at most) improvement.

Copy link
Member

Choose a reason for hiding this comment

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

also I don't believe this is completely correct. Currently in the SDK, the Span.resource attribute can be None as well.

This can be simplified to a Falsy check (if span.resource) to cover both cases.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, so I'm gonna revert the exposing of EMPTY_RESOURCE and just make the simple Falsy check.
@mauriciovasquezbernal, are you ok with that?

Choose a reason for hiding this comment

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

Yes, I'm ok with that, sorry for the confusion.

@@ -34,7 +35,9 @@ def setUp(self):
is_remote=False,
)

self._test_span = trace.Span("test_span", context=context)
self._test_span = trace.Span(
Copy link
Member

Choose a reason for hiding this comment

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

if you always attach an empty resource by default, you're omitting the valid test case of a Span with "None" as the resource.

For the purposes of this PR, I recommend adding a case that assumes the Span.resource may be None.

Added #702 for a more global fix.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for reviewing @toumorokoshi, I made the requested changes.
Do you think I should add another test case explicitly handling the None case?
Or is it good enough that it's contained in the other tests?

Copy link
Member

@toumorokoshi toumorokoshi left a comment

Choose a reason for hiding this comment

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

great, thanks!

@toumorokoshi toumorokoshi merged commit 01b9117 into open-telemetry:master May 19, 2020
srikanthccv pushed a commit to srikanthccv/opentelemetry-python that referenced this pull request Nov 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants