KAFKA-9441: Cleanup Streams metrics for removed task commit latency metrics#8356
Conversation
|
I thought we are still going to retain the thread-level commit-latency, by making its own recording calls than relying on its children metrics (which are removed now), is that the case? Or are you planning to add it in another PR? I’d suggest we use one PR to do this refactoring rather than two PRs to remove it and then add it back. |
We do. As explained in the PR description:
|
|
Maybe I'm missing sth here. Where do we record the |
|
LGTM! My previous comment was actually void so it should be good to go. |
55eb45f to
b69f3ab
Compare
|
Rebased to resolve merge conflict. Retest this please. |
|
Java. 8 passed. Retest this please. |
|
Retest this please |
|
Java 8 passed: Retest this please. |
|
Java 8: |
|
|
||
| verify(StreamsMetricsImpl.class, streamsMetrics); | ||
| assertThat(sensor, is(expectedSensor)); | ||
| } |
There was a problem hiding this comment.
req: Please keep this test and do only remove the following part (and of course the parts that become obsolete):
StreamsMetricsImpl.addAvgAndMaxToSensor(
expectedSensor,
TASK_LEVEL_GROUP,
tagMap,
operationLatency,
avgLatencyDescription,
maxLatencyDescription
);
Follow up to #8218 (KIP-447) that remove usage of task commit latency sensor. However, the underlying metrics were still registered, even if unused. This PR does the follow up cleanup to remove the metrics entirely.
The thread level commit metrics are no rollups but tracked individually and thus are not affected.
Call for review @cadonna @abbccdda @guozhangwang