-
Notifications
You must be signed in to change notification settings - Fork 775
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
Allow the jaeger exporter path to be configured #2847
Conversation
test/OpenTelemetry.Exporter.Jaeger.Tests/OpenTelemetry.Exporter.Jaeger.Tests.csproj
Outdated
Show resolved
Hide resolved
test/OpenTelemetry.Exporter.Jaeger.Tests/OpenTelemetry.Exporter.Jaeger.Tests.csproj
Outdated
Show resolved
Hide resolved
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.
LGTM with minor suggestions.
/// </summary> | ||
public Uri Endpoint { get; set; } = new Uri("http://localhost:14268"); | ||
public Uri Endpoint { get; set; } = new Uri(DefaultJaegerEndpoint); |
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 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.
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.
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.
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.
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!
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 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.
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.
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 theendpoint
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 tohttp://localhost:14268/api/traces
), and looking through the code, it just uses theendpoint
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 😄).
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.
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.
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.
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.
Anyway, I opened an issue in the otel spec repo: open-telemetry/opentelemetry-specification#2331
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.
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)?
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.
@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.
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.
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 Report
@@ 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
|
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? |
@abe545 The change looks good to me. Please address the following before merge:
|
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.
LGTM
Thanks @cijothomas! I updated the changelog and PR comment - please let me know if you'd like me to make any other changes |
@abe545 Could you merge the latest main to this as well? |
Fixes #2821.
Changes
Please provide a brief description of the changes here.
This makes the
JaegerExporter
treat the configurableEndpoint
in its options the same way theZipkinExporter
does. Basically, instead of hardcoding/api/traces
as a path toPOST
the trace data to, it is now assumed to be a part of theEndpoint
. 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:
CHANGELOG.md
updated for non-trivial changes