From 20070a96fb5ec66c1b6e25361a4521107dc4ca27 Mon Sep 17 00:00:00 2001 From: atovpeko Date: Mon, 30 Mar 2026 13:45:28 +0300 Subject: [PATCH 1/5] update docs --- use-timescale/metrics-logging/monitoring.md | 36 +++++++++++++-------- 1 file changed, 23 insertions(+), 13 deletions(-) diff --git a/use-timescale/metrics-logging/monitoring.md b/use-timescale/metrics-logging/monitoring.md index 54b83d2b56..1814db8df2 100644 --- a/use-timescale/metrics-logging/monitoring.md +++ b/use-timescale/metrics-logging/monitoring.md @@ -35,9 +35,10 @@ The following metrics are represented by graphs: - CPU, in mCPU - Memory, in GiB +- Queries per second, in q/sec - Storage used, in GiB -- Storage I/O, in ops/sec -- Storage bandwidth, in MiB/sec +- Read and write storage I/O, in ops/sec +- Read and write storage bandwidth, in MiB/sec When you hit the limits: @@ -109,20 +110,24 @@ Insights include `Metrics`, `Current lock contention`, and `Queries`. `Current lock contention` shows how many queries or transactions are currently waiting for locks held by other queries or transactions. -`Queries` displays the top 50 queries matching your search. This includes executions, total rows, total time, median time, P95 time, related hypertables, tables in the columnstore, and user name. +`Queries` displays the top 50 queries matching your search. This includes executions, total rows, total time, P95 time, and other metrics. ![Queries][queries] -| Column | Description | -|-------------------|-------------------------------------------------------------------------------------------------| -| `Executions` | The number of times the query ran during the selected period. | -| `Total rows` | The total number of rows scanned, inserted, or updated by the query during the selected period. | -| `Total time` | The total time of query execution. | -| `Median time` | The median (P50) time of query execution. | -| `P95 time` | The ninety-fifth percentile, or the maximum time of query execution. | -| `Hypertables` | If the query ran on a $HYPERTABLE. | -| `Columnar tables` | If the query drew results from a chunk in the $COLUMNSTORE. | -| `User name` | The user name of the user running the query. | +| Column | Description | +|-----------------------|-------------------------------------------------------------------------------------------------| +| `Executions` | How many times the query ran during the selected period. | +| `Total rows` | How many rows the query scanned, inserted, or updated during the selected period. | +| `Total time` | How long the query spent executing in total across all runs. | +| `Time (P95)` | How long the query takes in the worst typical case. Measured at the 95th percentile. | +| `CPU User (P95)` | How much CPU your query uses for its own work, such as calculations and data processing. Measured at the 95th percentile in millicores. | +| `CPU System (P95)` | How much CPU the operating system uses on behalf of your query, such as disk and network operations. Measured at the 95th percentile in millicores. | +| `Memory (P95)` | How much memory your query consumes during execution. Measured at the 95th percentile in MiB. | +| `Storage read (P95)` | How many read operations your query triggers on disk. Measured at the 95th percentile in ops/sec. | +| `Storage write (P95)` | How many write operations your query triggers on disk. Measured at the 95th percentile in ops/sec. | +| `Hypertables` | Whether the query ran on a $HYPERTABLE. | +| `Columnar tables` | Whether the query read data from a chunk in the $COLUMNSTORE. | +| `User name` | The database user who ran the query. | These metrics calculations are based on the entire period you've selected. For example, if you've selected six hours, all the metrics represent an aggregation of the previous six hours of executions. @@ -146,6 +151,11 @@ This view includes the following graphs: - `Plans and executions`: the number of query plans and executions over time. You can use this to optimize query performance, helping you assess if you can benefit from prepared statements to reduce planning overhead. - `Shared buffers hit and miss`: shared buffers play a critical role in $PG's performance by caching data in memory. A shared buffer hit occurs when the required data block is found in the shared buffer memory, while a miss indicates that $PG couldn't locate the block in memory. A miss doesn't necessarily mean a disk read, because $PG may retrieve the data from the operating system's disk pages cache. If you observe a high number of shared buffer misses, your current shared buffers setting might be insufficient. Increasing the shared buffer size can improve cache hit rates and query speed. - `Cache hit ratio`: measures how much of your query's data is read from shared buffers. A 100% value indicates that all the data required by the query was found in the shared buffer, while a 0% value means none of the necessary data blocks were in the shared buffers. This metric provides a clear understanding of how efficiently your query leverages shared buffers, helping you optimize data access and database performance. +- `CPU time (user)`: how much CPU time your query spends on its own work, such as parsing, sorting, filtering, and computing results. A spike here usually means the query is doing more computational work than expected — check for missing indexes, unnecessary joins, or large sequential scans. +- `CPU time (system)`: how much CPU time the operating system spends on behalf of your query, such as reading from disk, managing memory, and handling network I/O. High values here often point to heavy disk access or memory pressure rather than query logic itself. +- `Memory allocated`: how much memory your query consumes during execution. Watch for sudden increases, which may indicate inefficient joins, large sorts spilling to disk, or growing result sets. If memory usage consistently approaches your $SERVICE_SHORT's limits, consider optimizing the query or provisioning more resources. +- `Storage IO bytes read`: how much data your query reads from disk over time. High read volumes can indicate full table scans or queries that access more data than necessary. Adding indexes or narrowing your query's time range can help reduce reads. +- `Storage IO bytes written`: how much data your query writes to disk over time. This includes inserts, updates, and temporary files created during sorts or joins. Unexpectedly high write volumes may suggest that large intermediate results are spilling to disk. ## Jobs From e46bfcbdec5a2ba41f69b5fe692ee777d64b830e Mon Sep 17 00:00:00 2001 From: atovpeko Date: Mon, 30 Mar 2026 14:13:55 +0300 Subject: [PATCH 2/5] update docs --- use-timescale/metrics-logging/monitoring.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/use-timescale/metrics-logging/monitoring.md b/use-timescale/metrics-logging/monitoring.md index 1814db8df2..4531cc3683 100644 --- a/use-timescale/metrics-logging/monitoring.md +++ b/use-timescale/metrics-logging/monitoring.md @@ -110,7 +110,7 @@ Insights include `Metrics`, `Current lock contention`, and `Queries`. `Current lock contention` shows how many queries or transactions are currently waiting for locks held by other queries or transactions. -`Queries` displays the top 50 queries matching your search. This includes executions, total rows, total time, P95 time, and other metrics. +`Queries` displays the top 50 queries matching your search. This includes a whole range of metrics: ![Queries][queries] From 9752017378734d18783ad0ca5a24e7f2c1aed2c5 Mon Sep 17 00:00:00 2001 From: atovpeko Date: Mon, 30 Mar 2026 14:16:51 +0300 Subject: [PATCH 3/5] update docs --- use-timescale/metrics-logging/monitoring.md | 28 ++++++++++----------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/use-timescale/metrics-logging/monitoring.md b/use-timescale/metrics-logging/monitoring.md index 4531cc3683..fb2aa6ca7b 100644 --- a/use-timescale/metrics-logging/monitoring.md +++ b/use-timescale/metrics-logging/monitoring.md @@ -116,15 +116,15 @@ Insights include `Metrics`, `Current lock contention`, and `Queries`. | Column | Description | |-----------------------|-------------------------------------------------------------------------------------------------| -| `Executions` | How many times the query ran during the selected period. | -| `Total rows` | How many rows the query scanned, inserted, or updated during the selected period. | -| `Total time` | How long the query spent executing in total across all runs. | -| `Time (P95)` | How long the query takes in the worst typical case. Measured at the 95th percentile. | -| `CPU User (P95)` | How much CPU your query uses for its own work, such as calculations and data processing. Measured at the 95th percentile in millicores. | -| `CPU System (P95)` | How much CPU the operating system uses on behalf of your query, such as disk and network operations. Measured at the 95th percentile in millicores. | -| `Memory (P95)` | How much memory your query consumes during execution. Measured at the 95th percentile in MiB. | -| `Storage read (P95)` | How many read operations your query triggers on disk. Measured at the 95th percentile in ops/sec. | -| `Storage write (P95)` | How many write operations your query triggers on disk. Measured at the 95th percentile in ops/sec. | +| `Executions` | Number of times the query ran during the selected period. | +| `Total rows` | Total rows scanned, inserted, or updated by the query during the selected period. | +| `Total time` | Combined execution time across all runs of the query. | +| `Time (P95)` | Execution time in the worst typical case. 95th percentile. | +| `CPU User (P95)` | CPU spent on the query's own work — calculations, sorting, filtering. 95th percentile, in millicores. | +| `CPU System (P95)` | CPU spent by the OS for the query — disk reads, memory management, network I/O. 95th percentile, in millicores. | +| `Memory (P95)` | Memory used during query execution. 95th percentile, in MiB. | +| `Storage read (P95)` | Disk read operations caused by the query. 95th percentile, in ops/sec. | +| `Storage write (P95)` | Disk write operations caused by the query. 95th percentile, in ops/sec. | | `Hypertables` | Whether the query ran on a $HYPERTABLE. | | `Columnar tables` | Whether the query read data from a chunk in the $COLUMNSTORE. | | `User name` | The database user who ran the query. | @@ -151,11 +151,11 @@ This view includes the following graphs: - `Plans and executions`: the number of query plans and executions over time. You can use this to optimize query performance, helping you assess if you can benefit from prepared statements to reduce planning overhead. - `Shared buffers hit and miss`: shared buffers play a critical role in $PG's performance by caching data in memory. A shared buffer hit occurs when the required data block is found in the shared buffer memory, while a miss indicates that $PG couldn't locate the block in memory. A miss doesn't necessarily mean a disk read, because $PG may retrieve the data from the operating system's disk pages cache. If you observe a high number of shared buffer misses, your current shared buffers setting might be insufficient. Increasing the shared buffer size can improve cache hit rates and query speed. - `Cache hit ratio`: measures how much of your query's data is read from shared buffers. A 100% value indicates that all the data required by the query was found in the shared buffer, while a 0% value means none of the necessary data blocks were in the shared buffers. This metric provides a clear understanding of how efficiently your query leverages shared buffers, helping you optimize data access and database performance. -- `CPU time (user)`: how much CPU time your query spends on its own work, such as parsing, sorting, filtering, and computing results. A spike here usually means the query is doing more computational work than expected — check for missing indexes, unnecessary joins, or large sequential scans. -- `CPU time (system)`: how much CPU time the operating system spends on behalf of your query, such as reading from disk, managing memory, and handling network I/O. High values here often point to heavy disk access or memory pressure rather than query logic itself. -- `Memory allocated`: how much memory your query consumes during execution. Watch for sudden increases, which may indicate inefficient joins, large sorts spilling to disk, or growing result sets. If memory usage consistently approaches your $SERVICE_SHORT's limits, consider optimizing the query or provisioning more resources. -- `Storage IO bytes read`: how much data your query reads from disk over time. High read volumes can indicate full table scans or queries that access more data than necessary. Adding indexes or narrowing your query's time range can help reduce reads. -- `Storage IO bytes written`: how much data your query writes to disk over time. This includes inserts, updates, and temporary files created during sorts or joins. Unexpectedly high write volumes may suggest that large intermediate results are spilling to disk. +- `CPU time (user)`: CPU time the query spends on its own work — parsing, sorting, filtering, computing results. A spike here means the query is doing more computation than expected. Check for missing indexes, unnecessary joins, or large sequential scans. +- `CPU time (system)`: CPU time the OS spends servicing the query — disk reads, memory management, network I/O. High values point to heavy disk access or memory pressure rather than query logic. +- `Memory allocated`: memory the query uses during execution. Sudden increases often come from inefficient joins, large sorts spilling to disk, or growing result sets. If usage stays near the $SERVICE_SHORT's limits, optimize the query or provision more resources. +- `Storage IO bytes read`: data the query reads from disk over time. High read volumes point to full table scans or queries accessing more data than necessary. Adding indexes or narrowing the time range helps reduce reads. +- `Storage IO bytes written`: data the query writes to disk over time. This includes inserts, updates, and temporary files from sorts or joins. Unusually high writes often mean large intermediate results are spilling to disk. ## Jobs From 4051eef67845a37a07331f25d4ecbdb4004db5e5 Mon Sep 17 00:00:00 2001 From: atovpeko Date: Mon, 30 Mar 2026 15:25:03 +0300 Subject: [PATCH 4/5] additional updates --- integrations/find-connection-details.md | 2 +- use-timescale/security/members.md | 1 - 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/integrations/find-connection-details.md b/integrations/find-connection-details.md index fccb121443..15f8cc041a 100644 --- a/integrations/find-connection-details.md +++ b/integrations/find-connection-details.md @@ -100,7 +100,7 @@ In the `Services` page of the $MST_CONSOLE_LONG, click the service you want to c [mst-connection-details]: https://assets.timescale.com/docs/images/mst-connection-info.png [postgres-config]: https://www.postgresql.org/docs/current/runtime-config-file-locations.html [rest-api-reference]: /api/:currentVersion:/api-reference/ -[retrive-the-project-id-in-console]: https://assets.timescale.com/docs/images/tiger-on-azure/tiger-console-project-id.png +[retrive-the-project-id-in-console]: https://assets.timescale.com/docs/images/tiger-cloud-console/tiger-console-change-project.png [retrive-the-service-id-in-console-1]: https://assets.timescale.com/docs/images/tiger-cloud-console/tiger-cloud-console-client-credentials.png [retrive-the-service-id-in-console]: https://assets.timescale.com/docs/images/tiger-on-azure/tiger-console-service-id.png [service_long-connection-details]: https://assets.timescale.com/docs/images/tiger-cloud-console/tiger-service-connection-details.png diff --git a/use-timescale/security/members.md b/use-timescale/security/members.md index 308277c6f3..d8e82530d1 100644 --- a/use-timescale/security/members.md +++ b/use-timescale/security/members.md @@ -208,5 +208,4 @@ The user is deleted immediately, they can no longer access your $PROJECT_SHORT. [join-a-project]: /use-timescale/:currentVersion:/security/members/#join-a-project [pricing-plans]: /about/:currentVersion:/pricing-and-account-management/ [project-users-in-console]: https://assets.timescale.com/docs/images/tiger-cloud-console/tiger-console-project-roles-overview.png -[remove-user-in-console]: https://assets.timescale.com/docs/images/tiger-cloud-console/tiger-console-transfer-project-ownership.png [saml]: /use-timescale/:currentVersion:/security/saml/ From 9542c80c71da53bc07efa846c095ce988e3ebaba Mon Sep 17 00:00:00 2001 From: atovpeko Date: Tue, 31 Mar 2026 12:49:06 +0300 Subject: [PATCH 5/5] add a note about metrics --- use-timescale/metrics-logging/exported-metrics.md | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/use-timescale/metrics-logging/exported-metrics.md b/use-timescale/metrics-logging/exported-metrics.md index 8c5cd65144..d072798a80 100644 --- a/use-timescale/metrics-logging/exported-metrics.md +++ b/use-timescale/metrics-logging/exported-metrics.md @@ -8,11 +8,19 @@ tags: [telemetry, monitor, metrics] # Exported metrics -This page provides a list of metrics you can export with all $CLOUD_LONG exporters. +This page provides a list of metrics you can export with all $CLOUD_LONG exporters. + + + +The following limitations apply for replica metrics: +- For HA replicas, metrics are only exported for the primary and one HA replica. +- For read replica sets, metrics are exported for the primary/`standby_leader` and one read replica. + + ## $CLOUD_LONG metrics -These are the metrics exported by default by every $CLOUD_LONG exporter: +These are the metrics exported by default by every $CLOUD_LONG exporter. You can filter them by `project_id`, `service_id`, `role`, and `region`. |Metric|Description| |-|-| @@ -31,7 +39,7 @@ These are the metrics exported by default by every $CLOUD_LONG exporter: ## $PG metrics These additional metrics are collected if you tick `PostgreSQL metrics` when creating $CLOUD_LONG exporters. -All metrics have a scrape interval of 15 seconds. +All metrics have a scrape interval of 15 seconds. You can filter them by `project_id`, `service_id`, and `role`. ### Exporter metrics