Current metrics and instrumentation do not provide high visibility on this library behavior.
For server side use of this library (i.e. apm-server) this leads to blind spots that decrease troubleshooting and root cause analysis capabilities.
Approach
The proposed solution is to adopt the OpenTelemetry Metrics SDK in this library and its dependencies to gather relevant runtime metrics.
To avoid any performance penalty from this change we can default to use the global OpenTelemetry MeterProvider, which is either set by the library user or defaults to a no-op implementation.
Thank you for this proposal, I've taken this item to the team to discuss if further for a possible clients-team wide integration of metrics.
Closing this for now!
Status Quo
This library expose some internal metrics from https://github.com/elastic/elastic-transport-go, through the
BaseClient.Metrics
method.Problem
Current metrics and instrumentation do not provide high visibility on this library behavior. For server side use of this library (i.e. apm-server) this leads to blind spots that decrease troubleshooting and root cause analysis capabilities.
Approach
The proposed solution is to adopt the OpenTelemetry Metrics SDK in this library and its dependencies to gather relevant runtime metrics.
To avoid any performance penalty from this change we can default to use the global OpenTelemetry MeterProvider, which is either set by the library user or defaults to a no-op implementation.