> For the complete documentation index, see [llms.txt](https://docs.ionos.com/cloud/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ionos.com/cloud/databases/postgresql/how-tos/v2/view-postgresql-cluster-metrics.md).
# View PostgreSQL Cluster Metrics
You can monitor the performance of your PostgreSQL v2 clusters by opening the metrics dashboard in Grafana directly from the DCD.
{% hint style="info" %}
**Prerequisites:** An active PostgreSQL v2 cluster and access to the [Grafana dashboard](/cloud/observability/monitoring-service/quick-start/access-metrics-from-platform.md). For more information, see [Create a PostgreSQL Cluster](/cloud/databases/postgresql/how-tos/v2/create-postgresql-cluster.md).
{% endhint %}
{% stepper %}
{% step %}
## Navigate to PostgreSQL clusters
1\. In the **DCD**, go to **Menu** > **Databases** > **PostgreSQL**.
A list of all PostgreSQL clusters is displayed.
2\. Select a cluster from the list by clicking on its name. Alternatively, click **Details** in the **OPTIONS** column.
{% endstep %}
{% step %}
## Open Grafana from the cluster details
1\. From the **Cluster details** page, under the **Observability** section, select [**Open in Grafana**](https://grafana.logging.de-txl.ionos.com/login).
2\. Log in to the Grafana dashboard using space.vars.ionos\_cloud Single Sign-On (SSO). For more information, see [Access Metrics from the Platform](/cloud/observability/monitoring-service/quick-start/access-metrics-from-platform.md).
{% endstep %}
{% step %}
## Configure the data source
1\. From the Grafana home page, on the left-hand menu, go to **Connections** > **Data sources**.
2\. From the **Data sources** page, select **IONOS Telemetry**.
3\. In the **Settings** tab, go to the **Authentication** section > **HTTP headers**.
4\. Select **Add header**. You must add an authorization header with a bearer token. To do so, configure the following:
* **Header:** In this field, enter **Authorization**.
* **Value:** Obtain the bearer token value from the **Token Manager** section in the DCD and prefix `Bearer` before the **Token Value** and add it here. For more information, see [Generate authentication token](/cloud/set-up-ionos-cloud/management/identity-access-management/token-manager.md).
5\. In the **Other** section, select the **HTTP method** as `GET`.
6\. Click **Save & test**, available at the end of the **Settings** page.
{% endstep %}
{% step %}
## View PostgreSQL database metrics
1\. From the Grafana home page, on the left-hand menu, go to **Explore** > **Metrics**.
2\. Select **Let's start!** to start metrics exploration and choose **IONOS CLOUD Telemetry** as the **Data source**.
3\. In the **Search metrics**, type the keywords such as `postgres` to view metrics related to PostgreSQL.
{% endstep %}
{% endstepper %}
{% hint style="success" %}
**Result:** The Grafana metrics explorer displays available PostgreSQL metrics. You can search and visualize metrics to monitor cluster health and performance. For a full list of available metrics, see [Metrics for PostgreSQL](#metrics-for-postgresql).
{% endhint %}
## Metrics for PostgreSQL
The following metrics are available to gauge the health and performance of PostgreSQL clusters.
Database health and connections
| **Metric** | **Description** |
| ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **`pg_up`** | Indicates whether PostgreSQL is reachable. A value of `1` means the instance is up; a value of `0` means it is unreachable. Alert immediately if the value is `0`. |
| **`pg_stat_activity_count`** | The number of active sessions grouped by state. States include `active`, `idle`, `idle in transaction`, and others. Monitor this metric to understand connection usage patterns. |
| **`pg_stat_database_numbackends`** | The number of active connections per database. Compare this value with `pg_settings_max_connections` and alert when usage reaches 80% of the limit. |
| **`pg_settings_max_connections`** | The configured value of the `max_connections` PostgreSQL setting. Use this together with `pg_stat_database_numbackends` to calculate connection utilisation. |
| **`pg_settings_superuser_reserved_connections`** | The configured value of `superuser_reserved_connections`. Subtract this from `pg_settings_max_connections` to determine the effective connection limit available to regular users. |
Database size
| **Metric** | **Description** |
| ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| **`pg_database_size_bytes`** | The size of each database on disk, measured in bytes. Monitor this metric to track growth and alert when approaching capacity thresholds. |
Transactions and errors
| **Metric** | **Description** |
| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **`pg_stat_database_xact_commit`** | The cumulative number of committed transactions per database. Use `rate()` in PromQL to calculate transactions per second (TPS). |
| **`pg_stat_database_xact_rollback`** | The cumulative number of rolled-back transactions per database. A high rollback rate indicates application errors or logic issues. |
| **`pg_stat_database_deadlocks`** | The cumulative number of deadlock events per database. This value should remain close to zero; any non-zero reading warrants investigation. |
| **`pg_stat_database_conflicts`** | The cumulative number of query conflicts per database. This metric is most relevant when monitoring standby instances, where conflicts arise from replication activity. |
Background maintenance and checkpoints
| **Metric** | **Description** |
| ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **`pg_stat_bgwriter_checkpoints_timed`** | The cumulative number of checkpoints triggered by the scheduled checkpoint interval. This represents a stable baseline. Compare with `pg_stat_bgwriter_checkpoints_req` to assess checkpoint pressure. |
| **`pg_stat_bgwriter_checkpoints_req`** | The cumulative number of checkpoints triggered on demand because WAL volume exceeded the configured threshold. If this value consistently exceeds `pg_stat_bgwriter_checkpoints_timed`, consider increasing `max_wal_size`. |
| **`pg_wal_archive_rate`** | The rate at which WAL segments are archived. Monitor this metric to detect archiving backlogs or failures that could affect recovery point objectives. |
Replication
| **Metric** | **Description** |
| --------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| **`pg_replication_lag`** | The replication lag on a standby instance, measured in seconds. For critical workloads, alert when this value exceeds 30 seconds. |
| **`pg_replication_slots_active`** | The number of active replication slots. Inactive slots that retain WAL segments can cause disk exhaustion if not monitored and removed. |
Vacuum and table activity
| **Metric** | **Description** |
| ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **`pg_stat_user_tables_n_dead_tup`** | The number of dead (not yet vacuumed) tuples per table. High values indicate a vacuum backlog that may degrade query performance. |
| **`pg_stat_user_tables_last_autovacuum`** | The Unix timestamp of the last autovacuum run per table. Monitor the gap between runs; a long gap indicates that autovacuum is not keeping up with table activity. |
| **`pg_stat_user_tables_n_tup_ins`** | The cumulative number of rows inserted per table. Use `rate()` to calculate insert throughput. |
| **`pg_stat_user_tables_n_tup_upd`** | The cumulative number of rows updated per table. Includes both HOT and non-HOT updates. |
| **`pg_stat_user_tables_n_tup_del`** | The cumulative number of rows deleted per table. Use `rate()` to calculate delete throughput. |
| **`pg_stat_user_tables_n_tup_hot_upd`** | The cumulative number of HOT (Heap Only Tuple) updates per table. A high ratio of HOT updates to total updates indicates an effective `fillfactor` configuration. |
Memory performance and query statistics
| **Metric** | **Description** |
| ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **`pg_statio_user_tables_heap_blks_hit`** | The cumulative number of in-memory buffer hits for table data. Use together with `pg_statio_user_tables_heap_blks_read` to compute the hit ratio. The target hit ratio is above 99%. |
| **`pg_statio_user_tables_heap_blks_read`** | The cumulative number of disk reads for table data. A high value relative to in-memory hits indicates memory misses; consider increasing `shared_buffers`. |
| **`pg_stat_statements_sum_querycount`** | The total number of query executions across all tracked statements. Requires the `pg_stat_statements` extension to be enabled in the PostgreSQL configuration. |
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.ionos.com/cloud/databases/postgresql/how-tos/v2/view-postgresql-cluster-metrics.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.