-
Notifications
You must be signed in to change notification settings - Fork 36
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
fix: disabling aws sdk instrumentation #866
Conversation
d0b80b7
to
5dcb4b1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! 👍 👍
I left some rambling comments (as always :-) ) which are mostly a matter of taste and all completely optional.
expect(activateStubGrpc).to.not.have.been.called; | ||
expect(activateStubGrpcJs).to.have.been.called; | ||
expect(activateStubKafkaJs).to.have.been.called; | ||
expect(activateStubRdKafka).to.have.been.called; | ||
expect(activateAwsSdkv2).to.have.been.called; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thought: We could use the same pairs of init and activate checks as in the test case 'deactivate instrumentation via config' here. On the other hand, the test setup only deactivates grpc
, so to be honest, I do not remember why we check for all the other instrumentations here as well 🤔 I think just having expectations for grpc
and maybe grpcjs
for their respective init and activate methods would be enough?
it('skip init step when instrumentation disabled', () => { | ||
initAndActivate({ tracing: { disabledTracers: ['grpcjs', 'kafkajs'] } }); | ||
initAndActivate({ tracing: { disabledTracers: ['grpcjs', 'kafkajs', 'aws-sdk/v2'] } }); | ||
expect(initStubKafkaJs).not.to.have.been.called; | ||
expect(initStubGrpcJs).not.to.have.been.called; | ||
expect(initAwsSdkv2).to.not.have.been.called; | ||
expect(initStubGrpc).to.have.been.called; | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
though: We could merge this into 'deactivate instrumentation via config' instead of having a separate test case, see above.
refs 139073
This is
a) not documented https://www.ibm.com/docs/en/instana-observability/current?topic=nodejs-collector-configuration#disabling-individual-tracers
b) customers would need to use
aws/sdk/v2/index
, which is really not a good designThis is a first fix to this.
In the next major release we could drop the support for the old syntax. The major ticket contains it already.
This PR ensures that we still support the old notation, because it could be that some customers are using this.
Another addition could be: add an optional function like
handleDisablingInstrumentation
and each instrumentation can handle it on it's own if wished e.g. aws sdk could disable only certain instrumentations. Right now users can only disable the while library.