Page History

...

1. Last Fetch Time
   This metric will be reported for each voter. This is a good approximation of the “liveness” of the voters and can be used to detect a network partition in the quorum.
   This information is already known to the leader for all voters and only needs to be added to the response

2. Last Caught Up Time
   This metric will be reported for each voter. This is akin to the metric used to track lag for replicas in ISR and it measures the approximate lag between the leader and the replica based on the offsets requested in the fetch requests and when they were made. The metric gives a measure of when was the last time a replica caught up to the leader. .
   To compute this metric, the Replica state maintains a few bits of information about fetch requests as they are received. The leader tracks the time, requested offset and the leader's own end offset for the most recent fetch request it processes for each replica. Whenever a new fetch request comes in the replica's last caught up time is updated to the time of the fetch request if it requests an offset greater than the leader's current end offset. The offset is also compared to the leader's end offset when the previous request was received and the caught up time is updated to the time of that fetch request if the offset is greater than that. This gives a notion of whether a replica is within an acceptable bound of lag from the leader, and is more accurate than relying solely on the offset difference as it models the leader's load into the computation.
   Some of this information is not tracked in the information that by the Raft layer stores for each voter at this time but it can be easily added in. The cost to track this information is minimal and it only requires some additional bookkeeping during pre-existing processing for a fetch.
   
   NOTE: Given the leader is always caught up to itself, the Last Caught Up Time for the leader will be the leader's wall clock time when it responded to the DescribeQuorum request.

...