Open david-luna opened 2 months ago
@pichlermarc since we agreed on suppress tracing in the implicated detectors and these are placed in opentelemetry-js-contrib
repo. Should I move the issue there?
Should I move the issue there?
@david-luna I think, yes.
@david-luna I can see Azure VM detector trace there as well, are you refactoring all detectors to use latest interface and then fixing the issue suppressing the trace in the resources package? sorry if you already clarified this but is easy to get lost with all the referenced issues and PRs here.
@hectorhdzg that's correct :)
@hectorhdzg that's correct :)
Clarification on that. Azure detectors are already implementing DetectorSync
interface so I'm going to start the PR to suppress tracing for them :)
Reverting auto close done in #2328
What happened?
Steps to Reproduce
@opentelemetry/auto-instrumentations
Expected Result
Exported spans should belong only to application traces and not to any internal activity of the SDK or its components.
Actual Result
HTTP spans are exported for the requests done by GCP while it's doing its detection logic.
Additional Details
This is related to open-telemetry/opentelemetry-js#1989 since the instrumentations do the patching when constructor is called (before the detectors being used). IMO a user would expect to start collecting/exporting traces once the SDK has completely initialized and also to only export traces/logs/metrics activity related to the application. Self instrumentation would be a feature that could be activated or not.
Application Code
package.json
Relevant log output