smjn commented on code in PR #18174:
URL: https://github.com/apache/kafka/pull/18174#discussion_r1887252720
##########
share-coordinator/src/main/java/org/apache/kafka/coordinator/share/metrics/ShareCoordinatorMetrics.java:
##########
@@ -153,4 +158,31 @@ public void record(String sensorName) {
globalSensors.get(sensorName).record();
}
}
+
+ public void recordPrune(double value, TopicPartition tp) {
+ pruneMetrics.computeIfAbsent(tp, k -> new ShareGroupPruneMetrics(tp))
+ .pruneSensor.record(value);
+ }
+
+ private class ShareGroupPruneMetrics {
+ private final Sensor pruneSensor;
+
+ ShareGroupPruneMetrics(TopicPartition tp) {
+ String sensorNameSuffix = tp.toString();
+ Map<String, String> tags = Map.of(
+ "topic", tp.topic(),
+ "partition", Integer.toString(tp.partition())
+ );
+
+ pruneSensor =
metrics.sensor(SHARE_COORDINATOR_STATE_TOPIC_PRUNE_SENSOR_NAME +
sensorNameSuffix);
+
+ pruneSensor.add(
+ metrics.metricName("last-pruned-offset",
Review Comment:
The serves as proof of the record pruner working from the monitoring
perspective. On the off chance that we suspect that the pruner has deleted
overwhelming amount of data - this could prove useful data. Secondly, in share
coordinator terminology this is just an offset and we are not privy to what the
core replicaManger and partition implementation use.
This is capturing the value of the offset for which the delete call was
successful. Further details can be ascertained from the broker logs.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
