feat(opentelemetry-sdk-node): set resources and log provider for experimental start#6152
feat(opentelemetry-sdk-node): set resources and log provider for experimental start#6152maryliag wants to merge 18 commits intoopen-telemetry:mainfrom
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #6152 +/- ##
==========================================
- Coverage 95.40% 95.40% -0.01%
==========================================
Files 317 318 +1
Lines 9440 9546 +106
Branches 2188 2218 +30
==========================================
+ Hits 9006 9107 +101
- Misses 434 439 +5
🚀 New features to boost your workflow:
|
JamieDanielson
left a comment
There was a problem hiding this comment.
Took a pass through this and added some notes.
| config: ConfigurationModel, | ||
| sdkOptions: SDKOptions, | ||
| resource: Resource | undefined | ||
| ): LoggerProvider | undefined { |
There was a problem hiding this comment.
| ): LoggerProvider | undefined { | |
| ): LoggerProvider { |
Is there a scenario where setupLoggerProvider would be undefined? setupResource only returns a Resource not undefined
There was a problem hiding this comment.
if you don't have any log provider on env variables or config file, there is no logger provider to be setup, so it will return undefined
setupResource have a default value for resources, this is why it doesn't have the option to return undefined
| } else if (exporter.console) { | ||
| return new ConsoleLogRecordExporter(); | ||
| } | ||
| diag.warn(`Unsupported Exporter value. Using OTLP http/protobuf.`); |
There was a problem hiding this comment.
🤔 If someone uses a config file but neglects to specify a valid exporter (otlp_http, otlp_grpc, otlp_file/development(soon), console)... should we default an exporter for them or should we consider it a noop because it's invalid? It's not clear to me.
There was a problem hiding this comment.
I believe I saw the default should be otlp_http in this case, so I kept at that.
There was a problem hiding this comment.
Sorry on the delay in coming back to this. In re-reviewing the spec for required and null properties, my understanding is that if a field is required it must be a valid entry to be used and otherwise it is invalid.
When a property is required, the key must be included in the object or the configuration is invalid.
I'll take a look at the go and java implementations to see how they handle it
|
I copied the majority of tests form the original sdk tests, to make sure the behaviour didn't change with the new function |
|
This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days. |
|
This looks good! All CI passing and the implementation looks right. Could can you rebase? The PR is 123 commits behind and has a CHANGELOG conflict. Happy to help review once rebased 😄 |
|
I'll close this one in favour of a new PR. I made quite a few changes to be compatible with rc3, so this PR needs a lot of updates. I'll open the new updated PR soon :) |
|
New PR: #6407 |
Fixes #5822