-
Notifications
You must be signed in to change notification settings - Fork 542
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 |
Interestingly after update the example to
so this issue needs a bit more investigation and work |
new version of GCP detector is not released yet. #2420 |
@david-luna The GCP detector is released node:
const http = require('http');
const url = 'http://www.google.com/';
const clientReq = http.request(url, function (cres) {
console.log('client response: %s %s', cres.statusCode, cres.headers);
const chunks = [];
cres.on('data', function (chunk) {
chunks.push(chunk);
});
cres.on('end', function () {
const body = chunks.join('');
console.log(
'client response body (%d bytes): "%s..."',
Buffer.byteLength(body),
JSON.stringify(body.slice(0, 40)).slice(1, -1)
);
});
});
clientReq.end(); Running that:
Results in this telemetry (to mockoltpserver):
Perhaps the gaxios call being made by the gcp-metadata dep is being invoked in a way that breaks the context tracking? I'm guessing. |
Looking at GcpDetector, here is what I think is happening: class GcpDetector implements DetectorSync {
detect(_config?: ResourceDetectionConfig): IResource {
const attributes = context.with(suppressTracing(context.active()), () =>
this._getAttributes()
);
return new Resource({}, attributes);
}
private async _getAttributes(): Promise<ResourceAttributes> {
if (!(await gcpMetadata.isAvailable())) {
diag.debug('GcpDetector failed: GCP Metadata unavailable.');
return {};
}
const [projectId, instanceId, zoneId, clusterName, hostname] =
await Promise.all([
this._getProjectId(),
this._getInstanceId(),
this._getZone(),
this._getClusterName(),
this._getHostname(),
]);
// ... When The GcpDetector then goes into I don't have an idea for a fix yet. |
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: