Add metrics for PeriodicMetricReader #8038
Conversation
|
|
||
| /** | ||
| * Sets the {@link MeterProvider} to export metrics about this {@link PeriodicMetricReader} to. | ||
| * Automatically called by the meter provide the reader is registered to. |
There was a problem hiding this comment.
Couldn't think of a reason to not do this
| try { | ||
| metricData = collectionRegistration.collectAllMetrics(); | ||
| } catch (Throwable t) { | ||
| error = t.getClass().getName(); |
There was a problem hiding this comment.
Not sure if this is actually possible in practice
There was a problem hiding this comment.
Right, since we also suppress exceptions for observable instruments. In that case this is overkill so I removed it
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #8038 +/- ##
============================================
+ Coverage 90.16% 90.24% +0.07%
- Complexity 7478 7608 +130
============================================
Files 834 839 +5
Lines 22559 22846 +287
Branches 2239 2276 +37
============================================
+ Hits 20341 20618 +277
- Misses 1515 1519 +4
- Partials 703 709 +6 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
|
||
| private Scheduled() {} | ||
|
|
||
| void setMeterProvider(MeterProvider meterProvider) { |
There was a problem hiding this comment.
| void setMeterProvider(MeterProvider meterProvider) { | |
| private void setMeterProvider(MeterProvider meterProvider) { |
| } | ||
|
|
||
| /** Reflectively sets the meter provider for a PeriodicMetricReader to export metrics to. */ | ||
| public static void setMeterProvider( |
There was a problem hiding this comment.
I think this is the only meter provider setter which isn't public. Any reason?
There was a problem hiding this comment.
Yeah, conceptually it's important to "wire metrics into traces, logs", but there doesn't seem to be a need to support "wire metrics into metrics", and instead we just automatically call this internally.
There's also a different inconsistency in setMeterProvider being on the reader, not reader builder. The latter would have the same chicken-egg issue as ConfigProvider, but in a public API so even worse. So if keeping them all public, we would make setMeterProvider on the reader (not builder) public, but at that point it felt fine to just keep it private
That being said, I realized that MetricExporterBuilder does have setMeterProvider, and our code is doing the atomic reference dance to use it. I would be surprised if anyone in the wild is calling that method though since the ergonomics look poor
There was a problem hiding this comment.
Could have the internal reflection API in SdkMeterProvider to avoid any public API surface area. SdkMeterProviderUtil has historically functioned as a mechanism for users to access experimental APIs which are intended to eventually be public / user facing, but not quite ready yet. With this, it seems like there is no reason for the method to ever be promoted to the public API.
There was a problem hiding this comment.
Ah good call, moved it
|
|
||
| /** | ||
| * Sets the {@link MeterProvider} to export metrics about this {@link PeriodicMetricReader} to. | ||
| * Automatically called by the meter provider the reader is registered to. |
There was a problem hiding this comment.
Makes me think that SdkTracerProvider, SdkLoggerProvider should cascade set meter provider on all child components (i.e. BatchSpanProcessor, exporters, etc). Problem is, the setMeterProvider methods on child components are on the builders... Probably could have had something more elegant with some foresight. Too bad.
2 participants
This adds the last SDK metric, for the metric reader. Been a while since previous PR since I forgot about it 😅
https://opentelemetry.io/docs/specs/semconv/otel/sdk-metrics/#metric-otelsdkmetric_readercollectionduration