Supported monitoring metrics

This metric shows the status of rotating certificates that are associated with machines in a cluster.

The metric can have the following statuses:

• SUCCESS: Memorystore for Redis Cluster rotated the certificate.
• FAILED: Memorystore for Redis Cluster didn't rotate the certificate because the certificate isn't available, Memorystore for Redis Cluster doesn't have permissions to rotate the certificate, or there's an internal error.
• SKIPPED: Memorystore for Redis Cluster skipped rotating the certificate because it doesn't have to be rotated.

This metric shows the peak CPU usage across all nodes in a cluster (from 0.0 to 1.0).

The metric summarizes only the sys_main_thread and user_main_thread states. It doesn't include other CPU states (such as sys_children or user_children) that are available in the /cluster/node/cpu/utilization metric.

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.

This metric shows the amount of memory that a server excludes when it evaluates the memory that it needs for key eviction.

When Memorystore for Redis Cluster calculates whether it needs to evict keys, it compares its total allocated memory (used_memory) against the configured maxmemory limit. However, the value for mem_not_counted_for_evict is subtracted from this equation.

This metric tracks the amount of memory (in bytes) that replica clients consume on a cluster node. The metric measures the memory that replica clients use.

Because replica buffers share memory with the replication backlog, the metric can report a value of 0 when replicas don't trigger an increase in memory usage beyond what's allocated for the backlog.

This metric tracks the resident set size (RSS) usage of Memorystore for Redis Cluster on a cluster node. The metric represents the number of bytes that Memorystore for Redis Cluster allocates.

Monitoring RSS usage is vital because it reflects the actual physical RAM usage so it can detect high memory fragmentation. For example, if the RSS approaches the container limit of the cluster, then this can lead to OOM issues.

This metric tracks the peak memory usage associated with copy-on-write (COW) operations during a child fork process on a cluster node. The metric measures the maximum size (in bytes) of COW memory while a child fork runs. This occurs during operations that involve forking the process, such as creating an RDB snapshot or performing an AOF rewrite.

Monitoring the peak COW size is important for capacity planning and preventing OOM issues because the total memory usage of the node increases during the fork process by the amount of data that's modified while the fork is active.

This metric tracks the current size of COW memory while a child fork process is active on a cluster node. The metric measures the size (in bytes) of memory that's copied during a fork process, such as creating an RDB snapshot or performing an AOF rewrite.

You can use the metric to monitor the real-time memory overhead of an ongoing fork.

This metric tracks the duration of the most recent background save (BGSAVE) operation for an RDB on a cluster node. The metric measures how long (in seconds) the last RDB save operation took to complete.

You can use the metric to monitor the performance impact of persistence operations, especially during maintenance or scale-out events.

This metric tracks the size of the COW memory during the most recent RDB save operation on a cluster node. The metric measures the amount of memory (in bytes) that's copied while the last RDB snapshot is created in the background.

You can use the metric to debug potential issues with full synchronizations during maintenance or configuration updates because the metric provides insights into the memory overhead of the persistence process.

This metric tracks the size of COW memory that's used during the most recent AOF rewrite operation on a cluster node. The metric measures the amount of memory (in bytes) that Memorystore for Redis Cluster copies while it performs the last background AOF rewrite.

You can use the metric to monitor the COW memory size during persistence operations. This is critical for capacity planning because the total memory usage of the node increases during the fork process by the amount of data that's modified while the fork is active. If you don't manage the COW memory, then you might experience OOM issues for the cluster.

This metric measures the change in the total number of forks over an interval. The metric is a key indicator of Memorystore for Redis Cluster's background activity.

You can use the metric to monitor the fork frequency for capacity planning because each fork process involves COW memory. COW memory increases the overall memory footprint of a cluster node.

This metric shows whether a primary cluster is synchronizing with a replica. A value of 1 indicates that the synchronization is in progress; a value of 0 signifies that the cluster isn't synchronizing with the replica.

You can use the metric to troubleshoot data consistency issues and understand the progress of scale-out or maintenance events.

This metric measures the number of failed partial resynchronization attempts.

You can use the metric as an indicator of replication health. When a partial resynchronization fails, the replica must perform a full resynchronization. This involves creating an RDB snapshot on the primary cluster and transferring the entire dataset over the network.

This metric measures the change in the number of full resynchronizations that a primary cluster has with a replica. A full resynchronization occurs when a partial resynchronization fails. This happens when the replication backlog on the primary cluster isn't large enough to hold the data that the replica missed during a disconnection.

You can use the metric to diagnose replication health and capacity issues for the cluster.

This metric reflects the maxmemory configuration setting for a cluster node, which is the maximum amount of memory that Memorystore for Redis Cluster can consume. This setting determines when Memorystore for Redis Cluster begins to evict keys, based on the configured setting for the maxmemory-policy.

You can use the metric for capacity planning and troubleshooting OOM issues because the metric defines the upper bound of memory usage for data storage and server overhead.

For more information about the maxmemory and maxmemory-policy settings, see Modifiable configuration parameters.

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 status_code field. To check if an RDB snapshot fails, filter the status_code field for the 3 - INTERNAL_ERROR status.

This metric measures the time difference (or lag) for all nodes in a cluster that passes between writing data to the AOF and when that data is synchronized successfully to durable storage.

When the appendfsync parameter is set to everysec, you can use the metric to assess the health of persistence for the cluster. Ideally, you want the distribution of the lag to have values that have less lag time (or the same time) than the synchronization frequency of the AOF.

This metric tracks the cumulative number of times that a cluster node triggers an AOF rewrite operation. You can use the metric to diagnose performance issues because a high frequency of AOF rewrites might cause latency spikes or memory pressure on the cluster.

The metric has a status_code field. To check if AOF rewrites fail, filter this field for the 3 - INTERNAL_ERROR status.

This metric measures the time difference (or lag) for a cluster node that passes between writing data to the AOF and when that data is synchronized successfully to durable storage.

When the appendfsync parameter is set to everysec, you can use the metric to assess the health of persistence for the node. If the process of synchronizing data takes longer than 1 second, then persistence lags behind the incoming data, which can lead to performance degradation or data loss in a crash scenario.

This metric tracks the cumulative number of times that a cluster node triggers an AOF rewrite operation. You can use the metric to diagnose performance issues. High frequencies of AOF rewrites can lead to increased latency or memory pressure on the cluster.

The metric has a status_code field. To check if AOF rewrites fail, filter this field for the 3 - INTERNAL_ERROR status.

This metric tracks the cumulative number of times that a cluster node restores from a persistence dump file (AOF or RDB) automatically.

The metric has a status_code field. To check if restores fail, filter this field for the 3 - INTERNAL_ERROR status.