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
The existing Metrics SDK supports a MeterProvider API but the underlying components treat the Resource as part of the export Record and do not formally recognize a division between Meters. This issue outlines a proposal to solve this. The outcome will be that each:
metric.Descriptor no longer includes instrumentation name and version, nor Resource
metric/registry supports a UniqueMeterProvider that maintains a map of named MeterImpls.
metrics Export() includes additional SourceData (instrumentation name and version, schema URL, Resource)
sdk/metric/controller maintains once accumulator/checkpointer per Meter, exports them separately
OTLP exporter for metrics no longer needs to group data, is much simpler.
This is too much change for a single PR, but I have prototyped it in #2085. This issue will cover breaking up the draft PR into smaller pieces.
Another goal is met in the draft PR above, that metric.Descriptor could be moved out of the top-level metric package into a sub-package (possibly named "sdkapi"), as demonstrated in #2044.
The text was updated successfully, but these errors were encountered:
Discussed in the Go SIG meeting. The main objection to the draft PR #2085 is that it splits Metrics exports into one call per Meter. Instead, follow what's been done for Trace, export a slice of InstrumentationLibraryMetrics.
Next steps: I will continue with the refactoring proposed here in smaller PRs.
Remove instrumentation library and version from metric.Descriptor. Pass this information through a MeterProvider and store it in the metric Controller. Add registry.UniqueMeterProvider.
Create a metric/sdkapi subpackage and move Descriptor, InstrumentImpl, MeterImpl, SyncImpl, AsyncImpl, and a few other implementation-specific types into this package. These are the types that will survive regardless of which API design is chosen, as they support the current SDK's low-level interface shared by any API.
Remove Resource from the metric export Record.
Remove grouping from OTLP exporter, receive a slice of InstrumetationLibraryMetric recods.
The existing Metrics SDK supports a MeterProvider API but the underlying components treat the Resource as part of the export Record and do not formally recognize a division between Meters. This issue outlines a proposal to solve this. The outcome will be that each:
This is too much change for a single PR, but I have prototyped it in #2085. This issue will cover breaking up the draft PR into smaller pieces.
Another goal is met in the draft PR above, that metric.Descriptor could be moved out of the top-level metric package into a sub-package (possibly named "sdkapi"), as demonstrated in #2044.
The text was updated successfully, but these errors were encountered: