So Ideally the LastCatchUpTimeMs is supposed to be a proxy for lag. We could report this field as lag, but I am personally not in favor of doing that as the LastCaughtUpTimeMs is just an approximation of lag, but not actual lag.
I guess it depends on the experience we want through the tool. Do we want to isolate the user from internal details and report a “lag” which we can change the definition of, or just report the actual metric for the user of the tool to decide for themselves how to interpret that info. Do you have a strong opinion here? - Niket > On May 20, 2022, at 11:29 AM, José Armando García Sancio > <jsan...@confluent.io.INVALID> wrote: > > Thanks for the changes to KIP-836 Niket. > > KIP-836 has the following output for "--describe replication": >> bin/kafka-metadata-quorum.sh --describe replication > ReplicaId LogEndOffset Lag LastFetchTimeMs > LastCaughtUpTimeMs Status > 0 234134 0 tnow tnow > Leader > 1 234130 4 t2 t6 > Follower > 2 234100 34 t3 t7 > Follower > 3 234124 10 t4 t8 > Observer > 4 234130 4 t5 t9 > Observer > > KIP-595 has the following output for "--descripbe replication": >> bin/kafka-metadata-quorum.sh --describe replication > ReplicaId LogEndOffset Lag LagTimeMs Status > 0 234134 0 0 Leader > 1 234130 4 10 Follower > 2 234100 34 15 Follower > 3 234124 10 12 Observer > 4 234130 4 15 Observer > > Should we update KIP-836 to also include "LagTimeMs" in the output?
