tech review comments

Author: dlepow

articles/redis/monitor-cache-reference.md

@@ -16,9 +16,6 @@ appliesto:
 
 [!INCLUDE [horz-monitor-ref-intro](~/reusable-content/ce-skilling/azure/includes/azure-monitor/horizontals/horz-monitor-ref-intro.md)]
 
-<!-- Can we clone the following article for AMR too? -->
-See [Monitor Azure Cache for Redis](monitor-cache.md) for details on the data you can collect for Azure Managed Redis and how to use it.
-
 [!INCLUDE [horz-monitor-ref-metrics-intro](~/reusable-content/ce-skilling/azure/includes/azure-monitor/horizontals/horz-monitor-ref-metrics-intro.md)]
 
 For more details and information about the supported metrics for Microsoft.Cache/redisEnterprise, see the following section.
@@ -53,8 +50,8 @@ The following list provides details and more information about the supported Azu
 | 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:** 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:** 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. |
+| Sets | The number of write requests to the cache during the specified reporting interval. This value is sourced from the `bdb_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 `bdb_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. |