This alert aims to ensure the optimal performance and stability of Azure Cache for Redis by monitoring memory utilization levels. The alert is activated when memory utilization exceeds 85% over the last 10 minutes. High memory utilization may indicate that the cache is nearing capacity, potentially leading to increased key evictions, degraded performance, or service interruptions. Monitoring memory usage helps maintain cache efficiency and prevents resource exhaustion. Customization Guidance: Threshold: The default threshold is set at 85% utilization. Adjust this threshold based on the criticality of your application and the impact of potential key evictions. For applications with high caching demands, a lower threshold (e.g., 75%) may be more appropriate. Monitoring Period: The standard monitoring period is 10 minutes, providing a balanced view of memory trends. Reduce the period for real-time monitoring in dynamic workloads or extend it for more stable applications to observe longer-term patterns. Cache Configuration: Configure the alert for specific Redis instances or shards if your workloads have varying memory requirements or prioritization needs. Notification Frequency: Set notification frequency to balance between timely insights and manageable alert noise. High-priority applications may require more frequent notifications. Action: Upon triggering this alert, investigate the causes of high memory utilization. Review the size of the cache instance, data models, and eviction policies. Optimize key storage by adjusting expiration policies, removing unnecessary data, or compressing stored objects. If needed, scale up to a larger cache instance or distribute the load across additional nodes to ensure continued performance and stability.

This alert aims to ensure the consistent performance and reliability of Azure Cache for Redis by monitoring CPU utilization levels. The alert is activated when CPU utilization exceeds 85% over the last 10 minutes. High CPU utilization may indicate that the Redis instance is under significant load due to increased traffic, inefficient queries, or insufficient instance sizing. Persistent high CPU usage can lead to degraded performance, increased latency, or even service disruptions. Customization Guidance: Threshold: The default threshold is set at 80% utilization. Adjust this threshold based on the performance characteristics and criticality of your application. For workloads requiring low-latency responses, a more conservative threshold (e.g., 70%) might be appropriate. Monitoring Period: The standard monitoring period is 10 minutes to balance timely detection and reducing noise from short-term spikes. Consider reducing the period for latency-sensitive applications or increasing it for steady workloads to analyze broader trends. Cache Configuration: Customize this alert to monitor specific Redis instances or shards, especially if certain nodes are expected to handle higher loads due to workload partitioning. Notification Frequency: Configure notifications to avoid alert fatigue while ensuring timely responses to critical situations. For high-priority workloads, more frequent alerts may be necessary. Action: Upon triggering this alert, investigate the factors contributing to high CPU usage. Analyze query patterns, command execution times, and traffic spikes. If needed, optimize Redis commands, add read replicas, or scale up to a larger instance tier. Monitor for any application-level inefficiencies that may be putting undue stress on the cache and adjust accordingly to maintain stable performance.

This alert aims to ensure efficient cache usage and data lifecycle management in Azure Cache for Redis by monitoring the number of expired keys. The alert is activated when the number of expired keys exceeds 100 within the last 10 minutes. Expired keys indicate that cached items have exceeded their time-to-live (TTL) and are automatically removed from the cache. While some level of key expiration is expected, a high rate of expirations could signify inefficiencies in TTL settings or rapid data churn, potentially affecting cache performance and data availability. Customization Guidance: Threshold: The default threshold is set at 100 expirations in 10 minutes. Adjust this threshold based on the application's caching strategy and acceptable data expiration rates. Lower the threshold for applications requiring longer data retention in the cache. Monitoring Period: The standard monitoring period is 10 minutes to capture meaningful trends in expirations. Shorten the period for real-time monitoring in dynamic workloads or extend it for analyzing long-term patterns. Cache Configuration: Customize the alert for specific Redis instances or shards with distinct TTL policies or application priorities. Notification Frequency: Configure notifications to provide actionable insights without overwhelming operational teams. High-priority applications may warrant more frequent notifications. Action: Upon triggering this alert, review the cache TTL settings and analyze whether they align with application requirements. Investigate sudden changes in traffic or data access patterns that might contribute to rapid expirations. If necessary, adjust TTL policies, increase cache capacity, or optimize caching logic to reduce unnecessary expirations and enhance data availability for critical workloads.

This alert aims to ensure the optimal functioning and capacity management of Azure Cache for Redis by monitoring the number of evicted keys. The alert is activated when the number of evicted keys exceeds 100 within the last 10 minutes. Key evictions occur when the cache runs out of memory and needs to free up space for new data. A high eviction rate can indicate insufficient cache capacity or inefficient memory management, leading to potential data loss and degraded application performance. Customization Guidance: Threshold: The default threshold is set at 100 evictions in 10 minutes. Adjust this threshold based on your application's sensitivity to data eviction. For applications with critical caching needs, a lower threshold may be appropriate. Monitoring Period: The standard monitoring period is 10 minutes to provide a timely view of eviction trends. Reduce this period for high-traffic applications requiring immediate insights or extend it for workloads with steady-state usage patterns. Cache Configuration: Focus the alert on specific Redis instances or shards if your application has varying memory requirements or priorities across caches. Notification Frequency: Balance notification settings to avoid alert fatigue while ensuring prompt action for critical scenarios. Action: Upon triggering this alert, investigate the cause of the increased eviction rate. Check the cache memory utilization, eviction policies, and the size of the cache instance. Consider resizing the cache, optimizing the data model, or adjusting eviction policies to align with your workload requirements. Monitor for changes in traffic patterns or spikes that may require scaling or reconfiguring the cache to prevent data loss and ensure consistent performance.

This alert aims to ensure optimal performance and cost-efficiency of Azure Cache for Redis by monitoring the cache hit percentage. The alert is activated when the cache hit percentage drops below 80% over the last 10 minutes. Cache hit percentage is a critical indicator of how effectively the cache is being utilized. A lower percentage indicates that more requests are being served from the backend data source rather than the cache, potentially leading to higher latency and increased backend load. Maintaining a high cache hit percentage ensures faster response times and reduces stress on the underlying data store. Customization Guidance: Threshold: The default threshold is set at 80%. Adjust this threshold based on the criticality of your application and the acceptable trade-off between cache performance and backend dependency. For applications requiring near-instantaneous data retrieval, a more stringent threshold (e.g., 90%) might be appropriate. Monitoring Period: The standard monitoring period is 15 minutes, providing a balanced view of cache performance trends. Consider reducing the monitoring window for high-frequency, latency-sensitive applications or extending it for workloads with more stable access patterns. Cache Usage Patterns: Customize the alert to focus on specific instances or shards if your workload exhibits varying access patterns or priority levels across caches. Notification Frequency: Configure notifications to balance between timely insights and manageable noise. High-priority applications might warrant more frequent alerts. Action: Upon triggering this alert, investigate the underlying causes of the reduced cache hit percentage. Review recent changes to cache size, eviction policies, or data access patterns. Monitor backend performance for signs of increased load and address any bottlenecks. If necessary, scale the cache instance or adjust caching strategies to optimize performance.