Gauge Metrics

A messaging team noticed their consumer was processing messages slower than usual. But they had no metrics on queue depth. By the time someone manually checked the queue, 2 million messages were backed up. It took 6 hours to drain.

If they'd had a gauge tracking queue depth, a number that goes up when messages arrive and down when they're consumed, they would have seen the buildup start within minutes. A simple alert: "queue depth > 10,000" would have caught it before it became a 6-hour recovery event.

Gauges measure the current state of something. Not how many events happened (that's a counter), but what's the value right now. How much memory is being used. How many connections are active. How deep is the queue. What's the CPU temperature. These are all values that fluctuate. They go up, they go down, and the current reading is what matters.

The distinction is simple but critical:

Common gauges in production:

• process_memory_bytes, current memory usage
• node_cpu_utilization, current CPU percentage
• queue_depth, messages waiting to be processed
• active_connections, current open connections
• disk_usage_percent, current disk utilization
• thread_pool_active, threads currently busy

When something breaks, gauges tell you the current state of the world. Is memory at 95%? Is the connection pool saturated? Is the disk full? These are all gauge readings, and they're usually the first thing you check during an incident.