An empty group id
A blank line, which is a real and distinct mistake rather than nothing
my-consumer-group My Group
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.
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.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
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.
A blank line, which is a real and distinct mistake rather than nothing
my-consumer-group My Group
The __consumer_offsets partition a group hashes to, which decides its coordinator
orders-consumer payments-consumer inventory-consumer
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
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.
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.
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.
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.
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 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.
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.
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.
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.