PostgreSQL cluster and host state monitoring

Data on the cluster and host state is available in the management console. You can view them on the Monitoring tab of the cluster management page or in Yandex Monitoring.

Diagnostic information about cluster states is presented as graphs.

Chart update rate:

• Standard hosts and hosts with an increased RAM to vCPU ratio (memory-optimized): 15 seconds.
• Hosts with a guaranteed vCPU share under 100% (burstable): 150 seconds.

You can configure alerts in Yandex Monitoring to receive notifications about cluster failures. In Yandex Monitoring, there are two alert thresholds: Warning and Alarm. If the specified threshold is exceeded, you will receive alerts via the configured notification channels.

To identify potential issues in a cluster, use other cluster diagnostic tools alongside monitoring.

Monitoring the cluster stateMonitoring the cluster state

To view detailed information on the health state of a Managed Service for PostgreSQL cluster:

1. Navigate to Managed Service for PostgreSQL.

2. Click the name of your cluster and select the Monitoring tab.

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

You will see the following charts:

• Under Cluster:

  • PostgreSQL Alive, [boolean]: PostgreSQL health for each host either as a master or as a replica.

  • Is Primary, [boolean]: Shows which host is the master and for how long.

  • Replication lag: Replication delay time.

    Warning

    The replication lag is calculated with one-second accuracy. A lag of less than one second cannot be tracked using this metric.

  • Average CPU usage: Average transaction processing and operator execution time.

  • Maximum CPU usage: Peak processor core load.

  • Maximum memory usage: Peak RAM usage (in bytes). At high loads, the value of the Free space metric decreases, while the others increase.

  • Log errors: Number of errors logged per second.

  • OOM Count: Indicates the presence of Out-Of-Memory Killer processes. OOM Killer mechanism terminates memory exhausting applications, preventing the OS from crashing.

• Under Disk:

  • Disk usage on primary: Disk space utilization on the master host (bytes).
  • Disk read/write bytes: Speed of disk read and write operations (bytes per second).
  • Disk read/write IOPS: Intensity of disk read and write operations (operations per second).
  • Disk usage by DB: Disk space utilization, broken down by database, in bytes.
  • Inode usage on primary: Number of inodes used on the master host.
  • Inode usage by host: Number of inodes used by each host.
  • Total size of temporary files: Total size of temporary files in bytes.
  • Total size of WAL files: Total size of WAL files in bytes.
  • Free space: Free disk space broken down by host, in bytes.
  • WAL rate in bytes per second: WAL file write speed in bytes per second.

• Under Transactions:

  • Transactions/statements per second: Number of transactions and statements per second.
  • Average transaction/statement time: Average transaction/statement processing time.
  • Age of oldest transaction/statement: Age of the oldest transaction/request.
  • Statement quantiles: Statement execution time, broken down by percentile.
  • Transaction quantiles: Transaction processing time, broken down by percentile.
  • Used/Free Transaction IDs (%): Percentage of used/free transaction IDs.
  • Used/Free Transaction IDs.

• Under Vacuum:

  • Vacuum processes: Number of processes performing the vacuuming operation.
  • Scanning progress: Scanning progress during vacuuming.
  • Vacuuming progress: Progress of the vacuuming operation.

• Under Sessions:

  • Sessions read bytes per second: Amount of data read in bytes, broken down by session type.
  • Sessions write bytes per second: Amount of data written in bytes, broken down by session type.
  • Session CPU usage cores: Number of used processor cores, broken down by session type.
  • Sessions per wait event: Number of waiting sessions, broken down by wait event type.

• Under Connections:

  • Pooler is alive, [boolean]: Connection pooler health for each host either as a master or as a replica.
  • Total pooler connections: Number of pooler connections, both client and server.
  • TCP connections: Number of TCP connections per second.

• Under Network:

  • Packets received/sent: Network packet exchange rate, in packets per second.
  • Network received/sent bytes: Network data exchange rate, in bytes per second.

Host state monitoringHost state monitoring

To view detailed information on the state of individual Managed Service for PostgreSQL hosts:

1. Navigate to Managed Service for PostgreSQL.
2. Click the name of your cluster and select the Hosts tab.
3. Click the line of the host in the list.

This page displays workload charts for an individual cluster host:

• CPU usage: Processor core workload. With increased workload, the Idle value drops.

• Memory usage: Use of RAM, in bytes. At high loads, the value of the Free space metric decreases, while the others increase.

• Disk usage: Disk space usage in bytes.

• Disk usage by DB: Disk space utilization, broken down by database, in bytes.

• Disk IOPS: Number of disk operations per second.

• Network packets: Network packet exchange rate, in packets per second.

• Network bytes: Network data transfer rate, in bytes per second.

• Disk Metrics Details:

  • Disk used quota: Average and maximum quota used percentage for disk operations.
  • Disk read throttler latency (percentiles): Read delay introduced by exceeding disk quota, percentiles.
  • Disk write throttler latency (percentiles): Write delay introduced by exceeding disk quota, percentiles.
  • Disk read latency (percentiles): Disk read latency, percentiles.
  • Disk write latency (percentiles): Disk write latency, percentiles.
  • Disk read operations: Average and maximum number of read operations per second.
  • Disk write operations: Average and maximum number of write operations per second.
  • Disk read bytes: Average and maximum disk read rate, bytes per second.
  • Disk write bytes: Average and maximum disk write rate, bytes per second.

The Disk IOPS chart shows the increase in the Read value during database read activity, and in Write, during database write activity.

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

Setting up alerts in Yandex MonitoringSetting up alerts in Yandex Monitoring

To have other cluster health indicators monitored automatically:

Recommended threshold values for selected metrics:

Metric	Designation	Alarm	Warning
Replication delay	postgres-replication_lag	60	5
Number of healthy hosts	postgres-is_alive	<number_of_hosts> - 2	<number_of_hosts> - 1
Average query execution time	pooler-avg_query_time	—	2,000
Storage space used	disk.used_bytes	90% of the storage size	80% of the storage size

For the disk.used_bytes metric, the Alarm and Warning thresholds are only set in bytes. For example, the recommended values for a 100 GB disk are as follows:

• Alarm: 96636764160 bytes (90%)
• Warning: 85899345920 bytes (80%)

You can check the current storage size in the cluster details. For a complete list of supported metrics, see this Monitoring guide.

Cluster health and statusCluster health and status

The State of a cluster shows the health of its hosts, while the Status shows whether the cluster is started, stopped, or is at an intermediate stage.

To view the health state and status of a cluster:

1. Navigate to the folder dashboard and select Managed Service for PostgreSQL.
2. In the cluster row, hover over the indicator in the Availability column.

Cluster health statesCluster health states

State	Description	Suggested actions
ALIVE	Cluster is operating normally.	No action is required.
DEGRADED	Cluster is not running at its full capacity: the state of at least one of the hosts is other than ALIVE.	Run the diagnostics: Go to the Hosts tab and see which hosts are not working. Go to the Operations tab and make sure all operations are completed. Make sure the cluster is not under maintenance. If you cannot find the cause yourself, contact support.
DEAD	The cluster is down: none of its hosts are running.	Make a support request stating the following: Cluster ID. IDs of the last operations performed on it. Time the cluster entered the DEAD state according to the availability charts.
UNKNOWN	Cluster state is unknown.	Make a support request stating the following: Cluster ID. IDs of the last operations performed on it. Time the cluster entered the UNKNOWN state according to the availability charts.

Cluster statusesCluster statuses

Status	Description	Suggested actions
CREATING	Preparing for the first start	Wait a while and get started. The time it takes to create a cluster depends on the host class.
RUNNING	The cluster is operating normally	No action is required.
STOPPING	The cluster is stopping	After a while, the cluster status will switch to STOPPED and the cluster will be disabled. No action is required.
STOPPED	The cluster is stopped	Start the cluster to get it running again.
STARTING	Starting the cluster that was stopped earlier	After a while, the cluster status will switch to RUNNING. Wait a while and get started.
UPDATING	Updating the cluster's configuration	Once the update is complete, the cluster will get the status it had prior to the update: RUNNING or STOPPED.
ERROR	Error when performing an operation with the cluster or during a maintenance window	If the cluster remains in this status for a long time, contact support. You can see whether a cluster is available by its status.
STATUS_UNKNOWN	The cluster is unable to determine its status	If the cluster remains in this status for a long time, contact support.