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

Support Environment Variables for JaegerSpanExporter configuration #1114

Merged

Conversation

rydzykje
Copy link
Contributor

@rydzykje rydzykje commented Sep 15, 2020

Description

I've added possibility to configure JaegerSpanExporter by Environment Variables defined by OTEL_SPEC

Fixes # (#1056)

Type of change

  • New feature (non-breaking change which adds functionality)
  • This change requires a documentation update

How Has This Been Tested?

  • I've used the jaeger_explorter_example.py script to check if OTEL_ENVS are properly used.
  • Updated test_jaeger_exporter.py

Checklist:

  • Followed the style guidelines of this project
  • Change logs have been updated
  • Unit tests have been added
  • Documentation has been updated

@rydzykje rydzykje requested a review from a team as a code owner September 15, 2020 13:02
@rydzykje rydzykje changed the title Support Environment Variables for JaegerSpanExporter Support Environment Variables for JaegerSpanExporter configuration Sep 15, 2020
@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Sep 15, 2020

CLA Check
The committers are authorized under a signed CLA.

Copy link
Contributor

@codeboten codeboten left a comment

Choose a reason for hiding this comment

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

The change is looking pretty good!

Please add a changelog entry to note the change in method signature and the new support for env variables. It would be good to have those variables added to the docs as well, or at least a link to the otel spec.

One more question in the code regarding precedence

os.environ.get(OTEL_ENVS["collector_endpoint"])
or collector_endpoint
)
self.username = os.environ.get(OTEL_ENVS["username"]) or username
Copy link
Contributor

Choose a reason for hiding this comment

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

I would expect the or to be reversed here username or os.environ.get(OTEL_ENVS["username"]) as to ensure that if someone overrides the variable in the code, it takes precedence over environment variables. It's the model I followed for the zipkin environment variables https://github.com/open-telemetry/opentelemetry-python/pull/1064/files#diff-eb584b1fd47b0e9ede2d87c686b87a1aR113. We should be consistent one way or another.

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've added requested changes :)

collector_port=None,
collector_endpoint=DEFAULT_COLLECTOR_ENDPOINT,
collector_protocol=DEFAULT_COLLECTOR_PROTOCOL,
collector_endpoint=None,
Copy link
Contributor

Choose a reason for hiding this comment

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

Isn't the default supposed to be http://localhost:14250?

Choose a reason for hiding this comment

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

I think in this case it shouldn't. Previously collector_endpoint was related to /api/traces?format=jaeger.thrift and it was just a part of complete endpoint address. If we set collector_endpoint default then it will be used over agent which was default implementation.

Copy link
Contributor

Choose a reason for hiding this comment

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

Any reason why the specs would have that is the default value then?

If we set collector_endpoint default then it will be used over agent which was default implementation

I'm also not sure what you mean by the above statement.

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 just want to say that in previous implementation collector by default was not used and collector_endpoint was just an end part of complete URL. In current implementation there's no need to specify host,port and endpoint separately because they will be provided by one environment variable called OTEL_EXPORTER_JAEGER_ENDPOINT coming from otel specification.

Copy link
Contributor

Choose a reason for hiding this comment

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

Correct, I am asking whether the collector_endpoint value should default to http://localhost:14250 as defined by the spec if the value is not explicitly passed into the exporter AND the environment variable is not configured.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

According to our discussion on the Gitter. We've decided to do not set the collector_endpoint default because it is causing not entirely clear path of the used protocol to export spans. Separate issue and PR should be created for this purpose.

Copy link
Contributor

@lzchen lzchen Oct 5, 2020

Choose a reason for hiding this comment

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

Hmm, looking at java's implementation, it looks like they only have the concept of the collector endpoint. This leads me to believe that we should still have the default value for collector_endpoint, and if there's anything that errors with the creation of the Collector, then we would use the AgentClientUDP instead. So we should still set the default value to http://localhost:14250.

Copy link
Contributor

Choose a reason for hiding this comment

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

@codeboten @rydzykje
Thoughts on this?

Copy link
Contributor

Choose a reason for hiding this comment

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

Looking at the code, I don't know if there's any scenario where the .constructor property would return None if the default of collector_endpoint is always set. Based on the jaeger docs, it would appear that only the agent configuration is usually set by default, and a collector endpoint would have to be explicitly set:

If we want Jaeger client libraries to send trace data directly to collectors, we must provide them with a URL of the HTTP endpoint. It means that our applications require additional configuration containing this parameter, especially if we are running multiple Jaeger installations

I wonder if the spec should default to not having a collector endpoint. You're right @lzchen that other implementations only have the concept of an endpoint, go does the same thing.

Copy link
Contributor

Choose a reason for hiding this comment

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

I would be ok to go ahead with this implementation and raise an issue with the spec about this.

@codeboten codeboten added the release:required-for-ga To be resolved before GA release label Sep 17, 2020
@rydzykje rydzykje force-pushed the rydzykje-support_env_var_conf_jaeger branch from 1bc93ce to 3d8f333 Compare September 18, 2020 18:19
@rydzykje
Copy link
Contributor Author

@codeboten @lzchen there's one more thing which stays configured without environment variable - service_name. In current implementation this is the only one thing which has to be provided directly in the code during JaegerSpanExporter instantiation. Provided specification doesn't clarify the env for this purpose.

Configuration().EXPORTER_JAEGER_ENDPOINT or collector_endpoint
)
self.username = username or Configuration().EXPORTER_JAEGER_USER
self.password = password or Configuration().EXPORTER_JAEGER_PASSWORD
Copy link
Contributor

Choose a reason for hiding this comment

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

It looks like for username/password, precedence is given to the configured parameter, whereas for agent host,port and endpoint, the precedence is given to the environment variable. this would be confusing to me as a user.

A good way to test this would be to ensure the precedence is consistent when both environment variables and the constructor is called with all parameters.

@codeboten
Copy link
Contributor

@rydzykje any updates on this PR?

@rydzykje
Copy link
Contributor Author

rydzykje commented Oct 1, 2020

@rydzykje any updates on this PR?

I'm sorry I had a lot of things to do in my job :) I will take care of it tomorrow.

@codeboten
Copy link
Contributor

I'm sorry I had a lot of things to do in my job :) I will take care of it tomorrow.

No worries! Thanks for the quick response, will await your changes.

@codeboten codeboten added this to In Progress in GA Burndown Oct 1, 2020
@codeboten codeboten self-requested a review October 8, 2020 16:35
@lzchen
Copy link
Contributor

lzchen commented Oct 8, 2020

@rydzykje
Hey if you could maybe add a comment and tag us directly about which changes/comments that you've addressed every time you make a commit that you want us to review that would be very helpful.

Copy link
Contributor

@codeboten codeboten 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 the changes @rydzykje, LGTM! Just one non-blocking comment

@@ -177,6 +177,22 @@ def shutdown(self):
pass


def _parameter_setter(param, env_variable, default):
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if this should be in the configuration object to ensure the same order of precedence is used everywhere.

@codeboten codeboten requested a review from lzchen October 9, 2020 16:45
GA Burndown automation moved this from In Progress to Reviewer Approved Oct 14, 2020
@codeboten codeboten merged commit f669b67 into open-telemetry:master Oct 15, 2020
GA Burndown automation moved this from Reviewer Approved to Done Oct 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release:required-for-ga To be resolved before GA release
Projects
No open projects
GA Burndown
  
Done
Development

Successfully merging this pull request may close these issues.

None yet

4 participants