Traffic Analyzer for Redis and Valkey MONITOR Output

Load what MONITOR printed and see what a Redis or Valkey server’s traffic is made of: commands per second, the command mix, the busiest keys and clients, how the keys would spread over a cluster, commands worth a second look, and how many keys a cache needs to hold for a given hit rate. It all runs in your browser.

Nothing you load leaves this page. The tool doesn’t send anything anywhere, and the page’s security policy stops it from fetching or loading anything from another site, so your data stays on your machine.

On a wide screen you can open it full screen.

How to Use It

  1. Record a capture. Run MONITOR for a few seconds, or a minute at most, and stop it with Ctrl-C:
redis-cli -h 10.0.0.4 -p 6379 MONITOR > monitor.txt
timeout 30 valkey-cli -h 10.0.0.4 -p 6379 MONITOR > monitor.txt
  1. Open it. Choose the file or drop it on the page. Big files are read in steps, with a progress bar. You can also paste a few lines.
  2. Read the totals. Commands per second, the command mix, reads against writes, the busiest keys and key patterns, and which clients send what.
  3. Check the findings. KEYS, flushes, reads of whole collections, big values, commands across cluster slots, hot keys, and a few habits worth changing, each with examples from the capture.
  4. Size a cache. The hit-rate curve shows how many keys a cache would need to hold for a given share of the reads. Type a size to see what it would serve.
  5. Take it with you. Download every key with its counts, commands per second, or the curve as CSV.

MONITOR has a cost: the server writes out every command for every client that’s watching, which can halve its throughput when it’s busy. Keep captures short.

What MONITOR Shows

MONITOR sends a client every command the server runs, one line each, with the time to the microsecond, the database, the client’s address and the arguments:

1791218550.753456 [0 10.0.0.12:54650] "SET" "session:9f86" "{\"user\":42}" "EX" "1800"
1791218550.754174 [0 lua] "INCR" "rate:10.0.4.7"

Commands a Lua script or a function ran show lua in place of the address, right after the script’s own line. Admin commands such as CONFIG and CLIENT LIST never show up, passwords come out as "(redacted)", and commands the server refused before running them are missing. Commands that ran and failed are there.

From those lines the analyzer works out which arguments are keys, using the key positions of every command in Valkey 9.1 and Redis 8.10, and whether each command reads, writes or deletes.

How the Cache Curve Works

A least-recently-used cache keeps the keys used most recently. For every read in the capture, the analyzer counts how many other keys were used since the same key was last used. A cache holding more keys than that still has the key, so the read is a hit. One pass gives the hit rate for every cache size at once, a method from an IBM paper of 1970.

The first read of each key always misses, so even a cache holding every key stays below 100%. That ceiling is the best possible hit rate, and the page shows how many keys it takes to reach half of it, 80%, 90%, 95% and 99%.

Redis and Valkey evict keys by sampling a few and dropping the oldest of those, which comes close to an exact LRU. In a test with Valkey 9.1.2, allkeys-lru and 4 MB of memory, the server served 57.3% of 720,000 reads, and the curve from a MONITOR capture of the same run said 57.6%.

How It Was Tested

Five servers, built from source, ran a known workload while valkey-cli or redis-cli recorded MONITOR: Valkey 9.1.2 and Redis 8.10.2, 7.2.16, 6.2.24 and 2.8.24. Six client addresses sent 61 different commands, among them transactions, scripts, a function, binary and UTF-8 keys, a 110 KB value, KEYS and a FLUSHDB.

  • All 4,757 lines read back byte for byte as sent, each in its connection’s order.
  • The keys of every command matched what the server’s COMMAND GETKEYS reported, and key slots matched CLUSTER KEYSLOT for all 1,492 keys.
  • The totals per command, key and client, and every finding, matched counts made from what was sent.
  • The hit-rate curve matched a simulated LRU cache, and a real Valkey server within a third of a percentage point.

The Code

The analyzer is one JavaScript file with no dependencies, open source under the Apache License 2.0. It runs as this page, as a command line in Node.js that reads captures of any size, or from standard input, and inside your own code:

node traffic/cli.js monitor.txt
node traffic/cli.js monitor.txt --cache 50000
timeout 30 redis-cli MONITOR | node traffic/cli.js -

A capture of 3 million commands takes about 11 seconds on the command line. The full manual, the tests and the captures they replay are in the traffic folder on GitHub. The other tools work the same way.