Measuring Valkey Saturation with Active-Time and Eventloop Metrics in 9.1

Your Valkey server reports 100% CPU. Is it saturated? You cannot tell from that number, and it isn't a monitoring bug. Valkey's main thread and I/O threads busy-wait for work. A thread waiting burns CPU exactly like a thread working. In one reported case, throughput swept from 217K to 452K QPS- a 2x increase, while main-thread CPU sat flat near 100% the entire way and total CPU pinned at 400%. Every alert, dashboard and autoscaling policy built on that number is reading noise. Valkey 9.1 shipped the answer: used_active_time_main_thread and used_active_time_io_thread_N, measuring wall clock minus busy-wait and blocking epoll, on a monotonic clock so spare capacity is actually visible.

This session builds a real saturation signal out of INFO:
- active-time deltas for true per-thread utilization
- eventloop_duration_sum minus eventloop_duration_cmd_sum to separate I/O from command execution
- latencystats percentiles to catch what averages hide

Then we tune I/O thread count against it and ship the result with log-format json. You will leave able to answer "how much headroom do I have?" and to retire the CPU alert that was never going to tell you.