-
Notifications
You must be signed in to change notification settings - Fork 891
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
Add OTEL_SERVICE_NAME
environment variable
#1677
Conversation
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.
@SergeyKanzhelev You seemed to have a strong opinion on #709, so please take a look at this proposal.
@@ -32,6 +32,7 @@ For example, the value `12000` indicates 12000 milliseconds, i.e., 12 seconds. | |||
| Name | Description | Default | Notes | | |||
| ------------------------ | ------------------------------------------------- | --------------------------------- | ----------------------------------- | | |||
| OTEL_RESOURCE_ATTRIBUTES | Key-value pairs to be used as resource attributes | | See [Resource SDK](./resource/sdk.md#specifying-resource-information-via-an-environment-variable) for more details. | | |||
| OTEL_SERVICE_NAME | Sets the value of the [`service.name`](./resource/semantic_conventions/README.md#service) resource attribute | | If `service.name` is also provided in `OTEL_RESOURCE_ATTRIBUTES` then `OTEL_SERVICE_NAME` takes precedence. | |
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.
Should we also add OTEL_SERVICE_VERSION
or add a note that service.version
can be set via OTEL_RESOURCE_ATTRIBUTES
?
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 usually prefer to keep PR scope small, if possible. This PR solves one specific issue. I am happy to file a follow-up one, if you feel this is needed :)
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.
That's reasonable. If we add it, it would ideally be in the same spec version, however, so SDK maintainers/implementers can tackle this tightly coupled feature at once. The next release is scheduled for early June, so we should be good here, as the follow-up should be as uncontroversial as this PR.
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.
Same as #1677 (comment): I don't think the service version is used often enough to warrant it's own attribute. We did receive user requests for service.name AFAIK, but not for any others.
Co-authored-by: Armin Ruech <[email protected]>
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 am ok with the suggestion, but before merging, let's clarify whether environment variable should take precedence over the value set in code.
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.
Question that is not answer:
Why service name is treated differently than any other resource attribute?
|
Based on #1677 (comment) I will submit the PR about |
@bogdandrutu as discussed during spec SIG meeting, I tried to stress the significance of this specific attribute. Please check my changes in |
@@ -23,6 +23,8 @@ release. | |||
|
|||
### SDK Configuration | |||
|
|||
- Add `OTEL_SERVICE_NAME` environment variable. ([#1677](https://github.com/open-telemetry/opentelemetry-specification/pull/1677)) |
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 have never heard of anyone using namespace (but maybe it just works so well that there are no questions?). instance.id has is currently IMHO too vaguely defined to be useful, as discussed in #1034. So the service name is IMHO definitely the most useful one.
Ping @bogdandrutu |
Co-authored-by: Armin Ruech <[email protected]>
@bogdandrutu ;) |
Personally still believe we should not make this special but I would let the majority decide, I would not block but disagree with the change
@open-telemetry/technical-committee Anybody feeling confident enough to merge this? |
@bogdandrutu Thanks for going on with the compromise, really appreciated. Merging (we will see in the long run how things unfold! ;) ) |
* Add OTEL_SERVICE_NAME environment variable Closes open-telemetry#709
Closes #709
Changes
Add
OTEL_SERVICE_NAME
environment variable to SDK configuration