Remove ServiceName from OtlpExporterOptions#1557
Remove ServiceName from OtlpExporterOptions#1557cijothomas merged 7 commits intoopen-telemetry:masterfrom
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1557 +/- ##
==========================================
- Coverage 81.00% 80.98% -0.02%
==========================================
Files 237 237
Lines 6453 6449 -4
==========================================
- Hits 5227 5223 -4
Misses 1226 1226
|
|
I think if we're going to remove from Otlp, we should also remove from Zipkin & Jaeger. Keep it consistent. |
Agree. My motivation to have this option removed is: |
If not set, we currently fallback to a default. We keep the same behavior. |
| } | ||
| } | ||
|
|
||
| if (!processResource.Attributes.Any(kvp => kvp.Key == Resource.ServiceNameKey)) |
There was a problem hiding this comment.
Shouldn't we keep the current behavior of falling back to DefaultServiceName?
There was a problem hiding this comment.
Ah ok makes sense, wasn't sure about that. Will make the change first thing tomorrow.
Oddly, Zipkin actually does specify the ability for configuring a fall back. Jaeger does not. See:
|
Okay, so lets keep it in Zipkin. Add back to OTLP,Jaeger when spec requires it. For Zipkin, can you also confirm that the Zipkin options one is the fallback one, and Resource is always taken, if available. |
| using OpenTelemetry; | ||
| using OpenTelemetry.Resources; |
There was a problem hiding this comment.
I had to add both OpenTelemetry and OpenTelemetry.Resources here because the AddService extension method is in the OpenTelemetry namespace. Was this intentional? Relates to #1541 in that I think we should aim to be consistent.
There was a problem hiding this comment.
this requires some changes. Lets merge this PR, and follow up to make it consistent.
There was a problem hiding this comment.
@alanwest @cijothomas I put the extensions into OpenTelemetry namespace instead of OpenTelemetry.Resources so that people could use the TracerBuilderExtension.ConfigureResource extension without an additional namespace having to be imported. But that ended up being removed so we can probably move into OpenTelemetry.Resources without any issues, people will just need OpenTelemetry.Trace & OpenTelemetry.Resources in their startup usings (if they want to use ResourceBuilder). Or we put all the builders into OpenTelemetry namespace so people only need that single using in their startup? 🤷
There was a problem hiding this comment.
Yes we discussed this in todays SiG meeting as well.. Lets address the overall namespace changes separate from this PR.
There was a problem hiding this comment.
Ok, good to know the history here. We can continue the namespace conversation separate from this PR.
There was a problem hiding this comment.
Doh, it backfired on me! Just updated some code to RC1 and I had to add using OpenTelemetry because of this. I ended up with:
using OpenTelemetry;
using OpenTelemetry.Resources;
using OpenTelemetry.Trace;All being required to configure TracerProvider w/ Resources in startup code. That sucks. Sorry!
3 participants
As discussed with @cijothomas, removing ServiceName from OtlpExporterOptions since it is not in the specification.
Opening the PR now to get people's eyes on it with the caveat that I have not yet experimented with things to see what the experience is like when
service.namedoes not get set.@cijothomas This was recently done by @CodeBlanch in #1420 per an ask from the community. I'd be good with just keeping it, but I can also see the argument that we should push this through the spec. What do you all think?
There is a proposal for an environment configuration open-telemetry/opentelemetry-specification#709.
Changes
Please provide a brief description of the changes here.
For significant contributions please make sure you have completed the following items:
CHANGELOG.mdupdated for non-trivial changes