Interface PerformanceMetrics

public interface PerformanceMetrics
Latency measurements for the main operations in a Raft cluster.

Provides visibility into how long different types of operations take, which helps identify bottlenecks and monitor cluster health under load. Four categories of latency are tracked, each returned as a LatencyMetrics distribution:

  • Total: end-to-end request latency as experienced by the caller.
  • Processing: consensus latency, isolating the state machine apply phase.
  • Election: time to elect a new leader after a failure.
  • Redirect: round-trip cost when a follower forwards a request to the leader.

Diagnosing Bottlenecks

Start with getTotalLatency() to understand the latency users experience. If total latency is high, compare it against getProcessingLatency() to determine whether the delay is in consensus or elsewhere (e.g., queuing before processing). On follower nodes, check getRedirectLatency() to measure how much the forwarding hop contributes to overall latency. Use getLeaderElectionLatency() to assess how quickly the cluster recovers after a leader failure.

Role-Specific Availability

Not all metrics are available on every node. Total and processing latency are only recorded on the leader, since it is the node that processes requests. Redirect latency is only recorded on followers and learners, since they are the ones forwarding requests. Election latency is recorded on the JGroups coordinator that runs the voting process.

Since:
2.0
Author:
José Bolina
See Also:

  • Method Details

    • getTotalLatency

      LatencyMetrics getTotalLatency()
      End-to-end latency from request submission to response.

      Covers the full lifecycle of a request, including any internal queuing, consensus, and state machine handling. This is the latency most relevant to application-level SLAs; if this metric degrades, users are experiencing slower responses. Compare against getProcessingLatency() to determine whether the bottleneck is in the consensus phase or outside it.

      Only recorded on the leader node.

      Returns:
      the total operation latency distribution.

    • getProcessingLatency

      LatencyMetrics getProcessingLatency()
      Latency of the consensus process.

      Measures the time spent achieving majority agreement, from when the request starts being processed until it is committed. When significantly lower than getTotalLatency(), the gap reveals time spent in queuing or applying the command to the state machine. When both metrics are close, consensus is the dominant cost and network or cluster size may be the limiting factor.

      Only recorded on the leader node.

      Returns:
      the consensus processing latency distribution.

    • getLeaderElectionLatency

      LatencyMetrics getLeaderElectionLatency()
      Latency of leader elections.

      Measures how long it takes to elect a new leader after the previous one becomes unavailable. During this window the cluster cannot accept any operations, so shorter elections mean less downtime. High election latency may indicate network delays between cluster members or contention in the voting process.

      Only recorded on the JGroups coordinator that runs the voting process.

      Returns:
      the election latency distribution.

    • getRedirectLatency

      LatencyMetrics getRedirectLatency()
      Round-trip latency for requests forwarded from a non-leader node to the leader.

      When a client submits a request to a follower or learner, the request is transparently forwarded to the leader for processing and the response is relayed back. This metric captures the full round-trip cost of that forwarding. High redirect latency compared to the leader's total latency points to network overhead between the forwarding node and the leader.

      Only recorded on follower and learner nodes.

      Returns:
      the redirect latency distribution.