jugomezv commented on code in PR #9977:
URL: https://github.com/apache/pinot/pull/9977#discussion_r1050886269
##########
pinot-common/src/main/java/org/apache/pinot/common/metrics/ServerGauge.java:
##########
@@ -45,7 +45,10 @@ public enum ServerGauge implements AbstractMetrics.Gauge {
// Dedup metrics
DEDUP_PRIMARY_KEYS_COUNT("dedupPrimaryKeysCount", false),
CONSUMPTION_QUOTA_UTILIZATION("ratio", false),
- JVM_HEAP_USED_BYTES("bytes", true);
+ JVM_HEAP_USED_BYTES("bytes", true),
+ // Consumer lag metrics
+ LLC_RECORDS_LAG("recordCount", false),
+ LLC_AVAILABILITY_LAG_MS("availabilityLagMs", false);
Review Comment:
We had experimented with similar approach about a month back internally and
decided against having a lag metric for partition and come up instead with
[this](https://github.com/apache/pinot/pull/9994) approach. Among the
motivation we have were included the explosion of metrics if we do one metric
for partition. We also address issues like aging of time lag measures and
handling of events that affect partition hosting. These extra items do make
sense for time based but not for offset based so I do think we should keep
offset and time based lag separate. May be focus this pr on offset and the
other one in lag. I could modify my PR to also report the partition creating
the largest lag if that is something you think it will be useful. We should
also consider whether we want to combine the offset metric on a single one: I
think we can reuse the tracker object I created on my PR and disable aging.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
