-
Notifications
You must be signed in to change notification settings - Fork 821
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
SDK Resource #846
SDK Resource #846
Conversation
Codecov Report
@@ Coverage Diff @@
## master #846 +/- ##
==========================================
+ Coverage 92.63% 94.81% +2.17%
==========================================
Files 251 252 +1
Lines 11057 11032 -25
Branches 1079 1063 -16
==========================================
+ Hits 10243 10460 +217
+ Misses 814 572 -242
|
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.
Added first pass comments, I am still trying to understand how to use in MeterProvider
and TracerProvider
.
/** The name of the telemetry library. */ | ||
NAME: 'library.name', | ||
NAME: 'telemetry.sdk.name', |
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.
Previous attributes names were aligned to the specs (see: https://github.com/open-telemetry/opentelemetry-specification/blob/948304ad9ddf754ca8308cd51f54c1e8ced5c7d2/specification/data-resource-semantic-conventions.md#library). Could you please help me to point corresponding specs issue/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.
The proposed changes are here: open-telemetry/opentelemetry-specification#494. Let me know if it's too early to adopt them.
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.
Found specs issue: open-telemetry/opentelemetry-specification#484, I would have made this change in separate PR because specs PR is still not merged.
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 can go back to what is currently spec'd. Would you prefer that for 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.
I think it is fine for now, you already made significant efforts to change in multiple places I don't want you to change again. Also, specs PR looks in good shape (3 ppl already approved it).
@@ -16,3 +16,4 @@ | |||
|
|||
export { Resource } from './Resource'; | |||
export * from './constants'; | |||
export * from './resource-assertions'; |
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 no need to export internal assertion util,
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.
Both this and #846 (comment) are so that other packages can use the utilities to validate resources. Currently this is used in tests in opentelemetry-web, opentelemetry-node, opentelemetry-metrics, opentelemetry-tracing. Let me know if this should 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.
I see, but I am not sure if this is the right approach. Would like to hear from others.
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's probably sufficient for me to verify that a resource exists on the proper telemetry objects, without having to assert that it conforms to a specific semantic convention. I can go that route if it'd be better. Just let me know.
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.
why not add it to @opentelemetry/test-utils
?
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 will create a circular dependency that I'm not sure how to resolve. If the resource-assertions move to test-utils, they will have a dependency on opentelemetry-resources. opentelemetry-resources will want to use the resource-assertions, so it will depend on test-utils. Leading to the dependency cycle opentelemetry/resources
-> opentelemetry/test-utils
-> opentelemetry/resources
.
@@ -14,16 +14,17 @@ | |||
* limitations under the License. | |||
*/ | |||
|
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.
Why this file moved to src/
from test/
?
@@ -24,6 +25,7 @@ import { DEFAULT_CONFIG, MeterConfig } from './types'; | |||
*/ | |||
export class MeterProvider implements types.MeterProvider { | |||
private readonly _meters: Map<string, Meter> = new Map(); | |||
readonly resource: Resource = Resource.createTelemetrySDKResource(); | |||
readonly logger: types.Logger; | |||
|
|||
constructor(private _config: MeterConfig = DEFAULT_CONFIG) { |
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.
What do you think about making resource
part of MeterConfig with default value either to Resource.empty()
or Resource.createTelemetrySDKResource()
? This way users (and independent developers) can customize the 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 went with Resource.createTelemetrySDKResource()
as the default. When we have resource auto detection, it will be updated to use that (e.g. Resource.detectAll()
or similar).
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
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.
👍
@open-telemetry/javascript-approvers we need more reviews on this one! |
* export resource to exporters * update Zipkin and Stackdriver exporter to use Resource * chore: remove redundant dependency * update Collector exporter to use Resource * rebase with #846 * minor * fix collector resource * fix build
Which problem is this PR solving?
Short description of the changes
telemetry.sdk
semantic conventions that are proposed as a replacement for thelibrary
conventions that previously represented the SDK resource (Clarify telemetry library resource attributes opentelemetry-specification#494)