Redis Cloud v2 Metrics: Complete Reference for Monitoring, Alerting, and Production Observability

Redis Cloud v2 metrics provide deep, production-grade observability into every layer of your Redis deployment. Unlike basic INFO-command metrics that most monitoring setups rely on, the v2 metric set includes true histogram latency distributions, memory allocator internals, keyspace distribution by data structure and size, Active-Active CRDT synchronization tracking, and node-level infrastructure metrics. It's the difference between knowing Redis is slow and knowing exactly why.

Redis Cloud exports these metrics natively — no agent required. Connect your monitoring platform using an API key, select your region, and metrics start flowing within minutes. The metrics follow standard conventions: Gauge (current value), Count (monotonically increasing counter), Histogram (latency distribution), and Info (metadata). They arrive pre-tagged with cluster, database, shard, region, and role labels for instant filtering.

Basic Redis monitoring tells you 'latency is high.' v2 metrics tell you 'P99 write latency crossed 8ms, memory fragmentation is at 1.7, the allocator is holding 40% more resident memory than active, and 3 keys in the large sorted-set bucket are blocking the event loop.' That's the depth difference.

What the v2 Metric Set Covers

80+ metrics organized across 12 categories — from Redis process internals to node hardware.

• Configuration and metadata — database config state, throughput limits, cluster metadata
• Memory — 13 metrics covering usage, limits, allocator internals, fragmentation, and background process indicators
• Latency — true histogram distributions for read, write, and other operations (P50/P90/P95/P99, not averages)
• Traffic — request/response counts by type, ingress/egress bytes, backpressure indicators
• Connections — connected clients, blocked clients, connection churn, proxy disconnections, establishment failures
• Network — Redis-level input/output bytes
• CPU — process and per-thread CPU consumption
• Keyspace — key counts, expiry counts, evictions, hit/miss ratios separated by read and write
• Keyspace distribution — key counts by data structure type (String, Hash, List, Set, Sorted Set) and size bucket
• Replication and syncer — replication offsets, Active-Active lag, syncer status, byte-level sync tracking
• Client tracking — server-assisted caching metrics for Redis 6+ client-side caching
• Node-level infrastructure — CPU, memory, network I/O, packet counts on the underlying hardware (Pro subscriptions)

Configuration and Metadata Metrics

These metrics expose database and cluster configuration state. Use them to track config drift, detect unexpected changes, and correlate configuration modifications with performance shifts.

Memory Metrics (13 Metrics)

Memory is the most critical monitoring category for Redis. These 13 metrics cover the full stack: from how much data you're storing, to how the allocator is managing physical memory, to whether background persistence operations are spiking latency.

Three memory metrics matter most: used_memory (how full you are), maxmemory (the ceiling before evictions), and mem_fragmentation_ratio (how efficiently you're using what you have). Everything else is diagnostic — reach for them when those three raise a flag.

Latency Metrics — True Histogram Distributions (9 Metrics)

The v2 metrics provide true histogram latency — not averages. This is the single most important difference from basic Redis monitoring. Averages hide outliers. A P50 of 1ms and a P99 of 50ms both produce an average that looks fine while 1% of your requests are unacceptably slow. Histograms give you the full distribution: P50, P90, P95, P99.

Latency is broken into three operation categories — read, write, and other — each with count, sum, and bucket metrics.

To compute P99 read latency, use the standard histogram percentile formula: histogram_quantile(0.99, sum(rate(endpoint_read_requests_latency_histogram_bucket[5m])) by (le)). The result is in microseconds — divide by 1000 for milliseconds. This works in any monitoring platform that supports PromQL-style queries.

Traffic Metrics (10 Metrics)

Traffic metrics separate reads, writes, and other commands — and further separate requests from responses. This lets you detect asymmetries: if requests consistently exceed responses, commands are being dropped, timing out, or queuing.

Connection and Client Metrics (8 Metrics)

The most overlooked connection metric: endpoint_client_connections rate. If you see hundreds of new connections per minute while connected_clients stays low, your application is connecting and disconnecting on every request. You're paying the TCP+TLS handshake cost — 2-5ms — on every single operation. Fix the connection pool.

Network and CPU Metrics

Network (Redis-Level)

CPU (Process-Level)

Keyspace Metrics (10 Metrics)

Keyspace metrics tell you what's inside your database: how many keys, how many expire, and whether your reads are hitting or missing. The v2 metrics separate hits and misses by read and write — more granular than the combined keyspace_hits/keyspace_misses in basic Redis INFO.

Keyspace Distribution by Data Structure (15 Metrics)

These metrics are unique to the v2 metric set — you won't find them in basic Redis monitoring. They break down your key population by data structure type and size bucket. This is how you find the oversized keys that are silently degrading performance.

All metric names are prefixed with redis_server_. If any 'large' bucket is non-zero, investigate immediately. A single sorted set with 10 million items or a string exceeding 512MB will cause latency spikes on every operation that touches it. Large keys block the Redis event loop during serialization, deletion, and persistence — affecting all other operations on that shard.

The keyspace distribution table is the fastest way to find the keys that will break your system at scale. If the 'Large' column has any non-zero value, you have a problem — even if latency looks fine today. It will degrade as traffic grows.

Replication and Syncer Metrics (9 Metrics)

These metrics cover two replication modes: standard primary-replica synchronization and Active-Active (CRDT) cross-region database synchronization. If you run geo-distributed AI agent deployments with Active-Active databases, the syncer metrics are essential for detecting cross-region lag before it causes stale context retrieval.

Client Tracking and Caching Metrics (4 Metrics)

Redis 6+ introduced server-assisted client-side caching — where the server tracks which keys a client has cached locally and sends invalidation messages when those keys change. These metrics show adoption and correctness of that protocol.

Node-Level Infrastructure Metrics (9 Metrics — Pro Only)

Pro subscriptions expose the underlying node hardware metrics — the physical machine running your Redis shards. These are invisible on Essentials plans. When Redis-level metrics look fine but performance is degraded, node-level metrics reveal whether you're hitting hardware ceilings: CPU saturation, memory exhaustion at the OS level, or network interface limits.

Labels and Tags: The Complete Taxonomy

Every v2 metric arrives pre-tagged with rich labels for filtering, grouping, and dashboard segmentation. There are 9 distinct label categories. Understanding them is the difference between a dashboard that shows 'average across everything' and one that shows 'P99 latency on shard-3 of database-prod-context in us-east-1.'

Default System Tags (Auto-Attached to All Metrics)

Redis Enterprise Core Labels

Active-Active (CRDT) Labels

Available only for Active-Active databases — geo-distributed conflict-free replicated databases across multiple regions.

Account and Subscription Labels

Attached via cluster_data metrics. Essential for multi-tenant environments, cost allocation dashboards, and subscription-level capacity planning.

CSE Labels (job=rlec_v2)

Node and Proxy Labels

Alerting Labels (job=rlec_node)

Used for infrastructure alert metrics emitted at the node level.

Critical: The db vs bdb Naming Difference

There is a naming inconsistency between metric sources that will break your dashboards and monitors if you mix them.

Always check which job the metric originates from before building queries. Mixing db and bdb labels in the same query produces empty results or incorrect aggregations. This is the #1 debugging issue when building Redis Cloud dashboards.

Query Grouping Best Practices

How you group metrics determines the granularity of your monitoring. Choose the right level for each dashboard panel.

• Avoid grouping by instance unless you are specifically debugging metric collection issues.
• Never aggregate histogram _bucket metrics without preserving the le (bucket boundary) label — you will destroy the distribution and get meaningless percentile values.
• Use custom database tags in Redis Cloud (team, environment, service) — they flow automatically into exported metrics as labels for business-context filtering.

Building Production Dashboards

Organize your Redis Cloud monitoring dashboard into six sections, each answering one operational question. For Pro subscriptions, add a seventh.

• Section 1 — Health Overview: redis_server_up status indicator, connected_clients gauge, instantaneous_ops_per_sec timeseries, memory utilization percentage. The 10-second glance that answers 'is everything OK right now?'
• Section 2 — Latency Distribution: Histogram percentile graphs for read, write, and other latency. Show P50, P90, P95, P99 on the same chart. For AI context retrieval, P99 read latency is the metric that determines user-perceived agent performance.
• Section 3 — Memory Deep Dive: used_memory vs maxmemory as a utilization gauge. Fragmentation ratio timeseries. Allocator breakdown (allocated vs active vs resident) to quantify fragmentation. Eviction rate. RDB/AOF save indicators overlaid on the latency chart to correlate fork-induced spikes.
• Section 4 — Traffic and Throughput: Read/write/other request rates as stacked area. Ingress/egress bytes for data transfer cost visibility. Request vs response count comparison to detect command drops. egress_pending for backpressure detection.
• Section 5 — Connections: Connected clients timeseries. New connection rate (endpoint_client_connections). Establishment failures. Proxy disconnections. Blocked clients. If new connections per minute significantly exceeds connected_clients, connection pooling is broken.
• Section 6 — Keyspace Intelligence: Key count and expiry count over time. Eviction rate (should be zero for context stores). Read hit ratio as a computed metric (read_hits / (read_hits + read_misses)). Keyspace distribution by data structure — any non-zero 'large' bucket should be a red indicator.
• Section 7 (Pro only) — Node Infrastructure: Node available memory, CPU utilization by mode (user/system/iowait), network packet rates and bandwidth utilization.

Alerting: 6 Monitors That Cover Production Failure Modes

Six alerts. Not twenty. Every additional alert beyond the critical set dilutes team attention and causes alert fatigue — the state where every alert is ignored because most are noise.

If your Redis monitoring has 20 alerts, you effectively have zero. The team learned to ignore them two weeks after they were created. Six well-tuned alerts with clear severity levels and runbook links outperform fifty noisy ones every time.

v2 Metrics vs Basic Redis INFO Monitoring

Many teams monitor Redis using the basic INFO command output — 30-40 metrics covering memory, clients, stats, and replication. The v2 metric set exported by Redis Cloud goes significantly deeper.

For production AI workloads running on Redis Cloud, the v2 metric set is the monitoring foundation. Basic INFO monitoring was adequate when Redis was a simple cache. When Redis holds your agent's context, vector indexes, session state, and real-time feature stores — you need the full picture.