SDK Resource #846
SDK Resource #846
Conversation
mwear
requested review from
bg451,
dyladan,
markwolff,
mayurkale22,
obecny,
OlivierAlbertini,
rochdev and
vmarchaud
as code owners
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
|
| /** The name of the telemetry library. */ | ||
| NAME: 'library.name', | ||
| NAME: 'telemetry.sdk.name', |
There was a problem hiding this comment.
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.
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.
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.
I can go back to what is currently spec'd. Would you prefer that for this PR?
There was a problem hiding this comment.
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.
I think no need to export internal assertion util,
There was a problem hiding this comment.
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.
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.
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.
why not add it to @opentelemetry/test-utils?
There was a problem hiding this comment.
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.
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.
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.
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).
|
@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.sdksemantic conventions that are proposed as a replacement for thelibraryconventions that previously represented the SDK resource (Clarify telemetry library resource attributes opentelemetry-specification#494)