format

Author: dlepow

articles/redis/monitor-cache-reference.md

@@ -52,9 +52,9 @@ The following list provides details and more information about the supported Azu
 | Geo Replication Healthy | Indicates the health of the geo-replication link between caches in an Active Geo-Replication group. The metric reports one of two values:<br/><br/>0 – disconnected/unhealthy<br/>1 – healthy<br/><br/>The metric is available on Memory Optimized, Balanced, and Compute Optimized tier caches with geo-replication enabled. A value of 0 doesn't mean that data on the geo-replica is lost. It just means that the link between geo-primary and geo-secondary is unhealthy.<br/><br/>This metric might indicate a disconnected/unhealthy replication status for several reasons, including: monthly patching, host OS updates, network misconfiguration, or failed geo-replication link provisioning. The Azure Managed Redis service periodically patches caches with the latest platform features and improvements. During these updates, each cache node is taken offline, which temporarily disables the geo-replication link. If your geo-replication link is unhealthy, check to see if it was caused by a patching event on either the geo-primary or geo-secondary cache by using **Diagnose and Solve Problems** from the Resource menu in the portal. Depending on the amount of data in the cache, the downtime from patching can take anywhere from a few minutes to an hour. If the geo-replication link is unhealthy for over an hour, [file a support request](/azure/azure-portal/supportability/how-to-create-azure-support-request). |
 | Gets | The number of read requests to the cache during the specified reporting interval. This value is sourced from the `bdb_read_req` Prometheus metric, which represents the rate of all read requests on the database, and is equivalent to the sum of cache hits and misses during the reporting interval. |
 | Operations per Second | The total number of requests handled per second by all shards of the cache during the specified reporting interval. This value is sourced from the `bdb_instantaneous_ops_per_sec` Prometheus metric. |
-| Server Load | The *Server Load* metric reflects the Redis server's own assessment of overall load, and is similar to the **CPU** metric but measured at a cluster level rather than per instance. This value is derived from the `node_cpu_idle_min` Prometheus metric and inverted to reflect server busy time. If this counter reaches 100, the Redis server has hit a performance ceiling, and the CPU can't process work any faster. You can expect a large latency effect. If you're seeing sustained high Server Load, consider scaling up the cache or partitioning data across multiple caches. When *Server Load* is only moderately high, such as 50 to 80 percent, average latency usually remains low, and timeout exceptions could have other causes than high server latency.<br/><br/>Because *Server Load* is measured at the cluster level, it doesn't allow you to drill down to individual instances. We recommend using the **CPU** metric instead, as it supports splitting by Instance ID for instance-level analysis.<br/><br/>> [!CAUTION]<br/>> The *Server Load* metric can present incorrect data for Azure Managed Redis caches. Sometimes *Server Load* is represented as being over 100. We are investigating this issue. We recommend using the **CPU** metric instead.|
+| Server Load | The *Server Load* metric reflects the Redis server's own assessment of overall load, and is similar to the **CPU** metric but measured at a cluster level rather than per instance. This value is derived from the `node_cpu_idle_min` Prometheus metric and inverted to reflect server busy time. If this counter reaches 100, the Redis server has hit a performance ceiling, and the CPU can't process work any faster. You can expect a large latency effect. If you're seeing sustained high Server Load, consider scaling up the cache or partitioning data across multiple caches. When *Server Load* is only moderately high, such as 50 to 80 percent, average latency usually remains low, and timeout exceptions could have other causes than high server latency.<br/><br/>Because *Server Load* is measured at the cluster level, it doesn't allow you to drill down to individual instances. We recommend using the **CPU** metric instead, as it supports splitting by Instance ID for instance-level analysis.<br/><br/>**Caution:** The *Server Load* metric can present incorrect data for Azure Managed Redis caches. Sometimes *Server Load* is represented as being over 100. We are investigating this issue. We recommend using the **CPU** metric instead.|
 | Sets | The number of write requests to the cache during the specified reporting interval. This value is sourced from the `db_write_req` Prometheus metric, which represents the rate of all write requests on the database. |
-| Total Keys | The number of keys in the cache during the specified reporting interval. This value is sourced from the `db_no_of_keys`  Prometheus metric.<br/><br/>> [!IMPORTANT]<br/>> Because of a limitation in the underlying metrics system for caches with clustering enabled, Total Keys return the maximum number of keys of the shard that had the maximum number of keys during the reporting interval. |
+| Total Keys | The number of keys in the cache during the specified reporting interval. This value is sourced from the `db_no_of_keys`  Prometheus metric.<br/><br/>**Important:** Because of a limitation in the underlying metrics system for caches with clustering enabled, Total Keys return the maximum number of keys of the shard that had the maximum number of keys during the reporting interval. |
 | Total Operations | The total number of requests processed by the cache during the specified reporting interval. This value is sourced from the `bdb_total_req` Prometheus metric. |
 | Used Memory | The amount of cache memory in bytes used by the database during the specified reporting interval. This value is sourced from the `bdb_used_memory` Prometheus metric. On Flash Optimized tier caches, this value includes both RAM and flash memory usage. This value doesn't include fragmentation.<br/><br/> When High Availability is enabled, the Used Memory value includes the memory in both the primary and replica nodes. This can make the metric appear twice as large as expected. |
 | Used Memory Percentage | The percent of configured memory limit that is currently in use during the specified reporting interval. This value is calculated as the ratio of `bdb_used_memory` to `bdb_memory_limit` from the Redis Enterprise Prometheus metrics. This value doesn't include fragmentation. |