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.
Note
The most appropriate multiple units (MB, GB, and more) are automatically used in charts.
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 state
To view detailed information about the Managed Service for PostgreSQL cluster state:
-
Go to the folder page and select Managed Service for PostgreSQL.
-
Click the cluster name and open the Monitoring tab.
-
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 hosts
To view detailed information about the state of individual Managed Service for PostgreSQL hosts:
- Go to the folder page and select Managed Service for PostgreSQL.
- Click the cluster name and select the Hosts → Monitoring tab.
- 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 Monitoring
- In the management console
, select the folder with the cluster you want to configure alerts for. - In the list of services, select
Monitoring. - Under Service dashboards, select:
- Managed Service for PostgreSQL — Cluster Overview to configure cluster alerts.
- Managed Service for PostgreSQL — Host Overview to configure host alerts.
- In the chart you need, click
and select Create alert. - If the chart shows multiple metrics, select a data query to generate a metric and click Continue. For more information about the query language, see the Yandex Monitoring documentation.
- Set the
Alarm
andWarning
threshold values to trigger the alert. - Click Create alert.
To have other cluster health indicators monitored automatically:
- Create an alert.
- Add a status metric.
- In the alert parameters, set up your alert thresholds.
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 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:
- Go to the folder page and select Managed Service for PostgreSQL.
- Hover over the indicator in the Availability column in the required cluster row.
Cluster 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:
|
DEAD | Cluster is out of order: all of its hosts are down. | Prepare an application to support
|
UNKNOWN | Cluster state is unknown. | Prepare an application to support
|
Cluster 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 | After a while, the cluster's status will change to STOPPED and it will be disabled. No action is required. |
STOPPED | Stopped | For instructions on how to restart it, see Stopping and restarting a cluster. |
STARTING | Starting the cluster that was stopped earlier | After a while, the cluster's status will change to RUNNING . Wait a while and get started. |
UPDATING | Updating the cluster status | After the update is completed, the cluster's 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:
|
STATUS_UNKNOWN | Cluster is unable to determine its own status | Run the initial diagnostics:
|