Supported monitoring metrics

redis.googleapis.com/keyspace/avg_ttl

This metric measures the average time to live (TTL), in milliseconds, of all keys in a Redis database that have an expiration set. You can use the metric to understand the lifecycle of your cached data and identify if keys are expiring sooner or later than expected across your instances.

redis.googleapis.com/clients/blocked

This metric tracks the number of client connections that are waiting for data to become available because blocking commands are running in an instance. These blocking commands include BLPOP , BRPOP , and BRPOPLPUSH . A high number of blocked clients might indicate that your application is waiting on certain events or keys to be populated.

You can monitor this metric to understand the behavior of your application, especially if you see unexpected increases in latency that might be tied to clients waiting on blocking operations.

redis.googleapis.com/replication/master/slaves/lag

This metric measures the number of seconds that a replica lags behind a primary instance. Memorystore for Redis calculates the value for the metric by taking the current time and subtracting the time at which the replica acknowledges receiving the message of incoming bytes.

You can use the metric to identify if a replica falls behind the primary instance.

redis.googleapis.com/replication/offset_diff

This metric tracks the number of bytes that aren't replicated to a replica. The metric represents the difference between the replication byte offset of a primary instance and the replication byte offset of the replica. If there's no difference between these offsets, then the replica is fully in synchronization with the primary instance.

As the primary instance replicates data to the replica during a failover process, you might notice an increase in these pending bytes.

redis.googleapis.com/stats/cache_hit_ratio

This metric represents the ratio of successful Redis database calls to unsuccessful calls. A call is successful when the Redis database returns the value that the caller requested.

A higher cache-to-hit ratio means that the cache is more fully utilized. This is beneficial for the performance of your application.

redis.googleapis.com/commands/calls

This metric measures the number of Redis commands that are run each minute on a primary instance. These include all open source Redis commands, including SET , GET , and HSET . The metric doesn't count Memorystore for Redis commands such as create or update .

redis.googleapis.com/clients/connected

This metric displays the number of clients that are connected to an instance. You can monitor the metric to identify the load on the instance. If the number of connected clients approaches the maxclients limit, then the server might reject new connection attempts.

redis.googleapis.com/stats/cpu_utilization

This metric measures the CPU usage time per minute that the Redis server uses. This time is broken down by the system-user space and the parent-child relationships.

The value for CPU seconds shows the total CPU seconds for all threads of the Redis server's main process. If you want to see the CPU usage for the main thread only, then view the Main Thread CPU Seconds ( cpu_utilization_main_thread ) metric.

High CPU utilization is a common cause for increased latency in Redis instances because it can lead to delays in command processing. By monitoring this metric, you can identify if a high load from numerous clients drives the CPU usage.

redis.googleapis.com/stats/evicted_keys

This metric shows the number of keys that Memorystore for Redis evicts from an instance because the instance reaches the maxmemory limit.

By monitoring this metric, you can determine if the instance's memory size is sufficient for your workload. If frequently accessed data is removed from the cache, then the key evictions can impact your application's performance.

redis.googleapis.com/keyspace/keys_with_expiration

This metric tracks the number of keys in an instance that have an expiration configured. If no keys have an expiration, then "no data" is displayed in the chart for the metric.

redis.googleapis.com/keyspace/keys

This metric shows the total number of keys that are stored in a database. If no keys are stored, then "no data" is displayed in the chart for the metric.

redis.googleapis.com/stats/cpu_utilization_main_thread

This metric measures the CPU-seconds that the Redis server's main thread uses. This measurement is broken down by the system-user space and the parent-child relationship. You can monitor the metric to identify CPU usage spikes that occur on the main thread.

redis.googleapis.com/stats/memory/maxmemory

This metric represents the maximum amount of memory ( maxmemory ) that keys can use in an instance. After this limit is reached, Memorystore for Redis evicts keys from the instance. This eviction process occurs in accordance with the eviction policy that's configured for the instance.

redis.googleapis.com/stats/memory/usage_ratio

This metric shows the current memory usage of an instance that's expressed as a ratio of its maximum memory limit. You can monitor the metric to determine how close the instance is to its capacity. Based on the instance's configuration, reaching this limit triggers the key eviction process.

redis.googleapis.com/stats/keyspace_misses

This metric tracks the number of failed lookups of keys in the main dictionary. Every time a client attempts to access a key that doesn't exist in the database, the metric increments.

The metric is used to calculate the cache-to-hit ratio, which measures how effectively your application uses the cache. A high number of keyspace misses often indicates that the application is requesting data that isn't present in the cache. If the application has to fetch that data from a slower, backend datastore, then this can lead to increased latency.

redis.googleapis.com/replication/role

This metric returns a value that identifies the role of a node in a replication group. A value of 1 indicates that the node is a primary; a value of 0 signifies that the node is a replica.

You can use the metric to monitor the status of nodes, especially during failover events where roles might switch. In addition, you can track the health and topology of Standard Tier instances, which support high availability through replication.

redis.googleapis.com/persistence/rdb/bgsave_in_progress

This metric returns a value that identifies whether a background save ( BGSAVE ) operation of the Redis database (RDB) is active. A value of 1 indicates that a background RDB save is active; a value of 0 signifies that no background save is running.

You can use the metric to track automated RDB snapshots or manual exports. In addition, by monitoring the metric, you can correlate transient spikes in memory usage or latency with ongoing persistence tasks.

redis.googleapis.com/stats/pubsub/channels

This metric tracks the global number of Pub/Sub channels that have active client subscriptions in an instance. The metric measures the total count of unique channels to which clients are subscribed by using the SUBSCRIBE or PSUBSCRIBE commands.

redis.googleapis.com/stats/pubsub/patterns

This metric tracks the global number of Pub/Sub patterns that have active client subscriptions in an instance. The metric measures the total count of unique patterns to which clients are subscribed. Clients typically create these subscriptions by using the PSUBSCRIBE command.

redis.googleapis.com/stats/reject_connections_count

This metric tracks the number of connection attempts that an instance rejects because of the following reasons:

• The maxclients limit: the server reaches the maximum allowed number of concurrent client connections.
• Memory pressure: the instance rejects new connections because of high memory utilization.
• An invalid TLS connection: an instance where in-transit encryption is enabled has TLS-related issues.

By monitoring the metric, you can identify capacity issues. If the number of rejected connections increases, then you might either need to scale the instance to handle more connections or increase the instance's memory capacity. In addition, when encryption is enforced, you can use the metric to help debug client-side connection issues.

redis.googleapis.com/replication/master_repl_offset

This metric represents the total number of bytes that a primary instance produces and sends to a replica. By subtracting the Replication Byte Offset of the replica from this offset, you can calculate the size of the replication delay. When there's no difference between these offset values, then the replica is fully synchronized with the primary instance.

redis.googleapis.com/replication/master/slaves/offset

This metric indicates the total number of bytes that a replica receives from a primary instance. By subtracting this offset from the Replication Byte Offset of the primary instance, you can calculate the size of the replication delay. When there's no difference between these offset values, then the replica is fully synchronized with the primary instance.

redis.googleapis.com/stats/memory/system_memory_usage_ratio

This metric represents the amount of memory that's in use, expressed as a ratio of the total memory that's available for the system. The total available system memory is the memory that you provision for an instance plus additional memory that Memorystore for Redis provides to manage overhead processes.

redis.googleapis.com/stats/memory/system_memory_overload_duration

This metric measures the total amount of time (in microseconds) that an instance is in system memory overload mode.

You can use the metric to track periods where the instance's memory usage exceeds safe operating thresholds for the system. Persistent values in the metric might indicate that the instance is at risk of performance degradation or instability because of insufficient memory for overhead processes.

redis.googleapis.com/commands/usec_per_call

This metric represents the average time spent for each Redis command call over one minute. This time is measured in microseconds.

The metric is broken down by individual commands. This lets you monitor the performance of specific operations, such as GET , SET , and HSET .

You can also use the metric to measure instance latency. By comparing the time per call at different points, you can identify changes in performance and investigate the causes of a latency discrepancy.

redis.googleapis.com/stats/connections/total

Total number of connections accepted by the server.

redis.googleapis.com/commands/total_time

Total amount of time spent per open source Redis command (e.g. SET, GET, HSET, etc…) in microseconds over the last second. For example if SET used 800,000 microseconds it would mean that it took 80% of one CPU core to process all SET commands combined.

redis.googleapis.com/stats/network_traffic

Total number of bytes sent to/from Redis (includes bytes from commands themselves, payload data, and delimiters).

redis.googleapis.com/server/uptime

Uptime of the running Redis server process

redis.googleapis.com/stats/memory/usage

Total number of bytes allocated by the Redis server process.