Supported monitoring metrics

This page lists metrics that are available for Memorystore for Redis and describes what each metric measures.

To learn how to view these metrics, see Monitor instances.

Cloud Monitoring metrics

This section lists and describes Cloud Monitoring metrics that are available for Memorystore for Redis.

Metric name Description
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 This metric represents the total number of connections that the server accepts.
redis.googleapis.com/commands/total_time This metric measures the total amount of time, in microseconds, spent on each open source Redis command (such as SET, GET, or HSET) over the last second. For example, if the SET command uses 800,000 microseconds, then it takes 80% of a single CPU core to process all instances of that command combined.
redis.googleapis.com/stats/network_traffic This metric represents the total number of bytes that are sent to or from Redis. This count includes the bytes from the commands, the payload data, and any delimiters.
redis.googleapis.com/server/uptime This metric indicates the uptime of the running Redis server process.
redis.googleapis.com/stats/memory/usage This metric represents the total number of bytes that the Redis server process allocates.

Instance details metrics

The following metrics are available for an instance on the Instance details page of the Google Cloud console:

Metric name Description
Bytes pending replication

This metric shows the amount of data that's written to a primary node, but isn't copied to a replica node. This represents the difference between the replication byte offset of the primary instance and the offset of the replica.

A value of zero for the metric indicates that the replica is fully synchronized with the primary instance. A high value typically occurs during periods of high write activity or during a failover process because data is being synchronized.

Cache hit ratio

This metric shows the ratio of successful Redis database calls (hits) to the total number of calls (hits plus misses). The metric represents how effectively your application uses the cache.

A higher cache-to-hit ratio indicates that more requests are being fulfilled directly from the cache. This is beneficial for the performance of your application because it reduces latency.

A low or dropping ratio often indicates that your application requests data that isn't present in the cache. This might require you to increase the size of the instance or adjust your data population logic.

Calls

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

You can use the metric to measure and analyze the instance's latency. By comparing the volume of calls with the time spent on them, you can identify changes in performance and investigate what might cause latency spikes.

CPU seconds

This metric shows the total CPU usage time (in seconds) that an instance uses over a specific period.

By monitoring this metric, you can determine whether the instance has a high CPU usage. This is a frequent cause of increased latency because high CPU utilization can delay the processing of commands. You can also use the metric to determine whether a high load from a large number of clients drives the CPU usage.

Instance uptime

This metric indicates the total amount of time that the Redis server process runs continuously. If an instance restarts because of a failover, maintenance, or an unexpected crash, the value for the metric drops to zero, and then increases again from the new start time.

You can use the metric to identify and correlate unexpected service interruptions, failover events, or maintenance windows with other performance changes.

Keys in database

This metric shows the total number of keys that are stored in each Redis database within an instance. The metric tracks all keys that reside in the databases, regardless of whether the keys have an expiration set. If no keys are stored in the databases, then "no data" is displayed in the chart for the metric, rather than a zero value.

You can monitor the metric to verify that the instance receives traffic and stores data. A sudden drop in the metric might indicate data loss, mass eviction, or an instance restart.

Memory Usage / Max Memory A chart that shows memory usage compared to the maxmemory limit for your instance.
Evicted Keys / Expired Keys A chart that displays the number of evicted keys and expired keys.
Connected Clients / Blocked Clients A chart that displays the number of connected clients and blocked clients.
Network Bytes In/Out A chart that displays the number of bytes sent and received by the instance over a given period.

RDB Snapshots metrics

The following metrics help you manage RDB Snapshots for Memorystore for Redis.

Snapshot monitoring metrics

Metric name Full endpoint URL Description
Snapshot mode redis.googleapis.com/rdb/enabled Indicates if the RDB snapshot mode is enabled
Next snapshot time redis.googleapis.com/rdb/snapshot/time_until_next_run Seconds until the next scheduled snapshot.

Snapshot status metrics

Metric name Full endpoint URL Description
RDB snapshot in progress redis.googleapis.com/rdb/snapshot/in_progress Indicates if RDB snapshot is in progress. When the metric value is true, then an RDB snapshot is in progress.
RDB snapshot elapsed time redis.googleapis.com/rdb/snapshot/elapsed_time Indicates increasing time elapsed while creating the current snapshot.
RDB snapshot attempts count redis.googleapis.com/rdb/snapshot/attempt_count Indicates number of snapshot attempts every minute.
RDB snapshot last status redis.googleapis.com/rdb/snapshot/last_status Indicates status of the most recent snapshot attempt.
RDB snapshot duration redis.googleapis.com/rdb/snapshot/last_success_duration Indicates the total time required to write the last successful snapshot, not including failed attempts.
RDB snapshot age redis.googleapis.com/rdb/snapshot/last_success_age Indicates time elapsed since the start of the last successful snapshot.

Snapshot recovery metrics

Metric name Full endpoint URL Description
RDB recovery in progress redis.googleapis.com/rdb/recovery/in_progress Indicates if recovery from an RDB snapshot is in progress. When the metric value is true, then a recovery is in progress.
RDB recovery elapsed time redis.googleapis.com/rdb/recovery/elapsed_time Indicates increasing time elapsed for an in-progress recovery from an RDB snapshot.
RDB recovery estimated time redis.googleapis.com/rdb/recovery/estimated_recovery_time Indicates the expected recovery time when using the last successful snapshot for recovery.
RDB recovery remaining time redis.googleapis.com/rdb/recovery/estimated_remaining_time Indicates remaining time to finish recovery from an RDB snapshot.
RDB recovery attempts redis.googleapis.com/rdb/recovery/attempts_since_last_success Indicates number of recovery attempts since the last successful recovery attempt.
RDB recovery last status redis.googleapis.com/rdb/recovery/last_status Indicates status of the most recent recovery.
RDB recovery last duration redis.googleapis.com/rdb/recovery/last_duration Indicates time it took to restore the last snapshot.
RDB Snapshot Size redis.googleapis.com/rdb/recovery/total_bytes_count Indicates the size of the snapshot.
RDB Load progress redis.googleapis.com/rdb/recovery/loaded_bytes_count During a recovery, indicates how many bytes have loaded. 0 if the recovery is not active.