Monitoring the state of Valkey™ clusters and hosts

1. In the management console, select the folder with the cluster you need.

2. Select Yandex Managed Service for Valkey™.

3. Click the cluster name and open the Monitoring tab.

4. To get started with Yandex Monitoring metrics, dashboards, or alerts, click Open in Monitoring in the top panel.

The following charts will open on the page:

• Cache Hit Rate: Percentage of cache hits for each host.

  Values approaching 1 indicate efficient use of the cluster as a caching server. If the percentage of cache hits is close to 0, you may need to modify the application logic, the key lifetime, or the RAM management policy in case of memory pressure.

• Client recent max input buffer size: Memory usage (in bytes) to support client connections for data writes.

• Client recent max output buffer size: Memory usage to handle client connections to retrieve data:

  • soft_limit: Soft memory usage limit.
  • hard_limit: Hard memory usage limit.
  • buffer: Current amount of data in buffer.

  If the value of buffer reaches the soft_limit, the cluster will wait a few seconds for it to decrease. If the value of buffer does not decrease, the connection will be closed.

  If the value of buffer becomes equal to the value of hard_limit, the connection will shut down immediately.

• Commands Processed: Average number of commands processed by each cluster host.

• Connected Clients: Number of open connections for each cluster host.

  If a cluster is sharded or uses replication, some of the connections will be used for exchanging data between cluster hosts.

  Errors occuring when connecting to a cluster may result from inactive applications keeping connections open too long. If this is the case, modify the Valkey™ settings to change the value of the Timeout parameter.

• Copy-on-write allocation: Memory usage (in bytes) by Valkey™ processes when using the COW (Copy-on-write) mechanism.

  The graph shows the most recent parameter values measured by Valkey™:

  • module_fork_last_cow_size: Amount of data copied during a fork() call using the COW mechanism.
  • aof_last_cow_size: Amount of data copied when creating an AOF file.
  • rdb_last_cow_size: Amount of data copied when creating an RDB file.

  For more information, see Backups.

• DB keys: Number of keys stored in all the cluster's databases.

• Evicted keys: Number of keys deleted from memory when inserting new data.

  By default, memory management uses a noeviction policy: do not delete keys and return an error if there is insufficient memory to insert new data. To use a different memory management policy, modify the Valkey™ settings to change the value of the Maxmemory policy parameter.

• Inner memory limit: Amount of RAM (in bytes) available for Valkey™ processes:

  • maxmemory: Maximum amount of memory allocated for user data.
  • used_memory: Actual memory usage by a host.

  If the value of the used_memory parameter reaches maxmemory when trying to insert new records, Valkey™ will apply the memory management mode defined by the Maxmemory policy setting.

  Note

  The value of maxmemory for Valkey™ hosts is set to 75% of the available memory. For more information, see Memory management.

• Is Alive: Indicates cluster accessibility as the sum of its hosts' states.

  Each Alive host increases the overall availability by 1. When one of the hosts fails, the overall availability is reduced by 1.
  To increase the availability of a cluster, add hosts.

• Is Master: Shows which host is and how long it has been master.

  With sharding enabled, the graph will display information on master hosts in each shard.

• Outer memory limit: Shows the total amount of RAM (in bytes) available for use on hosts:

  • memory_limit: Amount of memory allocated to each host.
  • used_memory_rss: Process memory usage by Valkey™ processes.

  When the value of used_memory_rss approaches the value of memory_limit, a Valkey™ process may be killed by the operating system. To avoid this:

  • Change the application logic to reduce the amount of data stored in Valkey™.
  • Go to the Valkey™ settings and change the Maxmemory policy value responsible for the RAM management policy in case of memory pressure.
  • upgrade the host to a higher class.

• Redis Used Memory on Masters: RAM usage on master hosts (in bytes):

  • db_hashtable_overhead: To store all database hash tables.
  • used_memory_scripts: To store and run scripts.
  • mem_aof_buffer: For the AOF buffer.
  • mem_clients_normal: To serve external connections.
  • mem_clients_slaves: To serve replication connections.
  • mem_replication_backlog: For a circular replication buffer.
  • used_memory_startup: For Valkey™ processes at startup (for example, after a cluster reboot).
  • used_memory_dataset: For data storage.

• Redis Used Memory on Replicas: RAM usage on replicas (in bytes):

  • db_hashtable_overhead: To store all database hash tables.
  • used_memory_scripts: To store and run scripts.
  • mem_aof_buffer: For the AOF buffer.
  • mem_clients_normal: To serve external connections.
  • mem_clients_slaves: To serve replication connections.
  • mem_replication_backlog: For a circular replication buffer.
  • used_memory_startup: For Valkey™ processes at startup (for example, after a cluster reboot).
  • used_memory_dataset: For data storage.

• Redis-server OOM kills: Number of Valkey™ processes terminated because of a shortage of RAM (OOM stands for out-of-memory).

  To reduce the number of terminations:

  • Change the application logic to reduce the amount of data stored in Valkey™.
  • Go to the Valkey™ settings and change the Maxmemory policy value responsible for the RAM management policy in case of memory pressure.
  • upgrade the host to a higher class.

• Replication buffer size: Replication buffer size (in bytes):

  • repl_backlog_size: Maximum amount of memory available for the replication buffer.
  • repl_backlog_histlen: Portion of the replication buffer currently in use by data.

  When the circular buffer runs out of memory, complete replication starts. This will reduce cluster performance since full replication significantly increases RAM usage as well as CPU and network workload.

• Replication lag: Replica's lag behind the master (seconds).

  A non-zero value indicates that commands take a long time to execute on a replica or that the replica is overloaded.

  For more information, see Replication and fault tolerance.

• Slowlog top operations: List of the 5 slowest commands executed on each host in the course of one minute.

  A slow command is a command whose running time has exceeded the Slowlog log slower than setting. The graph shows only the first part of a command as well as the number of times it was called in one minute.

1. In the management console, select the folder with the cluster you need.
2. Select Yandex Managed Service for Valkey™.
3. Click the name of the cluster you need and select the Hosts → Monitoring tab.
4. Select the host from the drop-down list.

This page displays charts showing the load on an individual host in the cluster:

• CPU: Load on processor cores. As the load goes up, the Idle value goes down.
• Disk bytes: Speed of disk operations (bytes per second).
• Disk IOPS: Number of disk operations per second.
• Memory: Use of RAM, in bytes. At high loads, the Free value goes down, while the other values go up.
• Network bytes: Speed of data exchange over the network, in bytes per second.
• Network packets: Number of packets exchanged over the network, per second.

The Disk bytes and the Disk IOPS charts show that the Read property increases when active database reads are in progress, and that Write increases when database writes are in progress.

For hosts with the Replica role, Received is normally greater than Sent on the Network Bytes and Network Packets charts.

1. In the management console, select the folder with the cluster you want to configure alerts for.
2. In the list of services, select  Monitoring.
3. Under Service dashboards, select:
   • Managed Service for PostgreSQL — Cluster Overview to configure cluster alerts.
   • Managed Service for PostgreSQL — Host Overview to configure host alerts.
4. In the chart you need, click and select Create alert.
5. If the chart shows multiple metrics, select a data query to generate a metric and click Continue. You can learn more about the query language in the Yandex Monitoring documentation.
6. Set the Alarm and Warning threshold values to trigger the alert.
7. Click Create alert.

1. Create an alert.
2. Add a status metric.
3. In the alert parameters, set up your alert thresholds.

1. In the management console, select the folder with the cluster you need.
2. Select Yandex Managed Service for Valkey™.
3. Hover over the indicator in the Availability column in the required cluster row.