[Yandex Cloud documentation](../../index.md) > [Yandex Managed Service for PostgreSQL](../index.md) > [Step-by-step guides](index.md) > Logs and monitoring > Cluster and host status monitoring

# PostgreSQL cluster and host state monitoring

Data on the cluster and host state is available in the [management console](https://console.yandex.cloud). You can view them on the **Monitoring** tab of the cluster management page or in [Yandex Monitoring](../../monitoring/concepts/index.md).

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 info %}

The most appropriate multiple units (MB, GB, and more) are automatically used in charts.

{% endnote %}

You can [configure alerts](#monitoring-integration) 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](../../monitoring/concepts/alerting.md#notification-channel).


To identify potential issues in a cluster, [use other cluster diagnostic tools](../tutorials/performance-problems.md) alongside monitoring.


## Monitoring the cluster state {#monitoring-cluster}

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

1. Navigate to **Managed Service for PostgreSQL**.

1. Click the name of your cluster and select the **Monitoring** tab.

1. 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.

       {% note warning %}

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

       {% endnote %}
    
   * **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](../concepts/backup.md) 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 monitoring {#monitoring-hosts}

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

1. Navigate to **Managed Service for PostgreSQL**.
1. Click the name of your cluster and select the **Hosts** tab.
1. 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 Monitoring {#monitoring-integration}

{% list tabs group=instructions %}

- Management console {#console}

    1. In the [management console](https://console.yandex.cloud), select the folder with the cluster for which you want to set up alerts.
    1. Navigate to ![image](../../_assets/console-icons/display-pulse.svg) **Monitoring**.
    1. Under **Service dashboards**, select:
        * **Managed Service for PostgreSQL — Cluster Overview** to set up cluster alerts.
        * **Managed Service for PostgreSQL — Host Overview** to set up host alerts.
    1. In the relevant chart, click ![options](../../_assets/console-icons/ellipsis.svg) and select **Create alert**.
    1. If the chart displays multiple metrics, select the data query for the relevant metric and click **Continue**. Learn more about the query language in [this Yandex Monitoring guide](../../monitoring/concepts/querying.md).
    1. Set the `Alarm` and `Warning` alert thresholds.
    1. Click **Create alert**.

{% endlist %}

To have other cluster health indicators monitored automatically:

{% list tabs group=instructions %}

- Management console {#console}

    1. [Create an alert](../../monitoring/operations/alert/create-alert.md).
    1. Add a status metric.
    1. In the alert parameters, set the alert thresholds.

{% endlist %}

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](cluster-list.md#get-cluster). For a complete list of supported metrics, see [this Monitoring guide](../../monitoring/metrics-ref/managed-postgresql-ref.md).


## Cluster health and status {#cluster-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&nbsp;PostgreSQL**.
1. In the cluster row, hover over the indicator in the **Availability** column.

### Cluster health states {#cluster-health}

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:<ul><li>Go to the **Hosts** tab and see which hosts are not working.</li><li>Go to the **Operations** tab and make sure all operations are completed.</li><li>Make sure the cluster is not under maintenance.</li></ul>If you cannot find the cause yourself, [contact support](https://center.yandex.cloud/support).
**DEAD** | The cluster is down: none of its hosts are running. | [Make a support request](https://center.yandex.cloud/support) stating the following:<ul><li>Cluster ID.</li><li>IDs of the last operations performed on it.</li><li>Time the cluster entered the `DEAD` state according to the [availability charts](#monitoring-cluster).</li></ul>
**UNKNOWN** | Cluster state is unknown. | [Make a support request](https://center.yandex.cloud/support) stating the following:<ul><li>Cluster ID.</li><li>IDs of the last operations performed on it.</li><li>Time the cluster entered the `UNKNOWN` state according to the [availability charts](#monitoring-cluster).</li></ul>

### Cluster statuses {#cluster-status}

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](https://center.yandex.cloud/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](https://center.yandex.cloud/support).