Introduction

When people ask for a “Kafka consumer list,” they usually mean one of two things: a list of consumer groups in the cluster, or details about the members of a specific consumer group. Kafka’s tooling is centered around consumer groups, not around a global flat list of every consumer process.

That distinction matters because Kafka consumers coordinate through group membership. If you want operational visibility, the standard workflow is to list groups first and then describe the one you care about.

List Consumer Groups

The usual command-line entry point is:

kafka-consumer-groups.sh --bootstrap-server localhost:9092 --list

This prints the consumer group IDs known to the cluster.

It does not automatically show each member, partition assignment, or lag details. It just gives you the group names.

Describe One Consumer Group

To inspect the consumers participating in a specific group and their partition assignments, describe the group.

kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group my-group --describe

This typically shows information such as:

• topic
• partition
• current offset
• log end offset
• lag
• consumer ID
• host
• client ID

That is usually what operators actually need when they say “list consumers.”

Programmatic Listing With AdminClient

If you want the same information in Java code, use Kafka’s AdminClient.

1import org.apache.kafka.clients.admin.*;
2import java.util.Properties;
3
4public class ListGroups {
5    public static void main(String[] args) throws Exception {
6        Properties props = new Properties();
7        props.put(AdminClientConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
8
9        try (AdminClient admin = AdminClient.create(props)) {
10            for (ConsumerGroupListing group : admin.listConsumerGroups().all().get()) {
11                System.out.println(group.groupId());
12            }
13        }
14    }
15}

This gives you the group list. You can then drill into a specific group with more admin APIs if needed.

What You Can and Cannot List Globally

Kafka is not really designed around a single global “all consumer instances everywhere” list as the primary operational concept. The group is the coordination unit.

So the standard questions are:

• what consumer groups exist?
• what members are in this group?
• what partitions are assigned?
• what lag exists?

That framing matches the tools Kafka provides.

This is also why two monitoring tools may present the same cluster differently. One may emphasize group-level summaries, while another may emphasize member-level details only after you drill into a particular group.

Operational Tools Beyond the CLI

If you prefer a UI, monitoring platforms and Kafka dashboards can expose the same information more readably.

Typical options include:

• managed platform dashboards
• AKHQ
• cluster monitoring tools
• metrics systems that expose lag and group state

These are helpful for ongoing operations, but the CLI remains the quickest source of truth on a machine with Kafka tooling installed.

Common Pitfalls

A common mistake is expecting --list to show every consumer instance with all details. It usually only shows group IDs.

Another mistake is confusing consumer groups with individual applications. One app can run many consumers, and one group can span multiple hosts.

Developers also forget that an inactive or idle group may appear differently than an actively consuming group depending on cluster state and offsets.

Finally, if the CLI returns nothing useful, verify that you are connecting to the correct cluster and bootstrap server before assuming no consumers exist.

Summary

• In Kafka, the main operational unit is the consumer group, not a global flat list of consumers.
• Use kafka-consumer-groups.sh --list to list group IDs.
• Use --describe on a specific group to see members, assignments, and lag.
• 'AdminClient provides the same capabilities programmatically.'
• For most troubleshooting, group-level visibility is what actually matters.