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

Allow the jaeger exporter path to be configured #2847

Merged
merged 10 commits into from
Feb 24, 2022
Merged

Allow the jaeger exporter path to be configured #2847

merged 10 commits into from
Feb 24, 2022

Conversation

abe545
Copy link
Contributor

@abe545 abe545 commented Feb 2, 2022

Fixes #2821.

Changes

Please provide a brief description of the changes here.
This makes the JaegerExporter treat the configurable Endpoint in its options the same way the ZipkinExporter does. Basically, instead of hardcoding /api/traces as a path to POST the trace data to, it is now assumed to be a part of the Endpoint. This is the cleanest way of implementing this feature, but it is possible it will break people who already have it configured correctly.

I'm open to other ways of doing this - I'm not sure what the ethos is in this project surrounding changes like this. As I mentioned in the original feature request, I have some other ideas about how to achieve the goal (the goal being to be able to fully control the URL being used to post trace data), but figured I'd start with the cleanest code and move from there.

For significant contributions please make sure you have completed the following items:

@abe545 abe545 requested a review from a team February 2, 2022 20:42
@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Feb 2, 2022

CLA Signed

The committers are authorized under a signed CLA.

@cijothomas
Copy link
Member

cijothomas commented Feb 2, 2022

CLA Signed

The committers are authorized under a signed CLA.

@abe545
Copy link
Contributor Author

abe545 commented Feb 2, 2022

CLA Signed

The committers are authorized under a signed CLA.

Copy link
Member

@reyang reyang left a comment

Choose a reason for hiding this comment

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

LGTM with minor suggestions.

/// </summary>
public Uri Endpoint { get; set; } = new Uri("http://localhost:14268");
public Uri Endpoint { get; set; } = new Uri(DefaultJaegerEndpoint);
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 this is a breaking behavior. Previously /api/traces was appended to the endpoint user provided. Now we expect the user to provide the whole url.

(should be fine as Endpoint was added only in 1.2 and we haven;t yet released a stable)

@CodeBlanch Could you comment?

Also, we should update the readme to reflect the new change.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Agreed that this a breaking change. As I said in my PR comment, I personally think it makes sense to have this work like the zipkin exporter does - but I totally understand if you would like to avoid a breaking change. This is fairly trivial to change to some other pattern (like maybe another property on the JaegerExporterOptions with the path to append to the endpoint, and have it default to /api/traces).
I'll update the readme as a part of this PR to reflect the decision you make on how to implement this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hi @cijothomas just wanted to check if you've had a chance to discuss with the other maintainers what you'd like me to do here? Thanks!

Copy link
Member

@pellared pellared Feb 9, 2022

Choose a reason for hiding this comment

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

It may be good to confront it with the specification and how other languages are doing it (I suspect inconsistency after a quick look).

PS. OTel Java docs are probably misleading.

Copy link
Contributor Author

@abe545 abe545 Feb 9, 2022

Choose a reason for hiding this comment

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

So in the Environment variable docs it just lists http://localhost:14250 as the default value, and the jaeger docs are explicit about the path to use for Thrift over HTTP: /api/traces. I guess where this breaks down for my organization is that we don't use the jaeger agent, but rather a third party one that fails when we use this combination of values.

I've done some investigation on other otel languages:

  • Java - it looks like it only supports grpc
  • Javascript - Namely is already successfully sending metrics to our agent (It looks like otel js is using the jaeger-client npm package, which just uses the endpoint as-is):
const exporter = new JaegerExporter({
  endpoint: 'http://our-trace-collector:9080/v1/trace',
});
  • Golang - according to their readme and docs, the endpoint can be specified with a path (OTEL_EXPORTER_JAEGER_ENDPOINT defaults to http://localhost:14268/api/traces), and looking through the code, it just uses the endpoint value specified
  • Ruby - readme and code indicate that they export to the URL specified in the env var as-is

I haven't looked through any of the other languages, but it does seem that my change is more consistent with at least a few of the other languages that otel supports (and incidentally all the ones my Company uses 😄).

Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

One other thing I forgot to mention is that the behavior in this repo is different from the OpenTracing jaeger client (which we're migrating from). It also just used the endpoint property/env-var as-is.
If you want to keep the behavior as-is, would you have a problem with me adding a new configuration option to set the path? Right now there is no way for me to use jaeger with open telemetry in my organization for .net. That is the problem I'm trying to solve, and I'm not terribly concerned about how to solve it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Anyway, I opened an issue in the otel spec repo: open-telemetry/opentelemetry-specification#2331

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Now that it looks like the spec will be updated to make it clear that the endpoint should include the path, how do you feel about this pr @pellared and @cijothomas (also, do I need to do something to kick off the build)?

Copy link
Member

Choose a reason for hiding this comment

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

@abe545 In general I prefer the approach of your PR (this is also how I implemented it in OTel Go SDK some time ago 😄). The change is not really breaking from the perspective as there was no stable release.

Copy link
Member

@cijothomas cijothomas left a comment

Choose a reason for hiding this comment

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

Might be breaking, so want to make sure we are okay with this.
https://github.com/open-telemetry/opentelemetry-dotnet/pull/2847/files#r799001655

@codecov
Copy link

codecov bot commented Feb 11, 2022

Codecov Report

Merging #2847 (1f7ec6a) into main (1dec9bd) will increase coverage by 0.15%.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #2847      +/-   ##
==========================================
+ Coverage   83.86%   84.01%   +0.15%     
==========================================
  Files         254      254              
  Lines        8943     8942       -1     
==========================================
+ Hits         7500     7513      +13     
+ Misses       1443     1429      -14     
Impacted Files Coverage Δ
...Exporter.Jaeger/Implementation/JaegerHttpClient.cs 91.66% <100.00%> (+47.66%) ⬆️
...Telemetry.Exporter.Jaeger/JaegerExporterOptions.cs 100.00% <100.00%> (ø)
...nTelemetry.Exporter.Jaeger/Implementation/Batch.cs 100.00% <0.00%> (+5.55%) ⬆️

@abe545 abe545 requested a review from cijothomas February 15, 2022 17:31
@github-actions
Copy link
Contributor

This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or Pushing will instruct the bot to automatically remove the label. This bot runs once per day.

@github-actions github-actions bot added the Stale Issues and pull requests which have been flagged for closing due to inactivity label Feb 23, 2022
@abe545
Copy link
Contributor Author

abe545 commented Feb 23, 2022

This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or Pushing will instruct the bot to automatically remove the label. This bot runs once per day.

@cijothomas Is there any chance you can take a look at this pr again before github closes it?

@github-actions github-actions bot removed the Stale Issues and pull requests which have been flagged for closing due to inactivity label Feb 24, 2022
@cijothomas
Copy link
Member

@abe545 The change looks good to me. Please address the following before merge:

  1. Please update changelog to include this. (highlight that this will break previous rc users, so they need to take action).
  2. Update PR Description to include the relevant Spec links.

@cijothomas cijothomas dismissed their stale review February 24, 2022 18:14

dismissing old review.

@cijothomas cijothomas added this to the 1.2.0 milestone Feb 24, 2022
Copy link
Member

@CodeBlanch CodeBlanch left a comment

Choose a reason for hiding this comment

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

LGTM

@abe545
Copy link
Contributor Author

abe545 commented Feb 24, 2022

@abe545 The change looks good to me. Please address the following before merge:

  1. Please update changelog to include this. (highlight that this will break previous rc users, so they need to take action).
  2. Update PR Description to include the relevant Spec links.

Thanks @cijothomas! I updated the changelog and PR comment - please let me know if you'd like me to make any other changes

@cijothomas
Copy link
Member

@abe545 Could you merge the latest main to this as well?

@cijothomas cijothomas merged commit 13e721d into open-telemetry:main Feb 24, 2022
@abe545 abe545 deleted the add-configurable-path-to-jaeger-exporter branch February 24, 2022 22:52
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.

Allow us to specify the path to post telemetry to in the JaegerHttpClient
6 participants