THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Once a reassignment has been submitted, users can use one of the --describe options to monitor progress
Metrics
Here’s a list of proposed metrics for this new protocol:
NAME | TAGS | TYPE | NOTE |
CurrentLeader | type=raft-manager | dynamic gauge | -1 means UNKNOWN |
|---|---|---|---|
CurrentEpoch | type=raft-manager | dynamic gauge | 0 means UNKNOWN |
CurrentVote | type=raft-manager | dynamic gauge | -1 means not voted for anyone |
LogEndOffset | type=raft-manager | dynamic gauge | |
LogEndEpoch | type=raft-manager | dynamic gauge | |
BootTimestamp | type=raft-manager | dynamic gauge | |
State | type=raft-manager | dynamic enum | possible values: "leader", "follower", "candidate", "observer" |
NumQuorumVoters | type=raft-manager | dynamic gauge | number of cached voter connections; would never be larger than quorum-size |
InboundRequestPerSec | type=raft-manager, source-broker-id=[broker-id] | windowed rate | one per source |
OutboundRequestPerSec | type=raft-manager, destination-broker-id=[broker-id] | windowed rate | one per destination |
InboundChannelSize | type=raft-manager | windowed average | |
OutboundChannelSize | type=raft-manager | windowed average | |
FetchRecordsPerSec | type=raft-manager | windowed rate | apply to follower and observer only |
AppendRecordsPerSec | type=raft-manager | windowed rate | apply to leader only |
ErrorResponsePerSec | type=raft-manager, destination-broker-id=[broker-id] | windowed rate | one per destination |
TotalTimeMs | type=raft-manager, request=[request-type] | windowed average | one per inbound request type |
InboundQueueTimeMs | type=raft-manager, request=[request-type] | windowed average | one per inbound request type |
HandleTimeMs | type=raft-manager, request=[request-type] | windowed average | one per inbound request type |
OutboundQueueTimeMs | type=raft-manager, request=[request-type] | windowed average | one per inbound request type |
AvgIdlePercent | type=raft-manager | windowed average |
Client Interactions
Since this specific quorum implementation is only to be used by Kafka internally, we do not need to add new public protocols for clients. More specifically, the leader of the quorum would act as the controller of the cluster, and any client requests that requires updating the metadata (previously stored in ZK) would be interpreted as appending new record(s) to the quorum's internal log.
...