feat(v2): add ClientMetrics initialization core#473
feat(v2): add ClientMetrics initialization core#473westarle merged 2 commits intogoogleapis:mainfrom
Conversation
quartzmo
changed the title
This PR introduces the foundational configuration parameters and data structures for OpenTelemetry duration metrics in Google Cloud Go client libraries. Historically, generated Go clients lacked a straightforward architectural injection point for OpenTelemetry instruments. This leads to gaps in measuring time spent inside the `gax.Invoke` retry loop. To address this, this PR does the following: * Defines semantic OpenTelemetry constants that match our cross-language OpenTelemetry instrumentation specifications. * Defines the mapping constants generated clients will use to provide library-specific details to the underlying instrument initialization. * Provides the `NewClientMetrics` constructor to act as the central initialization registry for the OTel Meter and Float64Histogram. We strictly validate against the standard semantic convention keys to ensure backwards compatibility while resolving versions.
westarle
force-pushed
the
westarle/metrics-clientmetrics-core-v4
branch
from
fd956d1 to
2c9b435
Compare
shollyman
left a comment
shollyman
left a comment
There was a problem hiding this comment.
Left one more comment for consideration, but approving in the current state.
| } | ||
|
|
||
| provider := config.provider | ||
| if provider == nil { |
There was a problem hiding this comment.
nit: I see there's a number of these checks against config (clientMetricsOptions) that are variations of "if its not set, use this default".
One thing to consider is whether to add getter-style methods directly on the clientMetricsOptions struct that provide these defaults. It mostly down to how many consumers we expect to have read values from clientMetricsOptions, and whether consumers have special awareness or other side channels for data that inform how default values are generated.
Also, do we expect similar config options for the other observability features (tracing, logging)? Should we use a shared config type?
There was a problem hiding this comment.
One thing to consider is whether to add getter-style methods directly on the clientMetricsOptions struct
See #480
do we expect similar config options for the other observability features (tracing, logging)? Should we use a shared config type?
I was hoping to see what emerges from our design as we put it in practice and before we lift our 'experimental' flags. How big a pain is it to converge on a single type later?
2 participants
This PR introduces the foundational configuration parameters and data structures for OpenTelemetry duration metrics in Google Cloud Go client libraries.
NewClientMetricsconstructor to act as the central initialization registry for the OTel Meter and Float64Histogram.We strictly validate against the standard semantic convention keys to ensure backwards compatibility while resolving versions.