Monitoring Streams and Consumer Groups

Is anyone falling behind?

For each stream, watch its length, memory and growth rate. For each consumer group, watch lag and pending entries. XINFO STREAM shows length, first and last entries and the number of groups. XINFO GROUPS lists groups with their consumers, pending count, last-delivered-id, and, since Redis 7, entries-read and lag (entries not yet delivered to the group, when Redis can compute it). XINFO CONSUMERS shows each consumer's pending count and idle time, which reveals dead consumers. XPENDING summarises unacknowledged entries. Export these to your monitoring system (for example, Prometheus via redis_exporter, which can be configured to collect stream metrics) and alert on growing lag, a PEL that keeps growing, consumers idle with pending entries, and memory approaching maxmemory. For Pub/Sub, watch the number of subscribers per channel and client output buffer sizes.

Inspecting groups and consumers

Lag and pending counts tell you whether consumers keep up.

XINFO STREAM events:orders
# length, radix-tree keys/nodes, last-generated-id, groups, first-entry, last-entry

XINFO GROUPS events:orders
# name, consumers, pending, last-delivered-id, entries-read, lag

XINFO CONSUMERS events:orders billing
# name, pending, idle (ms since last interaction), inactive

XPENDING events:orders billing
XPENDING events:orders billing IDLE 60000 - + 10    # entries idle over 60 s

Queue length at a ticket counter

Lag is the number of people waiting to be served; pending is the number currently at the counter. If the queue grows all morning, you need another counter (consumer); if one counter has had the same person for an hour, the clerk has gone missing.

Quick check: Which XINFO GROUPS field (Redis 7+) shows how many entries a group has not yet received?

• idle
• radix-tree-nodes
• last-generated-id
• lag