MQ Commands Cheatsheet - Kafka & RabbitMQ

First use kafka-consumer-groups.sh --describe --group <group> to see whether LAG grows steadily or merely spikes: steady growth means the consumption rate sits below the production rate and the gap is widening, whereas a spike that returns to baseline is transient noise. Then pair it with --members --verbose to see group membership and partition assignment. If idle partitions exist you have too few consumers to cover the topic; if every partition is assigned and LAG still climbs, individual consumers are simply too slow and adding machines will not help.

Run rabbitmqctl list_queues name messages consumers to get everything in one shot. Messages present with consumers at 0 means messages arrive but no consumer is registered or has disconnected — check the application side, whether it is running and pointed at the same vhost. If consumers is above 0 and nothing is still consumed, the messages are not being routed: rabbitmqctl list_exchanges name type and list_bindings then reveal the exchange types and bindings, and the usual culprit is an exchange declared with the binding forgotten.

Look at both. On the broker, rabbitmqctl list_connections name state channels gives connection and channel counts, and list_channels pid number identifies which single connection is holding many channels — far more channels than the workload needs usually means connections are not being reused. On the host, ss -tnp | grep :9092 | wc -l counts connections reaching the broker, which you compare against the pool size the application is configured with. Broker-side counts that look sane while the host-side count keeps climbing point at a pool that never releases.

Because Pub/Sub has neither persistence nor an offset. A client that disconnects while subscribed loses everything published in the gap, and PUBSUB CHANNELS * only lists currently active channels while PUBSUB NUMSUB channel only counts present subscribers — there is no observation point that can tell you what you missed. So the investigation is not about finding the message but about confirming the consumer is present and deciding whether loss is acceptable. If it is not, move to a solution with consumer groups rather than trying to make Pub/Sub reliable.

It means no rate limit: kafka-producer-perf-test.sh pushes as fast as the system allows, which measures the throughput ceiling rather than steady-state latency. --num-records sets the total record count. If you care about tail latency in production, do not run unthrottled — set a rate near your real peak instead, or the measured ceiling means nothing operationally. Before any of it, confirm partition count with kafka-topics.sh --describe --topic <topic>, because a low partition count makes you hit a per-partition bottleneck before a broker one.