rpk group

Describe, list, and delete consumer groups and manage their offsets.

Consumer groups allow you to horizontally scale consuming from topics. A non-group consumer consumes all records from all partitions you assign it. In contrast, consumer groups allow many consumers to coordinate and divide work. If you have two members in a group consuming topics A and B, each with three partitions, then both members consume three partitions. If you add another member to the group, then each of the three members will consume two partitions. This allows you to horizontally scale consuming of topics.

The unit of scaling is a single partition. If you add more consumers to a group than there are total partitions to consume, then some consumers will be idle. More commonly, you have many more partitions than consumer group members and each member consumes a chunk of available partitions. One scenario where you may want more members than partitions is if you want active standby’s to take over load immediately if any consuming member dies.

How group members divide work is entirely client driven (the "partition assignment strategy" or balancer depending on the client). Brokers know nothing about how consumers are assigning partitions. A broker’s role in group consuming is to choose which member is the leader of a group, forward that member’s assignment to every other member, and ensure all members are alive through heartbeats.

Consumers periodically commit their progress when consuming partitions. Through these commits, you can monitor just how far behind a consumer is from the latest messages in a partition. This is called lag. Large lag implies that the client is having problems, which could be from the server being too slow, or the client being oversubscribed in the number of partitions it is consuming, or the server being in a bad state that requires restarting or removing from the server pool, and so on.

You can manually manage offsets for a group, which allows you to rewind or forward commits. If you notice that a recent deploy of your consumers had a bug, you may want to stop all members, rewind the commits to before the latest deploy, and restart the members with a patch.

This command allows you to list all groups, describe a group (to view the members and their lag), and manage offsets.

Usage

rpk group [flags]

Aliases

rpk g

Subcommands

Command Description

rpk group delete

Delete one or more consumer groups. You may want to delete groups to clean up committed offsets sooner than they expire automatically, such as when you create temporary groups for quick investigation or testing.

rpk group describe

Describe group offset status & lag. This command describes group members, calculates their lag, and prints detailed information about the members.

rpk group list

List all groups. This command lists all groups currently known to Redpanda, including empty groups that have not yet expired.

rpk group offset-delete

Forcefully delete offsets for a kafka group. The broker will only allow the request to succeed if the group is in a dead state (no subscriptions) or there are no subscriptions for offsets for topic/partitions requested to be deleted.

rpk group seek

Modify a group’s current offsets. This command allows you to modify a group’s offsets.

Global flags

Value Type Description

--config

string

Redpanda or rpk config file; default search paths are ~/.config/rpk/rpk.yaml, $PWD/redpanda.yaml, and /etc/redpanda/redpanda.yaml.

-X, --config-opt

stringArray

Override rpk configuration settings; -X help for detail or -X list for terser detail.

--ignore-profile

bool

Ignore rpk.yaml and redpanda.yaml; use default settings.

--profile

string

rpk profile to use.

-v, --verbose

bool

Enable verbose logging.