...
There are additional info in a GroupMetadata
object on the server side, some of which could be useful if exposed via the DescribeGroups
protocol. Here are some examples:
generationId
leaderId
newMemberAdded
receivedConsumerOffsetCommits
receivedTransactionalOffsetCommits
supportedProtocols
per member
Enhancing the protocol with some of this additional info means improving the existing tools that make use of it. For example, using this additional info, the consumer group command's --describe
output will provide more information about each consumer group to help with studying understanding the group behavior, its monitoring, troubleshooting, etc.
Public Interfaces
This is the latest version (v1) of DescribeGroups
protocol:
...
Code Block |
---|
DescribeGroups Request (Version: 2) => [group_ids] group_ids => STRING DescribeGroups Response (Version: 2) => throttle_time_ms [groups] throttle_time_ms => INT32 groups => error_code group_id state protocol_type protocol generation_id leader_id new_member_added received_consumer_offset_commits received_transactional_offset_commits [members] error_code => INT16 group_id => STRING state => STRING protocol_type => STRING protocol => STRING * generation_id => INT32 * leader_id => STRING * new_member_added => BOOLEAN * received_consumer_offset_commits => BOOLEAN * received_transactional_offset_commits => BOOLEAN members => member_id client_id client_host member_metadata member_assignment [member_protocols] member_id => STRING client_id => STRING client_host => STRING member_metadata => BYTES member_assignment => BYTES * member_protocols => STRING |
...
- Create version 2 of
DescribeGroups
protocol to include additional information about the consumer group and also each group member for the API clients. - Update the consumer group command to provide the added information in the command output (where applicable). Note that this KIP will impact improve upon KIP-175 where group state and detailed member information will also be returned by the consumer group command using additional command line options. Therefore, If this KIP is implemented before KIP-175, this step can be skipped (as the output of some of the sub-options introduced in KIP-175 will make the command line adjustments to leverage improve to include the newly available information ).If this KIP is implemented after KIP-175, this step will be implemented as part of the KIPby this KIP.
Compatibility, Deprecation, and Migration Plan
If Since this KIP is implemented before follows KIP-175, there is no compatibility concerns. This all existing protocol fields remain unchanged.If the KIP is implemented after KIP-175, the output for sub-options --members
and --state
that are introduced in that KIP will be modified to also include the newly added fields. Therefore, clients who rely on the output for those sub-options may need to be adjusted.
Rejected Alternatives
There are other information available for a consumer group that could be included in the KIP. For example:
newMemberAdded
receivedConsumerOffsetCommits
receivedTransactionalOffsetCommits
Instead of adding this information to the protocol (and having to explain to users what it means and also having to continue exposing it in the future even if implementation details change) we could report them as log messages them when necessary on the broker side.