You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
A way to disable the OTel instrumentation. Users of an OTel SDK will be somewhat used to the ability to disable particular instrumentations. Usually this config var is called enabled, in the context of an instrumentation.
A way to suppress child HTTP spans that will be created under the Elasticsearch spans. There are a few existing OTel instrumentations that have this same situation, e.g.: instrumentation-aws-sdk, instrumentation-mongoose. Typically this config var is a boolean called 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:
🚀 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: