This page lists metrics available for Memorystore for Redis Cluster and describes what each metric measures.
Backup metrics
This section lists and describes backup and import metrics.
Cluster-level metrics
This section lists and describes cluster-level backup and import metrics.
| Metric name | Description |
|---|---|
redis.googleapis.com/cluster/backup/last_backup_start_time
|
This metric shows the start time of the last backup operation. |
redis.googleapis.com/cluster/backup/last_backup_status |
This metric shows whether the most recent backup attempt completed
successfully or failed. The statuses are 1 for
Success and 0 for Failed. |
redis.googleapis.com/cluster/backup/last_backup_duration
|
This metric shows the duration of the last backup operation (in milliseconds). |
redis.googleapis.com/cluster/backup/last_backup_size |
This metric shows the size of the last backup (in bytes). This metric is a key indicator for monitoring backup efficiency and storage capacity planning. |
redis.googleapis.com/cluster/import/last_import_start_time
|
This metric shows the start time of the last import operation. |
redis.googleapis.com/cluster/import/last_import_duration
|
This metric shows the duration of the last import operation (in milliseconds). |
Certificate Authority (CA) metrics
This section lists metrics that are associated with customer-managed Certificate Authorities (CA).
Cluster-level metrics
These metrics provide a high-level overview of the certificates that are associated with machines in a cluster.
| Metric name | Description |
|---|---|
redis.googleapis.com/cluster/security/rotate_tls_cert_count
|
This metric shows the status of rotating certificates that are associated with machines in a cluster. The metric can have the following statuses:
|
Cloud Monitoring metrics
This section lists and describes Cloud Monitoring metrics that are available for Memorystore for Redis Cluster.
Cluster-level metrics
These metrics provide a high-level overview of the overall health and performance of a cluster. You can use the metrics to understand the overall capacity and utilization of a cluster as well as to identify potential bottlenecks or areas for improvement.
| Metric name | Description |
|---|---|
redis.googleapis.com/cluster/clients/average_connected_clients
|
This metric measures the average number of active client connections to a cluster over a specified time. You can use the metric to monitor connection scaling, identify application bottlenecks, and ensure that the cluster is stable. |
redis.googleapis.com/cluster/clients/maximum_connected_clients
|
This metric shows the maximum number of active client connections across all nodes of a cluster. You can use the metric to monitor the highest connection load on the cluster at any time. This is critical to ensure a high performance for the cluster because high connection counts can increase response times. |
redis.googleapis.com/cluster/clients/total_connected_clients
|
This metric tracks the current number of active client connections to a cluster. You can use the metric to monitor the load of your database and prevent connection limits. |
redis.googleapis.com/cluster/stats/total_connections_received_count
|
This metric shows the cumulative number of client connections that are created in a cluster in the last minute. You can use the metric to analyze traffic load, ensure that connection limits aren't exceeded, and determine whether you need to scale the cluster. |
redis.googleapis.com/cluster/stats/total_rejected_connections_count
|
This metric tracks the total number of connections to a cluster that
are rejected because the maxclients limit is reached. |
redis.googleapis.com/cluster/commandstats/total_usec_count
|
This metric measures the total CPU time that each command consumes. The metric indicates the total microseconds used, which provides insights into a cluster's performance and latency. |
redis.googleapis.com/cluster/commandstats/total_calls_count
|
This metric measures the total number of calls that are associated with a specific command on a cluster node in one minute. To identify bottlenecks or high traffic on specific commands, you can use the metric to monitor command throughput (commands per minute) across primary and replica nodes. |
redis.googleapis.com/cluster/cpu/average_utilization |
This metric shows the mean CPU utilization for a cluster (from 0.0 to 1.0). You can use the metric to identify overprovisioned or underutilized resources, manage auto scaling thresholds, and detect performance bottlenecks, with an ideal utilization of 40%-70%. |
redis.googleapis.com/cluster/cpu/maximum_utilization |
This metric shows the peak CPU usage across all nodes in a cluster (from 0.0 to 1.0). The metric summarizes only the Make sure that CPU utilization doesn't exceed 0.8 seconds for the primary node and 0.5 seconds for each replica that's designated as a read replica. For more information, see CPU usage best practices. |
redis.googleapis.com/cluster/stats/average_expired_keys
|
This metric measures the mean number of key expiration events for all primary nodes of a cluster. You can use the metric to monitor the number of keys that are expiring. |
redis.googleapis.com/cluster/stats/maximum_expired_keys
|
This metric measures the maximum number of key expiration events that are occurring across all primary nodes of a cluster. |
redis.googleapis.com/cluster/stats/total_expired_keys_count
|
This metric tracks the total number of key expiration events that are occurring across all primary nodes of a cluster. You can use the metric to monitor the number of keys that are expiring. |
redis.googleapis.com/cluster/stats/average_evicted_keys
|
This metric tracks the mean number of keys that are evicted because of memory capacity constraints across the primary shards of a cluster. |
redis.googleapis.com/cluster/stats/maximum_evicted_keys
|
This metric shows the highest number of keys that are evicted from a node or shard of a primary cluster because of memory capacity. |
redis.googleapis.com/cluster/stats/total_evicted_keys_count
|
This metric shows the total number of keys that are evicted by a node of of a primary cluster because of memory capacity. |
redis.googleapis.com/cluster/keyspace/total_keys |
This metric shows the number of keys that are stored in a cluster. |
redis.googleapis.com/cluster/stats/average_keyspace_hits
|
This metric shows the mean number of successful lookups of keys across all nodes in a cluster. |
redis.googleapis.com/cluster/stats/maximum_keyspace_hits
|
This metric shows the maximum number of successful lookups of keys in a cluster node. You can use the metric to monitor the cluster's performance and to identify potential hotspots across the cluster. |
redis.googleapis.com/cluster/stats/total_keyspace_hits_count
|
This metric tracks the cumulative number of successful lookups of keys across all nodes in a cluster. |
redis.googleapis.com/cluster/stats/average_keyspace_misses
|
This metric shows the mean number of failed lookups of keys across a cluster. You can use the metric to track how often keys are requested but aren't found in the cache. |
redis.googleapis.com/cluster/stats/maximum_keyspace_misses
|
This metric shows the maximum number of failed lookups of keys across a cluster node. |
redis.googleapis.com/cluster/stats/total_keyspace_misses_count
|
This metric shows the total number of failed lookups of keys across all cluster nodes. |
redis.googleapis.com/cluster/memory/average_utilization
|
This metric shows the mean memory utilization across a cluster (from 0.0 to 1.0). You can use the metric to monitoring the cluster's capacity and to set alert thresholds. For example, you can set an alert threshold to notify users when the average memory exceeds a specific percentage (for example, 80%). |
redis.googleapis.com/cluster/memory/maximum_utilization
|
This metric shows the maximum memory utilization across all cluster nodes (from 0.0 to 1.0). You can use the metric to identify when to scale a cluster. We recommend that you monitor usage to ensure that it stays under 100%. Under high write loads, performance might degrade if this metric reaches 65% to 85%. |
redis.googleapis.com/cluster/memory/total_used_memory |
This metric shows the total memory usage of a cluster (in bytes). You can use the metric to monitor the cluster's capacity. |
redis.googleapis.com/cluster/memory/size |
This metric measures the total, used, and available RAM across all nodes in a cluster. You can use the metric to monitor the cluster's capacity and to prevent node failures. |
redis.googleapis.com/cluster/replication/average_ack_lag
|
This metric shows the mean acknowledgement lag (in seconds) of replicas
across a cluster.
Acknowledgment lag is a bottleneck on the primary node in a cluster. This bottleneck is caused by its replicas that can't keep up with the information that the primary node sends to them. When this happens, the primary node must wait for the acknowledgment that the replicas received the information. This might slow down transaction commits and cause a performance hit on the primary node. |
redis.googleapis.com/cluster/replication/maximum_ack_lag
|
This metric shows the maximum acknowledgement lag (in seconds) of replicas across a cluster. |
redis.googleapis.com/cluster/replication/average_offset_diff
|
This metric shows the mean replication acknowledge offset diff (in
bytes) across a cluster.
Replication acknowledge offset diff means the number of bytes that aren't replicated between replicas and their primary clusters. |
redis.googleapis.com/cluster/replication/maximum_offset_diff
|
This metric shows the maximum replication offset diff (in bytes) across
a cluster. Replication offset diff means the number of bytes that aren't replicated between replicas and their primary clusters. |
redis.googleapis.com/cluster/stats/total_net_input_bytes_count
|
This metric shows the count of incoming network bytes that a cluster's endpoints receives. |
redis.googleapis.com/cluster/stats/total_net_output_bytes_count
|
This metric shows the count of outgoing network bytes that a cluster's endpoints sends. |
Node-level metrics
These metrics offer detailed insights into the health and performance of individual nodes within a cluster. You can use the metrics to troubleshoot issues with the nodes to optimize their performance.
| Metric name | Description |
|---|---|
redis.googleapis.com/cluster/node/clients/connected_clients
|
This metric indicates the number of active client connections to a cluster node, excluding replica connections. You can use the metric to monitor connection limits and to identify hotspots where a shard receives disproportionate traffic. |
redis.googleapis.com/cluster/node/clients/blocked_clients
|
This metric shows the number of client connections that a cluster node blocks. A high or rapidly increasing number of blocked client connections might indicate that many clients are waiting on operations. This can lead to an increased latency. |
redis.googleapis.com/cluster/node/server/uptime |
This metric measures the uptime of a cluster node. You can use the metric to track how long a server runs continuously without a reboot or failure. |
redis.googleapis.com/cluster/node/stats/connections_received_count
|
This metric tracks the total number of client connections that are created on a cluster node within a specified period. You can use the metric to monitor connection traffic to individual nodes within a cluster. As a result, you can analyze load distribution and identify spikes in connection activity. |
redis.googleapis.com/cluster/node/stats/rejected_connections_count
|
This metric shows the number of connections that are rejected because
a cluster node reaches the maxclients limit. You can use the
metric to identify if a node is under high-connection pressure and is
refusing new connections because it can't handle more connections. |
redis.googleapis.com/cluster/node/commandstats/usec_count
|
This metric shows the total time that each command consumes in a cluster node. You can use the metric to analyze the performance of commands, identify slow commands, and troubleshoot latency issues at the node level. |
redis.googleapis.com/cluster/node/commandstats/calls_count
|
This metric tracks the total number of calls for a command on a cluster node per minute. You can use the metric to monitor traffic distribution, identify heavily used commands, and troubleshoot bottlenecks on individual nodes. |
redis.googleapis.com/cluster/node/cpu/utilization |
This metric shows the CPU utilization for a cluster node (from 0.0 to 1.0). |
redis.googleapis.com/cluster/node/stats/expired_keys_count
|
This metric shows the total number of expiration events in a cluster node. You can use the metric to monitor the rate at which keys are being removed from the cluster because their time to live (TTL) reaches zero. |
redis.googleapis.com/cluster/node/stats/evicted_keys_count
|
This metric counts the total number of keys that a cluster node evicts because the cluster reaches its maximum memory limit. The metric can identify if a cluster is under memory pressure. High or rising counts of evicted keys indicate that a cluster is running out of space. As a result, the cluster removes keys to make room for new data. |
redis.googleapis.com/cluster/node/keyspace/total_keys |
This metric measures the total number of keys that a cluster node stores. The metric provides visibility into data distribution and sharding across nodes. |
redis.googleapis.com/cluster/node/stats/keyspace_hits_count
|
This metric tracks the number of successful key lookups on a cluster node. You can use the metric to monitor the efficiency that the node has to retrieve in-memory data. |
redis.googleapis.com/cluster/node/stats/keyspace_misses_count
|
This metric tracks the number of failed key lookups on a cluster node. |
redis.googleapis.com/cluster/node/memory/utilization |
This metric tracks the memory utilization in a cluster node (from 0.0 to 1.0). You can use the metric to prevent node failures and to ensure a cluster's stability. |
redis.googleapis.com/cluster/node/memory/usage |
This metric measures the total memory usage of a cluster node. |
redis.googleapis.com/cluster/node/stats/net_input_bytes_count
|
This metric measures the total number of incoming network bytes that a cluster node receives. You can use the metric to monitor the network throughput, identify potential bottlenecks, and analyze traffic spikes on the node. |
redis.googleapis.com/cluster/node/stats/net_output_bytes_count
|
This metric measures the total number of outgoing network bytes that a cluster node sends. You can use the metric to monitor the network egress volume for the node for performance tuning and capacity planning purposes. |
redis.googleapis.com/cluster/node/replication/offset |
This metric measures the replication offset bytes of a cluster node. Before you promote the replicas of a cluster to primary clusters, you can use the metric to check whether the replicas processed all data. This prevents data loss. |
redis.googleapis.com/cluster/node/server/healthy |
This metric determines whether a cluster node is available and functioning correctly. |
Cross-region replication metrics
This section lists and describes cross-region replication metrics.
| Metric name | Description |
|---|---|
redis.googleapis.com/cluster/cross_cluster_replication/secondary_replication_links
|
This metric shows the number of shard links between the primary and secondary clusters. Within a cross-region replication group, a primary cluster reports the number of CRR replication links that it has with the secondary clusters in the group. For each secondary cluster, this number is expected to be equal to the number of shards. If, unexpectedly, the number drops below the number of shards, this identifies the number of shards where replication between the replicator and follower has ceased. In an ideal state, this metric should have the same number as the primary cluster shard count. |
redis.googleapis.com/cluster/cross_cluster_replication/secondary_maximum_replication_offset_diff |
This metric measures the maximum replication offset difference (in bytes) between the primary and secondary (replica) shards of a cluster across different regions. |
redis.googleapis.com/cluster/cross_cluster_replication/secondary_average_replication_offset_diff |
This metric measures the average replication offset difference (in bytes) between the primary and replica shards of a cluster across different regions. High values for the metric indicate a replication lag, which you can resolve by pausing and then resuming the replication. |
Persistence metrics
This section lists and describes persistence metrics.
RDB persistence metrics
This section lists and describes Redis database (RDB) persistence metrics.
Cluster-level metrics
This section lists and describes cluster-level RDB persistence metrics.
| Metric name | Description |
|---|---|
redis.googleapis.com/cluster/persistence/rdb_saves_count |
This metric tracks the cumulative number of times that an RDB persistence snapshot (also known as an RDB save) is taken on a cluster node. You can use the metric to monitor the frequency and success of RDB snapshots on a per-node basis. The metric has a |
redis.googleapis.com/cluster/persistence/rdb_save_ages |
This metric shows a distribution snapshot age for all nodes across a cluster. In the case of a recovery incident, you can use the metric to view the timeframe for data staleness. Ideally, the distribution has values that have less lag time (or the same lag time) than your snapshot frequency. |
Node-level metrics
| Metric name | Description |
|---|---|
redis.googleapis.com/cluster/node/persistence/rdb_bgsave_in_progress
|
This metric indicates whether an RDB background save
(BGSAVE) is active on a cluster node. A status of
TRUE means that the BGSAVE is active. |
redis.googleapis.com/cluster/node/persistence/rdb_last_bgsave_status
|
This metric indicates whether the BGSAVE operation on a
cluster node completed or encountered an error. A status of
TRUE means that the operation completed. |
redis.googleapis.com/cluster/node/persistence/rdb_saves_count
|
This metric tracks the cumulative number of RDB snapshots that are created on a cluster node. You can use the metric to monitor the frequency and success of snapshots on the node. |
redis.googleapis.com/cluster/node/persistence/rdb_last_save_age
|
This metric measures the time, in seconds, that elapsed since the last successful RDB snapshot. You can use the metric to monitor the staleness of RDB persistence data on a cluster node. |
redis.googleapis.com/cluster/node/persistence/rdb_next_save_time_until
|
This metric measures the time remaining, in seconds, until the next RDB snapshot is scheduled to occur on a cluster node. You can use the metric to monitor the schedule of RDB persistence and track when the next automatic snapshot is taken. |
redis.googleapis.com/cluster/node/persistence/current_save_keys_total
|
This metric tracks the total number of keys that are processed in the current RDB save operation on a cluster node. |
AOF persistence metrics
Cluster-level metrics
| Metric name | Description |
|---|---|
redis.googleapis.com/cluster/persistence/aof_fsync_lags
|
This metric shows a distribution of the lag (from data write to durable storage sync) for all nodes in the cluster. It is only emitted for clusters with appendfsync=everysec. Ideally you want to see the distribution have values that have less lag time (or the same time) than your AOF sync frequency. |
redis.googleapis.com/cluster/persistence/aof_rewrite_count
|
This metric shows the cumulative number of times for your cluster that a
node has triggered an AOF rewrite. This metric has a
status_code field. To check if AOF rewrites are failing, you
can filter the status_code field for the following error:
3 - INTERNAL_ERROR |
Node-level metrics
| Metric name | Description |
|---|---|
redis.googleapis.com/cluster/node/persistence/aof_last_write_status
|
This metric shows the success of the most recent AOF write on the cluster node. TRUE means success, if no write has occurred the value might default to TRUE. |
redis.googleapis.com/cluster/node/persistence/aof_last_bgrewrite_status
|
This metric shows the success of the last AOF bgrewrite operation on the cluster node. TRUE means success, if no bgrewrite has occurred the value might default to TRUE. |
redis.googleapis.com/cluster/node/persistence/aof_fsync_lag
|
This metric shows the AOF lag between memory and persistent store in the cluster node. It is only applicable for AOF enabled clusters where appendfsync=EVERYSEC |
redis.googleapis.com/cluster/node/persistence/aof_rewrites_count
|
This metric shows the count of AOF rewrites in the cluster node. To
check if AOF rewrites are failing, you can filter the
status_code field for the following error: 3 - INTERNAL_ERROR
|
redis.googleapis.com/cluster/node/persistence/aof_fsync_errors_count
|
This metric shows the count of AOF fsync() call errors and is only applicable for AOF enabled clusters where appendfsync=EVERYSEC|ALWAYS. |
Common persistence metrics
Metrics that are applicable to both AOF and RDB persistence mechanisms.
Node-level metrics
| Metric name | Description |
|---|---|
redis.googleapis.com/cluster/node/persistence/auto_restore_count
|
This metric shows the count of restores from the dumpfile (AOF or RDB). |
Sample use cases for persistence metrics
Check if AOF write operations cause latency and memory pressure
Suppose that you detect increased latency or memory usage on your cluster or the node within the cluster. In this case you might want to check if the extra usage is related to AOF persistence.
Because you know AOF rewrite operations can trigger transient load spikes, you
can inspect the aof_rewrites_count metric which gives you the cumulative count
of AOF rewrites over the lifetime of the cluster or the node within the cluster.
Suppose this metric shows you that increments in the rewrites count correspond
to latency increases. In this circumstance you could address the issue by
reducing the write rate or increasing the shard count to reduce the frequency of
rewrites.
Check if RDB save operations cause latency and memory pressure
Suppose that you detect increased latency or memory usage on your cluster or the node within the cluster. In this case you might want to check if the extra usage is related to RDB persistence.
Because you know RDB save operations can trigger transient load spikes, you can
inspect the rdb_saves_count metric which gives the cumulative count of RDB
saves over the lifetime of the cluster or the node within the cluster. Suppose
this metric shows you that increments in the RDB saves count correspond to
latency increases. In this circumstance you could reduce the RDB snapshot
interval to lower the frequency of rewrites. You could also scale out the
cluster to reduce the baseline load levels.
Interpret metrics for Memorystore for Redis Cluster
As seen in the list above, many of the metrics share three categories: average, maximum, and total.
For Memorystore for Redis Cluster, we provide average and maximum variations of the same metric so you can use both metrics to identify hotspots for that metric family.
The total value for the metric is independent, and provides separate insights unrelated to the purpose of the average and maximum variations for hotspots.
Understand average and maximum metrics
Suppose you compare the average_keyspace_hits and maximum_keyspace_hits
values for your cluster. As the difference between the two metrics grows, a
greater difference indicates that there are more hotspots for hits in your
cluster. A close value between average_keyspace_hits and
maximum_keyspace_hits indicates that hits are distributed across your
cluster more evenly.
This principle applies to all metrics that have the average and maximum variations of the same metric.
Hotspot example
If you compare average_keyspace_hits and maximum_keyspace_hits for all of
the shards in your cluster, comparing these values indicates where hotspots
occur. For example, suppose shards in a 6-shard cluster have the following
number of hits:
- Shard 1 – 2 hits
- Shard 2 – 2 hits
- Shard 3 – 2 hits
- Shard 4 – 2 hits
- Shard 5 – 2 hits
- Shard 6 – 8 hits
In this example the average_keyspace_hits returns a value of 3, and the
maximum_keyspace_hits returns 8, indicating that shard 6 is hot.
We provide node-level metrics that you can use to identify hotspots in the cluster.