feat(api-metrics): async instruments spec compliance - #2569
Conversation
Codecov Report
@@ Coverage Diff @@
## main #2569 +/- ##
==========================================
+ Coverage 93.08% 93.10% +0.01%
==========================================
Files 123 123
Lines 4761 4758 -3
Branches 1061 1061
==========================================
- Hits 4432 4430 -2
+ Misses 329 328 -1
|
# Conflicts: # experimental/packages/opentelemetry-api-metrics/src/NoopMeter.ts # experimental/packages/opentelemetry-api-metrics/src/types/BatchObserverResult.ts # experimental/packages/opentelemetry-api-metrics/src/types/Metric.ts # experimental/packages/opentelemetry-sdk-metrics-base/test/Meter.test.ts
| labels?: Labels, | ||
| ) => Observation; | ||
| } | ||
| export type ObservableBase = Record<never, never>; |
There was a problem hiding this comment.
Record<never, never> only allows the empty object correct?
There was a problem hiding this comment.
It declares an object type, and it can be extended to have any keys. The reason I use Record here is that the linter rules disallow empty interface interface ObservableBase {}.
| }; | ||
| } | ||
| } | ||
| export class NoopObservableBaseMetric extends NoopMetric implements ObservableBase {} |
There was a problem hiding this comment.
Does NoopMetric serve any purpose here or anywhere?
There was a problem hiding this comment.
Hm, the only use case can be observable instanceof NoopMetric. However, there are no API spec constraints on class hierarchy here, maybe we can remove it.
|
@dyladan const observable = meter.createObservableGauge('name', observableResult => {
observableResult.observe(100, { attr1: 'val' });
});
// we don't have to call `observable.observation(100)` anymore since there is no BatchObserverResult to consume them. |
# Conflicts: # experimental/packages/opentelemetry-api-metrics/src/types/Metric.ts # experimental/packages/opentelemetry-api-metrics/src/types/ObservableResult.ts # experimental/packages/opentelemetry-exporter-prometheus/test/PrometheusSerializer.test.ts # experimental/packages/opentelemetry-sdk-metrics-base/README.md
This comment has been minimized.
This comment has been minimized.
# Conflicts: # experimental/packages/opentelemetry-sdk-metrics-base/README.md # experimental/packages/opentelemetry-sdk-metrics-base/src/Meter.ts # experimental/packages/opentelemetry-sdk-metrics-base/src/ObservableBaseMetric.ts # experimental/packages/opentelemetry-sdk-metrics-base/src/ObservableResult.ts # experimental/packages/opentelemetry-sdk-metrics-base/test/Meter.test.ts
|
So we don't have an updated SDK implementation for the updated API yet and the tests for exporters are complaining about that. |
pirgeo
left a comment
There was a problem hiding this comment.
The changes look good to me, I just wonder: was the Observation not used before?
Do we need to ignore tests from exporters while we are working on the metrics api/sdk ? cc @dyladan |
It's being used in batch observers. And batch observers were removed in #2566. |
This comment has been minimized.
This comment has been minimized.
I think we should remove the exporters like we did the SDK. Let's talk about it in SIG |
|
@legendecas exporter tests are still failing for some reasons :/ |
|
@vmarchaud updated with exporters' changes removed since they are linked to a fixed version of api-metrics. |
Which problem is this PR solving?
Fixes #2550
Fixes #2551
Fixes #2553
Depends on #2566
Short description of the changes
ObservableBase.observationObservationfrom api-metricscallback(3rd parameter) withoptions(2nd parameteronMeter.createObservable*to markcallback` as a required parameter: a required parameter can not be placed after an optional parameter.labelofObservableResult.observeas optional.Type of change
Checklist: