Monitoring the state of PostgreSQL clusters and hosts

Data on cluster and host states are 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 tools to analyze and monitor the cluster state.

Monitoring cluster stateMonitoring cluster state

To view detailed information about the Managed Service for PostgreSQL cluster state:

1. Go to the folder page and select Managed Service for PostgreSQL.

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

3. 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:

• Age of oldest transaction/statement: Oldest transaction processing and operator execution time.
• Average transaction/statement time: Average transaction processing and operator execution time.
• CPU usage: Usage of processor cores.
• Disk read/write bytes: Disk read and write speed (bytes per second).
• Disk read/write IOPS: Disk read and write activity (ops per second).
• Disk usage by DB: Disk usage by database (bytes).
• Disk usage on primary: Disk usage on a master host (bytes).
• Inode usage by host: Number of inodes used by host.
• Inode usage on primary: Number of inodes used on a master host.
• Is Primary, [boolean]: Indicates which host is the master and for how long.
• Free space: Free disk space for each host (in bytes).
• Log errors: Number of logged errors per second.
• Memory usage: Use of RAM, in bytes. At high loads, the value of the Free parameter goes down while those of other parameters go up.
• Network Bytes: Network data transfer speed (bytes per second).
• OOM Count: Shows whether there are Out-Of-Memory Killer processes. They stop apps that use up all the memory on the machine and prevent the OS from crashing.
• Packets received/sent: Network packet transmission activity (packets per second).
• Pooler is alive, [boolean]: Connection pooler health for each host either as a master or as a replica.
• PostgreSQL Alive, [boolean]: PostgreSQL health for each host either as a master or as a replica.
• Replication lag: Replication delay.
• Session CPU usage cores: Number of utilized processor cores by session type.
• Sessions per wait event: Number of waiting sessions by wait type.
• Sessions read bytes: Amount of data read by session type (bytes).
• Sessions write bytes: Amount of data written by session type (bytes).
• Statement quantiles: Operator execution time by percentile.
• TCP connections: Number of TCP connections per second.
• Total pooler connections: Number of pooler connections, both client and server.
• Total size of temporary files: Total temporary file size (bytes).
• Total size of WAL files: Total WAL file size (bytes).
• Transaction quantiles: Transaction processing time by percentile.
• Transactions/statements per second: Number of transactions and operators per second.

Monitoring the state of hostsMonitoring the state of hosts

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

1. Go to the folder page and select Managed Service for PostgreSQL.
2. Click the cluster name and select the Hosts → Monitoring tab.
3. Select the host from the drop-down list.

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

• CPU usage: Usage of processor cores. As the load goes up, the Idle value goes down.
• Disk IOPS: Number of disk operations per second.
• Disk read/write bytes: Speed of disk operations, in bytes per second.
• Memory usage: Use of RAM, in bytes. At high loads, the value of the Free parameter goes down while those of other parameters 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 read/write 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.

Alert settings in Yandex MonitoringAlert settings in Yandex Monitoring

To have other cluster health indicators monitored automatically:

The recommended thresholds are as follows:

Metric	Parameter	Alarm	Warning
Replication delay	postgres-replication_lag	60	5
Number of healthy hosts	postgres-is_alive	<host_count>: 2	<host_count>: 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: 96,636,764,160 bytes (90%)
• Warning: 85,899,345,920 bytes (80%)

You can view the current storage size in the detailed information about the cluster. For a complete list of supported metrics, see the Monitoring documentation.

Cluster state and statusCluster state 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 a cluster's state and status:

1. Go to the folder page and select Managed Service for PostgreSQL.
2. Hover over the indicator in the Availability column in the required cluster row.

Cluster statesCluster 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 launch	Wait a while and get started. The time it takes to create a cluster depends on the host class.
RUNNING	Cluster is operating normally	No action is required.
STOPPING	Stopping cluster	After a while, the cluster status will change to STOPPED and the cluster will be disabled. No action is required.
STOPPED	Cluster stopped	Start the cluster to get it running again.
STARTING	Starting the cluster that was stopped earlier	After a while, the cluster status will change to RUNNING. Wait a while and get started.
UPDATING	Updating the cluster status	After the update is completed, the cluster status will change to RUNNING. Wait a while and get started.
ERROR	An error occurred that does not allow the cluster to continue working	Run the initial diagnostics: Analyze the cluster monitoring charts and view the operations performed. Prepare a list of IDs of problem resources. If you cannot find the cause of the error yourself, contact support.
STATUS_UNKNOWN	Cluster is unable to determine its own status	Run the initial diagnostics: Analyze the cluster monitoring charts and view the operations performed. Prepare a list of IDs of problem resources. If you cannot find the cause of the error yourself, contact support.