Automating Redis Monitoring with an AI Agent: From Graphs to Fixes

Here is a story most teams running Redis will recognize. Friday evening, peak traffic. maxmemory fills, evictions spike from zero to thousands per second, the cache hit ratio craters, and every miss falls through to a database that was sized on the assumption the cache would absorb 90% of reads. The part that stings in the postmortem: the Grafana panel showed evictions climbing for three weeks. Everyone saw the graph. Nobody owned the action.

That gap — between Redis monitoring that shows you a problem and someone actually doing something about it — is what this article is about. It is part three of our Redis performance series. Part one covered the metrics that matter: cache hit ratio, memory fragmentation, eviction behavior, slow commands, big keys, replication lag. Part two walked through auditing all of them with native tools — INFO, SLOWLOG, LATENCY, MEMORY DOCTOR, redis-cli --bigkeys.

If you ran that audit, you found real issues. You also spent hours on it, and the output was a snapshot: fragmentation drifts, keyspaces grow, a single deploy can introduce a KEYS call that undoes a month of tuning. This article covers how Tony, CloudThinker's database agent, runs that audit continuously — and, unlike a dashboard, follows through with evidence-backed remediation proposals you approve or reject.

How Tony works with your Redis

Connecting: a read-only ACL user, about five minutes

Tony connects to Redis the way your security review would insist on: a dedicated Redis ACL user scoped to read and introspection commands — INFO, SLOWLOG GET, LATENCY history, MEMORY stats, key sampling. No write commands, no FLUSHALL, no ability to change server configuration at connection time. You create the user, paste the endpoint and credentials into CloudThinker, and the first scan starts. The whole flow takes about five minutes; the Redis connection guide lists the exact ACL rule so you can see precisely which command categories are granted, and works the same for self-hosted Redis, ElastiCache, and Azure Cache for Redis.

What Tony watches continuously

Once connected, Tony runs the part-two audit on a loop instead of once a quarter:

1. Cache hit ratio — keyspace_hits versus keyspace_misses, trended over time, not eyeballed once. A ratio drifting from 92% to 84% over two weeks becomes a finding with a probable cause attached (new key pattern, TTL change, working set outgrowing maxmemory).
2. Memory fragmentation — mem_fragmentation_ratio per node, flagged when it holds above ~1.5, with the RSS-versus-used-memory delta translated into wasted gigabytes.
3. Eviction and expiry behavior — evicted_keys rate against your maxmemory-policy, including the dangerous quiet case: noeviction set on a cache workload, which fails writes instead of evicting when memory fills.
4. Slow commands — SLOWLOG entries correlated with latency spikes, with repeat offenders (a KEYS pattern in a cron job, an HGETALL on a giant hash) identified by origin and frequency.
5. Big keys and hot keys — sampled key-size analysis to catch the 800 MB hash before it becomes a blocking DEL or a replication stall.
6. Replication health — replica lag and output-buffer pressure, so a replica quietly falling behind surfaces before a failover makes it everyone's problem.

The checks are the same ones you can run by hand. The difference is cadence and memory: Tony has the baseline, so "fragmentation is 1.7" arrives as "fragmentation rose from 1.2 to 1.7 since the March 14 deploy."

Proposals with evidence, not alerts with a shrug

This is where an agent differs from Redis monitoring dashboards. When Tony finds something, it proposes a specific fix with the reasoning attached:

• TTL strategy — if a large share of keys have no expiry, Tony identifies which key patterns they belong to, estimates memory reclaimed by adding TTLs, and proposes values based on observed access recency.
• Eviction policy — if noeviction or a mismatched policy is causing failures or evicting the wrong keys, Tony proposes a policy (allkeys-lru, volatile-ttl, and so on) with the trade-offs spelled out for your workload, per the Redis eviction docs.
• Big-key refactors — for an oversized hash or set, Tony proposes the split (bucketed hashes, pagination with HSCAN instead of HGETALL) and quantifies the latency evidence from the slowlog.
• Fragmentation remediation — active defragmentation settings or a scheduled replica-first restart, depending on your Redis version and topology.

Every proposal cites the underlying INFO, SLOWLOG, and sampling data — the same evidence you gathered manually in part two, minus the hours.

Graduated autonomy: you set what Tony may touch

Every action class has an autonomy level you configure per environment:

• Notify — Tony reports the finding. Nothing else. The default for everything.
• Suggest — Tony proposes the specific change with projected impact and rollback notes.
• Approve — Tony prepares the change and executes only after a named human approves.
• Autonomous — Tony executes and reports. Teams reserve this for reversible, low-blast-radius actions in non-production — say, adjusting a TTL on a staging keyspace — usually after weeks of watching Tony be right at the Approve level.

Every finding, proposal, approval, and change lands in an audit trail: what was observed, what was proposed, who approved, what changed, when.

What a first pass typically finds

Illustrative numbers — a composite first scan of a mid-market setup: one primary with a replica, around 12 GB of data, backing a SaaS API. Yours will differ.

Note the shape: nothing exotic. The eviction-storm scenario from the opening is fully assembled in rows two and three — keys that never expire plus a policy that fails writes instead of evicting. A dashboard shows you each metric separately; the value here is that the table connects them, refreshes daily, and each row arrives with a proposed, approval-gated fix.

Prompts to try in your first session

Tony is conversational — you ask in plain language and get answers grounded in your instance's actual data:

"@tony why did our cache hit ratio drop below 80% last week? Which key patterns are missing most?"

"@tony show me the ten biggest keys, which commands touch them, and what a refactor would look like."

"@tony evictions spiked at 21:00 yesterday — what got evicted, and is our maxmemory-policy right for this workload?"

What Tony will not do

"AI agent connected to prod Redis" should trigger questions, so to state it plainly:

• Read-only by default. The connection user has no write or admin command categories. Remediation requires you to explicitly grant scoped access and raise the autonomy level above Notify.
• No config changes, deletions, or restarts without approval — unless you have deliberately set that specific action class to Autonomous for that specific environment.
• Nothing outside the audit trail. Every proposed and executed action is logged with its evidence and its approver.
• No architectural decisions. Tony will show you that the session store should not be one 890 MB hash; whether to re-shard it, move it, or redesign sessions entirely stays an engineering call — yours.

The right mental model: Tony is your part-two audit running daily, with a remediation queue attached. Not an autopilot you hand CONFIG SET to on day one.

From watching graphs to closing findings

You know which Redis metrics matter, and you know how to audit them by hand. What broke down in the Friday-evening story was neither knowledge nor tooling — it was ownership of the follow-through. Continuous watch plus evidence-backed proposals plus graduated autonomy is how that gap closes: the eviction trend gets caught in week one, arrives with a fix, and someone clicks approve.

Try CloudThinker free — 100 premium credits, no card required — and follow the Redis connection guide to see your own first findings table within the hour.