Kafka Consumer Group Id Validator

Work out which __consumer_offsets partition a consumer group hashes to, and therefore which broker coordinates it, using Kafka's own hash. Also flags the ids that break JMX metric names, which the broker accepts happily.

The partition count is fixed when __consumer_offsets is created and cannot be altered afterwards, so if your cluster is not on the default 50 this has to match or every result is wrong.

Paste below, or drop a file anywhere on this panel

Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.

The answer appears here

Paste on the left and press Check group ids. Nothing leaves this tab.

Examples

Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.

An empty group id

A blank line, which is a real and distinct mistake rather than nothing

my-consumer-group
My Group

Which partition holds the offsets

The __consumer_offsets partition a group hashes to, which decides its coordinator

orders-consumer
payments-consumer
inventory-consumer

Common mistakes

These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

  1. Using a group id with spaces or unusual characters

    It becomes part of metrics and file paths, and the same dot-versus-underscore collision as topic names applies.

    Instead:Stick to lowercase, hyphens and dots, and be consistent about which.

  2. Sharing one group id across unrelated consumers

    They will rebalance against each other and split partitions, so each sees only some of the messages.

    Instead:One group id per logical consumer application.

  3. Changing the group id to reset offsets

    A new group starts from auto.offset.reset, which usually means reprocessing everything or skipping the backlog.

    Instead:Use kafka-consumer-groups --reset-offsets on the existing group.

Which broker coordinates your group, and why the id matters elsewhere

Kafka puts almost no restriction on a group id, so this is not really a validator in the sense the topic name validator is. The useful answers are where the group's state lands and what the id collides with outside Kafka.

The group id decides which broker coordinates the group

Kafka hashes the group id with Java's String.hashCode, masks the sign off with 0x7fffffff, and takes it modulo the number of __consumer_offsets partitions. The leader of that partition is the group coordinator, and every join, heartbeat and offset commit for the group goes to that one broker. That placement is fixed by the hash: it cannot be moved without changing the group id, and changing the group id abandons the committed offsets. This page computes it exactly rather than approximately, which is why the number matches what the broker does.

partition = (hashCode(groupId) & 0x7fffffff)
            % offsets.topic.num.partitions

# masked, not Math.abs: in Java, Math.abs of
# Integer.MIN_VALUE is still negative, and a negative
# partition number would be a real bug

Two groups on the same partition fail together

Groups are placed by hash rather than spread deliberately, so two unrelated services can share a coordinator. That is normal and harmless until the broker holding that partition restarts, at which point both groups rebalance at the same moment and both recover at the same moment. When two services appear to have a correlated incident with no shared dependency, a shared coordinator is worth checking.

Kafka does not restrict the characters, and JMX does

The broker accepts any non-empty string. The consumer's own metrics, though, are registered under a JMX ObjectName that contains the group id, and a comma, equals sign, colon, quote, asterisk or question mark is either a separator or a wildcard there. The result is a group that works perfectly and whose metrics fail to register or cannot be queried, so the consumer is healthy and invisible. Since a group cannot be renamed without losing its offsets, this is worth getting right at the start.

offsets.topic.num.partitions cannot be changed later

It is 50 by default and fixed when __consumer_offsets is created. If your cluster was created with a different value, set it above or every partition on this page is wrong. It is also why a development cluster that created the topic with one partition keeps every group on one coordinator forever.

Console consumer groups accumulate

kafka-console-consumer invents a random group id per run unless you pass --group. Each becomes a real group with real state, and on a cluster people debug on they collect in the thousands, which slows group listing and lengthens coordinator loading after a broker restart. They do expire, after offsets.retention.minutes, which is 7 days by default.

Related kafka tools

Kafka Consumer Config Generator The commit mode decides the semantics Kafka Consumer Assignment Visualizer The three assignors disagree Kafka Topic Name Validator Legal, risky, or 249 characters too long? Kafka ACL Permission Matrix Viewer DENY beats every ALLOW Kafka Connect Config Validator The mistakes that raise no error Kafka Avro Schema Validator The defaults Avro accepts and rejects
All 73 kafka tools

Elsewhere on the site

Terraform Validator & Formatter Kubernetes YAML Generator Kubernetes YAML Validator AWS IAM Policy Validator & Analyzer