fix link

Author: dlepow

articles/redis/monitor-cache-reference.md

@@ -43,7 +43,7 @@ The following list provides details and more information about the supported Azu
 | Cache Latency (preview) | The average latency of requests handled by endpoints on the cache node during the specified reporting interval. This metric is measured in milliseconds and is sourced from the `node_avg_latency` Prometheus metric. This metric is only reported when there is active traffic on the cache. |
 | Cache Hits | The number of successful key lookups during the specified reporting interval. This value is sourced from the `bdb_read_hits` Prometheus metric. |
 | Cache Misses | The number of failed key lookups during the specified reporting interval. This value is sourced from the `bdb_read_misses_max` Prometheus metric. Cache misses don't necessarily mean there's an issue with the cache. For example, when using the cache-aside programming pattern, an application looks first in the cache for an item. If the item isn't there (cache miss), the item is retrieved from the database and added to the cache for next time. Cache misses are normal behavior for the cache-aside programming pattern. If the number of cache misses is higher than expected, examine the application logic that populates and reads from the cache. If items are being evicted from the cache because of memory pressure, then there might be some cache misses, but a better metric to monitor for memory pressure would be `Used Memory or Evicted Keys`. |
-| Cache Read | The rate of incoming network traffic to the cache node in bytes per second during the specified reporting interval. This value is sourced from the `node_ingress_bytes_max` Prometheus metric. If you want to set up alerts for server-side network bandwidth limits, then create it using this Cache Read counter. See [this table](azure/redis/planning-faq#how-can-i-measure-azure-managed-redis-performance-) for the observed bandwidth limits for various cache pricing tiers and sizes. |
+| Cache Read | The rate of incoming network traffic to the cache node in bytes per second during the specified reporting interval. This value is sourced from the `node_ingress_bytes_max` Prometheus metric. If you want to set up alerts for server-side network bandwidth limits, then create it using this Cache Read counter. See [this table](/azure/redis/planning-faq#how-can-i-measure-azure-managed-redis-performance-) for the observed bandwidth limits for various cache pricing tiers and sizes. |
 | Cache Write | The rate of outgoing network traffic from the cache node in bytes per second during the specified reporting interval. This value is sourced from the `node_egress_bytes_max` Prometheus metric. |
 | Connected Clients | The number of client connections to the cache during the specified reporting interval. This value is sourced from the `node_conns` Prometheus metric, which counts clients connected to endpoints on the node. Once the connection limit is reached, later attempts to connect to the cache fail. Even if there are no active client applications, there might still be a few instances of connected clients because of internal processes and connections. |
 | CPU | The CPU utilization of the Azure Managed Redis server as a percentage during the specified reporting interval. This value is derived from the `node_cpu_idle_min` Prometheus metric, which represents the lowest CPU idle time portion observed during the interval, and is inverted to reflect CPU busy time. The CPU metric includes background processes such as anti-malware that aren't strictly Redis server processes, so it can sometimes spike independently of Redis workload. We recommend using this metric over **Server Load** for monitoring, as it supports instance-level drill-down by splitting on Instance ID, providing more granularity into which node is under pressure. |