-
Notifications
You must be signed in to change notification settings - Fork 727
Configurability of OpenTelemetry instrumentation #2299
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
Comments
This issue is stale because it has been open 90 days with no activity. Remove the |
Just came across the issue of not seemingly being able to disable the elasticsearch instrumentation. |
Semi-related: #2583 |
@JoshMock Another thing to consider, is being able to disable dynamically. We are looking at central config support for our EDOT SDKs and one of the considered central config options is a way to disable instrumentations once the app is running. However, I'm fine with that being a separate issue (let me know). Mostly I think there is a clear need for being able to statically disable the native OTel instrumentation, so getting something for that is a good first step. Also let me know if you'd like an API proposal for what dynamic config might look like. I don't know if the ES |
Updated ref to Java ES client configurability of its OTel instrumentation: https://www.elastic.co/docs/reference/elasticsearch/clients/java/setup/opentelemetry#_configuring_the_opentelemetry_instrumentation |
🚀 Feature Proposal
Native OpenTelemetry instrumentation is being added as part of #2267
From review of part of that work:
It would be good to provide some configurability of the OTel instrumentation.
Similar to how the older diagnostics events can be configured via
TransportOptions.diagnostic
, there are a couple things that might be nice to be configurable:enabled
, in the context of an instrumentation.suppressInternalInstrumentation
.AFAIK there aren't any other Node.js libraries that have native OTel instrumentation yet, so there isn't prior art on exactly what to name OTel-related config. Perhaps having this in
@elastic/transport
:and the equivalent in
interface ClientOptions
in@elastic/elasticsearch
.I'm suggesting they get grouped under a "opentelemetry." namespace, because there could be requests for more configuration options as well. For example, see the instrumentation-aws-sdk and instrumentation-mongoose links above.
The text was updated successfully, but these errors were encountered: