CLOUD-4725: update the Insights page for the redesigned tab

llms-full.txt

@@ -83248,25 +83248,25 @@ The **Insights** tab on the database page of the [Upstash Console](https://conso
   Insights is a [Prod Pack](/docs/redis/overall/enterprise#prod-pack-features) feature, also included in Enterprise plans. Databases without Prod Pack see the tab with sample data, so you can explore it before you enable Prod Pack. Insights is not available for databases created through Fly.io, Heroku or DigitalOcean.
 </Note>
 
-Every view except Keyspace has a period picker in its top-right corner. You can look at the past hour, 3 hours, 12 hours, day, 3 days, week or month.
+Every view except Keyspace has a period picker in its top-right corner. You can look at the past hour, 3 hours, 12 hours, day, 3 days, week or month. The period you pick stays the same when you switch views.
 
 ## Traffic
 
 ### Request routing
 
-Upstash serves requests from the region closest to the client. This section shows where each request entered and which region of your database answered it.
+Requests enter Upstash at the region closest to the client, whether or not your database has a replica there. This section shows where each request entered and which region of your database answered it.
 
   <img alt="Request routing in the Traffic view of the Insights tab" width="100%" />
 
-* **Requests**: total requests in the period, how many were served in the region where they entered, how many were served in another region, and how many failed.
-* **Routes on the map**: each route from an entry region to the database region that served it. Dashed arrows are cross-region requests.
-* **All routes**: each route with its request count, share of requests, active and total connections, ingress and egress traffic, and errors.
+* **Requests**, **Same region**, **Cross-region** and **Errors**: total requests in the period, the share served in the region where they entered, the share served in another region, and the number of errors.
+* **Routes on the map**: the regions where requests entered and the regions that served them, with the primary, the replicas and entry-only regions marked. Each cross-region route is drawn as a dashed arrow.
+* **All routes**: each route with its request count, share of requests, active connections (open now), total connections (opened in the period), ingress and egress traffic, and errors. Routes without TCP connections show as REST only.
 
 Cross-region requests are expected. Writes always go to the primary region, and reads go to the nearest replica. If many reads cross regions, adding a [read region](/docs/redis/features/globaldatabase) close to those clients reduces their latency.
 
 ### Where clients connect from
 
-The IP ranges your requests came from, busiest first, with the cloud and region each range belongs to. Ranges are matched against the IP ranges that AWS, Google Cloud and Cloudflare publish. Serverless platforms show up as the cloud they run on, for example Vercel functions as AWS.
+The IP ranges your requests came from, busiest first, with the cloud each range belongs to, the entry region its requests used, and its share of the sampled requests. Hover a source to see its cloud region, when the range has one. Ranges are matched against the IP ranges that AWS, Google Cloud and Cloudflare publish. Serverless platforms show up as the cloud they run on, for example Vercel functions as AWS. Other addresses show up as Internet.
 
   <img alt="The IP ranges clients connect from" width="100%" />
 
@@ -83280,7 +83280,7 @@ The SDKs, platforms and runtimes your clients use, from the telemetry headers th
 
 ## Performance
 
-Charts of throughput, bandwidth, disk size and latency. Pick a replica in the top-left corner to see a single replica instead of all of them. The Simple service latency chart has its own picker for the p50, p90 and p99 percentiles.
+Charts of throughput, bandwidth, disk size, latency, expired entries and replication lag, with a line per region and, when there are several, their average. Pick a replica next to the period picker to see a single replica instead of all of them. The Simple service latency chart has its own picker for the p50, p90 and p99 percentiles. The other latency charts show p99, and Replication latency shows p99.9.
 
   <img alt="Throughput and bandwidth charts in the Performance view" width="100%" />
 
@@ -83305,8 +83305,8 @@ How close the database is to the limits of its plan, and the requests a limit re
 
   <img alt="Usage against plan limits and command rejections" width="100%" />
 
-* **Storage**, **Connections** and **Peak commands / sec**: current usage against the limit of the plan.
-* **Command rejections**: requests refused or delayed because of a limit, such as oversize requests, oversize keys, throttled writes, requests that could not reach any replica, and authentication failures. Each row shows when the rejections happened, how many there were, and when the last one was.
+* **Storage**, **Connections** and **Peak commands / sec**: the current storage and open connections, and the highest commands per second in the period, each against the limit of the plan when it has one.
+* **Command rejections**: requests refused or delayed because of a limit, such as oversize requests, oversize keys, throttled writes, requests that could not reach any replica, and authentication failures. Each row shows when in the period the rejections happened, how many there were, and when the last one was.
 
 If you keep running into a limit, see [upgrading your database](/docs/redis/howto/upgrade-database).
 
@@ -83316,18 +83316,20 @@ Script counters, Lua latency, and the scripts that run most often.
 
   <img alt="Lua script counters, latency and the most executed scripts" width="100%" />
 
-The **Scripts** table lists the ten most executed scripts of the day, with their executions, the commands they ran, failures, and their average and maximum duration and memory. It counts from the daily UTC reset, whatever period is selected. Failures include timeouts and memory limit hits.
+* **Scripts loaded**, **Executions**, **Failures** and **Lua p99 now**: the scripts loaded on the database, script executions and failures in the period, and the latest p99 Lua latency, next to the script timeout when the plan sets one.
+* **Lua latency**: p99 and p50 time spent executing scripts.
+* **Scripts**: the ten most executed scripts of the day, with their executions, the commands they ran, failures, and their average and maximum duration and memory. Click a column header to sort by it. The table counts from the daily UTC reset, whatever period is selected. Failures include timeouts and memory limit hits.
 
 ## Keyspace
 
-An analysis of what your keys hold, made from an offline scan of the latest daily backup. It does not run any command on your database.
+An analysis of what your keys hold, made from an offline scan of the latest analyzed backup. The date of that backup is shown where the other views have their period picker. It does not run any command on your database.
 
   <img alt="Keyspace summary, key types and biggest keys" width="100%" />
 
-* **Summary**: number of keys and elements, logical size, keys without a TTL, and keys that had already expired.
-* **Key types**: for each Redis data type, the number of keys, their total size, key size and element count percentiles, and the largest key.
-* **Biggest keys**: the ten largest keys, with their type, element count and remaining TTL.
-* **Expiration profile**: keys grouped by remaining TTL.
+* **Summary**: number of keys and elements, logical size, persistent keys (keys without a TTL), and keys that had already expired.
+* **Key types**: for each Redis data type that has keys, the number of keys, their total size, their share of the logical size, the median key size, and the size of the largest key. Click a type to see the p50, p90, p99 and max of its key sizes and, for collections, of the number of elements per key.
+* **Biggest keys**: the ten largest keys, with their type, size, element count and remaining TTL. Pick a type to see the largest keys of that type.
+* **Expiration profile**: keys grouped by remaining TTL range, with the number of keys, their share of the keys that have a TTL, and their size. The last row is the total of every key with a TTL.
 
 The keyspace is analyzed after every daily backup, so [daily backups](/docs/redis/features/backup) must be turned on. The analysis is not available for HIPAA-compliant databases.
 
@@ -85184,7 +85186,7 @@ commands introduced in Redis 7.
 <Update label="July 2024">
 * Added REST API support for [`MONITOR`](/docs/redis/commands/server/monitor) and [`SUBSCRIBE`](/docs/redis/commands/pub-sub/subscribe)
 commands using [SSE](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events).
-See [Monitor](../features/restapi#monitor-command) and [Subscribe](../features/restapi#subscribe-and-publish-commands) docs.
+See [Monitor](../features/restapi#monitor-command) and [Subscribe](../features/restapi#subscribe-&-publish-commands) docs.
 * Added [`JSON.MSET`](/docs/redis/commands/json/json-mset) and [`JSON.MERGE`](/docs/redis/commands/json/json-merge) commands.
 * Introduced the `IP Allowlist` feature for enhanced security on newly created databases. By default, all IP addresses will be allowed.
 However, access can be restricted by specifying permitted IP addresses or CIDR ranges.

redis/howto/insights.mdx

@@ -9,27 +9,27 @@ The **Insights** tab on the database page of the [Upstash Console](https://conso
   Insights is a [Prod Pack](/redis/overall/enterprise#prod-pack-features) feature, also included in Enterprise plans. Databases without Prod Pack see the tab with sample data, so you can explore it before you enable Prod Pack. Insights is not available for databases created through Fly.io, Heroku or DigitalOcean.
 </Note>
 
-Every view except Keyspace has a period picker in its top-right corner. You can look at the past hour, 3 hours, 12 hours, day, 3 days, week or month.
+Every view except Keyspace has a period picker in its top-right corner. You can look at the past hour, 3 hours, 12 hours, day, 3 days, week or month. The period you pick stays the same when you switch views.
 
 ## Traffic
 
 ### Request routing
 
-Upstash serves requests from the region closest to the client. This section shows where each request entered and which region of your database answered it.
+Requests enter Upstash at the region closest to the client, whether or not your database has a replica there. This section shows where each request entered and which region of your database answered it.
 
 <Frame>
   <img src="/img/insights/overview.png" alt="Request routing in the Traffic view of the Insights tab" width="100%" />
 </Frame>
 
-- **Requests**: total requests in the period, how many were served in the region where they entered, how many were served in another region, and how many failed.
-- **Routes on the map**: each route from an entry region to the database region that served it. Dashed arrows are cross-region requests.
-- **All routes**: each route with its request count, share of requests, active and total connections, ingress and egress traffic, and errors.
+- **Requests**, **Same region**, **Cross-region** and **Errors**: total requests in the period, the share served in the region where they entered, the share served in another region, and the number of errors.
+- **Routes on the map**: the regions where requests entered and the regions that served them, with the primary, the replicas and entry-only regions marked. Each cross-region route is drawn as a dashed arrow.
+- **All routes**: each route with its request count, share of requests, active connections (open now), total connections (opened in the period), ingress and egress traffic, and errors. Routes without TCP connections show as REST only.
 
 Cross-region requests are expected. Writes always go to the primary region, and reads go to the nearest replica. If many reads cross regions, adding a [read region](/redis/features/globaldatabase) close to those clients reduces their latency.
 
 ### Where clients connect from
 
-The IP ranges your requests came from, busiest first, with the cloud and region each range belongs to. Ranges are matched against the IP ranges that AWS, Google Cloud and Cloudflare publish. Serverless platforms show up as the cloud they run on, for example Vercel functions as AWS.
+The IP ranges your requests came from, busiest first, with the cloud each range belongs to, the entry region its requests used, and its share of the sampled requests. Hover a source to see its cloud region, when the range has one. Ranges are matched against the IP ranges that AWS, Google Cloud and Cloudflare publish. Serverless platforms show up as the cloud they run on, for example Vercel functions as AWS. Other addresses show up as Internet.
 
 <Frame>
   <img src="/img/insights/traffic-clients.png" alt="The IP ranges clients connect from" width="100%" />
@@ -47,7 +47,7 @@ The SDKs, platforms and runtimes your clients use, from the telemetry headers th
 
 ## Performance
 
-Charts of throughput, bandwidth, disk size and latency. Pick a replica in the top-left corner to see a single replica instead of all of them. The Simple service latency chart has its own picker for the p50, p90 and p99 percentiles.
+Charts of throughput, bandwidth, disk size, latency, expired entries and replication lag, with a line per region and, when there are several, their average. Pick a replica next to the period picker to see a single replica instead of all of them. The Simple service latency chart has its own picker for the p50, p90 and p99 percentiles. The other latency charts show p99, and Replication latency shows p99.9.
 
 <Frame>
   <img src="/img/insights/performance.png" alt="Throughput and bandwidth charts in the Performance view" width="100%" />
@@ -76,8 +76,8 @@ How close the database is to the limits of its plan, and the requests a limit re
   <img src="/img/insights/limits.png" alt="Usage against plan limits and command rejections" width="100%" />
 </Frame>
 
-- **Storage**, **Connections** and **Peak commands / sec**: current usage against the limit of the plan.
-- **Command rejections**: requests refused or delayed because of a limit, such as oversize requests, oversize keys, throttled writes, requests that could not reach any replica, and authentication failures. Each row shows when the rejections happened, how many there were, and when the last one was.
+- **Storage**, **Connections** and **Peak commands / sec**: the current storage and open connections, and the highest commands per second in the period, each against the limit of the plan when it has one.
+- **Command rejections**: requests refused or delayed because of a limit, such as oversize requests, oversize keys, throttled writes, requests that could not reach any replica, and authentication failures. Each row shows when in the period the rejections happened, how many there were, and when the last one was.
 
 If you keep running into a limit, see [upgrading your database](/redis/howto/upgrade-database).
 
@@ -89,19 +89,21 @@ Script counters, Lua latency, and the scripts that run most often.
   <img src="/img/insights/lua.png" alt="Lua script counters, latency and the most executed scripts" width="100%" />
 </Frame>
 
-The **Scripts** table lists the ten most executed scripts of the day, with their executions, the commands they ran, failures, and their average and maximum duration and memory. It counts from the daily UTC reset, whatever period is selected. Failures include timeouts and memory limit hits.
+- **Scripts loaded**, **Executions**, **Failures** and **Lua p99 now**: the scripts loaded on the database, script executions and failures in the period, and the latest p99 Lua latency, next to the script timeout when the plan sets one.
+- **Lua latency**: p99 and p50 time spent executing scripts.
+- **Scripts**: the ten most executed scripts of the day, with their executions, the commands they ran, failures, and their average and maximum duration and memory. Click a column header to sort by it. The table counts from the daily UTC reset, whatever period is selected. Failures include timeouts and memory limit hits.
 
 ## Keyspace
 
-An analysis of what your keys hold, made from an offline scan of the latest daily backup. It does not run any command on your database.
+An analysis of what your keys hold, made from an offline scan of the latest analyzed backup. The date of that backup is shown where the other views have their period picker. It does not run any command on your database.
 
 <Frame>
   <img src="/img/insights/keyspace.png" alt="Keyspace summary, key types and biggest keys" width="100%" />
 </Frame>
 
-- **Summary**: number of keys and elements, logical size, keys without a TTL, and keys that had already expired.
-- **Key types**: for each Redis data type, the number of keys, their total size, key size and element count percentiles, and the largest key.
-- **Biggest keys**: the ten largest keys, with their type, element count and remaining TTL.
-- **Expiration profile**: keys grouped by remaining TTL.
+- **Summary**: number of keys and elements, logical size, persistent keys (keys without a TTL), and keys that had already expired.
+- **Key types**: for each Redis data type that has keys, the number of keys, their total size, their share of the logical size, the median key size, and the size of the largest key. Click a type to see the p50, p90, p99 and max of its key sizes and, for collections, of the number of elements per key.
+- **Biggest keys**: the ten largest keys, with their type, size, element count and remaining TTL. Pick a type to see the largest keys of that type.
+- **Expiration profile**: keys grouped by remaining TTL range, with the number of keys, their share of the keys that have a TTL, and their size. The last row is the total of every key with a TTL.
 
 The keyspace is analyzed after every daily backup, so [daily backups](/redis/features/backup) must be turned on. The analysis is not available for HIPAA-compliant databases.

redis/overall/changelog.mdx

@@ -72,7 +72,7 @@ commands introduced in Redis 7.
 <Update label="July 2024">
 - Added REST API support for [`MONITOR`](/redis/commands/server/monitor) and [`SUBSCRIBE`](/redis/commands/pub-sub/subscribe)
 commands using [SSE](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events). 
-See [Monitor](../features/restapi#monitor-command) and [Subscribe](../features/restapi#subscribe-and-publish-commands) docs.
+See [Monitor](../features/restapi#monitor-command) and [Subscribe](../features/restapi#subscribe-&-publish-commands) docs.
 - Added [`JSON.MSET`](/redis/commands/json/json-mset) and [`JSON.MERGE`](/redis/commands/json/json-merge) commands.
 - Introduced the `IP Allowlist` feature for enhanced security on newly created databases. By default, all IP addresses will be allowed. 
 However, access can be restricted by specifying permitted IP addresses or CIDR ranges.