Introduction

Kafka does not have one perfect built-in command that says "show me every consumer of this topic" across all groups in one direct lookup. Operationally, you usually list consumer groups and then describe them to find which groups currently own partitions of the topic you care about.

Why There Is No Single Perfect Command

Kafka tracks consumption primarily through consumer groups and partition assignments, not through a standalone topic-to-consumer registry you can query with one universal topic command.

So the practical workflow is:

1. list consumer groups
2. describe relevant groups
3. filter the output by topic

That gives you the groups and members currently consuming that topic.

Step 1: List Consumer Groups

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

This gives you the group IDs known to the cluster.

Step 2: Describe a Group

For a specific group:

1kafka-consumer-groups.sh \
2  --bootstrap-server localhost:9092 \
3  --describe \
4  --group my-group

The output typically includes columns such as:

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

If the topic rows you care about appear in that output, that group is consuming the topic.

Filter by Topic

In practice, you usually filter the describe output:

1kafka-consumer-groups.sh \
2  --bootstrap-server localhost:9092 \
3  --describe \
4  --group my-group | grep '^my-topic[[:space:]]'

Or inspect all groups one by one and check which ones include my-topic.

That is the real operational answer most of the time.

What You Actually Learn

From the described group output, you can identify:

• whether the group is consuming the topic
• which partitions it owns
• which consumer member currently owns each partition

That is more useful than a bare list of names because it shows actual active assignment, not just a historical relationship.

Programmatic Alternative

If you need something more structured than CLI parsing, a program using Kafka's admin API can:

• list consumer groups
• describe each group
• inspect member assignments
• filter groups whose assignments include the target topic

That is the better route for automation. The CLI is more convenient for human inspection.

Important Limitation

This workflow tells you about consumer groups and their members. It does not give you a magical global list of every possible client that ever read from a topic outside the normal group-management model.

For example:

• old inactive groups may not be active consumers now
• manually assigned consumers may behave differently
• historical topic access is a different question from current assignment

So be clear whether you want current active consumers or some broader audit question.

A Practical Shell Pattern

For a quick operator workflow:

1for group in $(kafka-consumer-groups.sh --bootstrap-server localhost:9092 --list); do
2  echo "GROUP: $group"
3  kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group "$group" | grep my-topic || true
4done

This is not a special Kafka feature. It is just a practical shell loop over the normal group commands.

Common Pitfalls

Expecting a single Kafka command to map topic directly to all consumers across all groups is the most common misunderstanding.

Confusing "group exists" with "group is currently consuming this topic" leads to incorrect operational conclusions.

Filtering only by topic name without checking member and partition assignment can hide whether the group is actually active.

Assuming CLI output format is the best source for automation is fragile compared with using the admin API in real tooling.

Summary

• Kafka usually answers this question through consumer groups, not through one direct topic-consumer command.
• Use kafka-consumer-groups.sh --list to find groups and --describe --group to inspect each one.
• Filter described group output by topic to see which groups and members are consuming it.
• For automation, prefer the Kafka admin API over CLI-output parsing.
• Be clear whether you want current active assignments or a broader historical view, because those are different questions.