-
Notifications
You must be signed in to change notification settings - Fork 487
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
traces of resource detectors being sent #2320
Comments
@pichlermarc since we agreed on suppress tracing in the implicated detectors and these are placed in |
@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 :) |
Clarification on that. Azure detectors are already implementing |
Reverting auto close done in #2328 |
What happened?
Steps to Reproduce
@opentelemetry/auto-instrumentations
OTEL_TRACES_EXPORTER=console \ OTEL_NODE_RESOURCE_DETECTORS=all \ node --require '@opentelemetry/auto-instrumentations-node/register' index.js
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
The text was updated successfully, but these errors were encountered: