fix bug with broker parallel merge metrics emitting#13420
Conversation
…ast/slow partition time metrics
rohangarg
left a comment
There was a problem hiding this comment.
Thanks for the changes Clint! Left some comments, also could you please add some tests for the new metrics you've added?
|
I'm not sure it makes sense to add tests to make the coverage bot happy since these metrics are not emitted by default and tests seem pointless. Specifically, its complaining about these two files: the first of which just has no-ops which do nothing, and the latter just delegate to the underlying metrics. |
rohangarg
left a comment
There was a problem hiding this comment.
+1 on the coverage check failing just because of technicality
LGTM once the second phase passes. Thanks for initiating it
|
@clintropolis I guess these metrics are enabled by default if
|
|
Okay for future readers, we did not enable the metrics by default: since this generates a ton of metrics per query. |
Description
Heh, I left out the call to
.emiton the broker parallel merge pool metrics so they just get reported into thin air. This PR fixes this so that they now exist and look something like this (when wired up to aQueryMetricsimplementation that actually emits them, they are currently off by default):I've also added three new metrics, one for total 'wall' time of the sequence from construction to being totally consume, and one each for the time spent waiting for the fastest and slowest partitions to initialize (fetch the first batch of results to begin work). The three of these should provide some additional insight into how time was spent by the tasks on the pool to accompany the existing set of metrics (which actually exist now).
Release note
This PR has: