Monitor Azure Cache for Redis
Azure Cache for Redis uses Azure Monitor to provide several options for monitoring your cache instances. These tools enable you to monitor the health of your Azure Cache for Redis instances and help you manage your caching applications.
Use Azure Monitor to:
- view metrics
- pin metrics charts to the Startboard
- customize the date and time range of monitoring charts
- add and remove metrics from the charts
- and set alerts when certain conditions are met
Metrics for Azure Cache for Redis instances are collected using the Redis INFO command. Metrics are collected approximately two times per minute and automatically stored for 30 days so they can be displayed in the metrics charts and evaluated by alert rules.
To configure a different retention policy, see Export cache metrics.
For more information about the different INFO values used for each cache metric, see Available metrics and reporting intervals.
View cache metrics
To view cache metrics, browse to your cache instance in the Azure portal. Azure Cache for Redis provides some built-in charts on the left using Overview and Redis metrics. Each chart can be customized by adding or removing metrics and changing the reporting interval.
View pre-configured metrics charts
On the left, Overview has the following pre-configured monitoring charts.
The Monitoring section---in Overview on the left---has Hits and Misses, Gets and Sets, Connections, and Total Commands charts.
The Usage section---in Overview on the left---has Redis Server Load, Memory Usage, Network Bandwidth, and CPU Usage charts, and also displays the Pricing tier for the cache instance.
The Pricing tier displays the cache pricing tier, and can be used to scale the cache to a different pricing tier.
View metrics charts for all your caches with Azure Monitor for Azure Cache for Redis
Use Azure Monitor for Azure Cache for Redis (preview) for a view of the overall performance, failures, capacity, and operational health of all your Azure Cache for Redis resources. View metrics in a customizable, unified, and interactive experience that lets you drill down into details for individual resources. Azure Monitor for Azure Cache for Redis is based on the workbooks feature of Azure Monitor that provides rich visualizations for metrics and other data. To learn more, see the Explore Azure Monitor for Azure Cache for Redis article.
View metrics with Azure Monitor metrics explorer
For scenarios where you don't need the full flexibility of Azure Monitor for Azure Cache for Redis, you can instead view metrics and create custom charts using the Azure Monitor metrics explorer. Select Metrics from the Resource menu, and customize your chart using your preferred metrics, reporting interval, chart type, and more.
In the left navigation pane of contoso55, Metrics is an option under Monitoring and is highlighted. On Metrics, is a list of metrics. Cache hits and Cache misses are selected.
For more information on working with metrics using Azure Monitor, see Overview of metrics in Microsoft Azure.
Export cache metrics
By default, cache metrics in Azure Monitor are stored for 30 days and then deleted. To persist your cache metrics for longer than 30 days, you can designate a storage account and specify a Retention (days) policy for your cache metrics.
To configure a storage account for your cache metrics:
- In the Azure Cache for Redis page, under the Monitoring heading, select Diagnostics.
- Select + Add diagnostic setting.
- Name the settings.
- Check Archive to a storage account. You’ll be charged normal data rates for storage and transactions when you send diagnostics to a storage account.
- Select Configure to choose the storage account in which to store the cache metrics.
- Under the table heading metric, check box beside the line items you want to store, such as AllMetrics. Specify a Retention (days) policy. The maximum days retention you can specify is 365 days. However, if you want to keep the metrics data forever, set Retention (days) to 0.
- Select Save.
In addition to archiving your cache metrics to storage, you can also stream them to an Event hub or send them to Azure Monitor logs.
To access your metrics, you can view them in the Azure portal as previously described in this article. You can also access them using the Azure Monitor Metrics REST API.
If you change storage accounts, the data in the previously configured storage account remains available for download, but it is not displayed in the Azure portal.
Available metrics and reporting intervals
Cache metrics are reported using several reporting intervals, including Past hour, Today, Past week, and Custom. On the left, you find the Metric selection for each metrics chart displays the average, minimum, and maximum values for each metric in the chart, and some metrics display a total for the reporting interval.
Each metric includes two versions. One metric measures performance for the entire cache, and for caches that use clustering, a second version of the metric that includes
(Shard 0-9) in the name measures performance for a single shard in a cache. For example if a cache has four shards,
Cache Hits is the total number of hits for the entire cache, and
Cache Hits (Shard 3) is just the hits for that shard of the cache.
When you're seeing the aggregation type :
- Count” show 2, it indicates the metric received 2 data points for your time granularity (1 minute).
- “Max” shows the maximum value of a data point in the time granularity,
- “Min” shows the minimum value of a data point in the time granularity,
- “Average” shows the average value of all data points in the time granularity.
- “Sum” shows the sum of all data points in the time granularity and may be misleading depending on the specific metric. Under normal conditions, “Average” and “Max” will be very similar because only one node emits these metrics (the master node). In a scenario where the number of connected clients changes rapidly, “Max,” “Average,” and “Min” would show very different values and this is also expected behavior.
Generally, “Average” will show you a smooth chart of your desired metric and reacts well to changes in time granularity. “Max” and “Min” may hide large changes in the metric if the time granularity is large but can be used with a small time granularity to help pinpoint exact times when large changes occur in the metric.
“Count” and “Sum” may be misleading for certain metrics (connected clients included).
Hence, we suggested you to have a look at the Average metrics and not the Sum metrics.
Even when the cache is idle with no connected active client applications, you may see some cache activity, such as connected clients, memory usage, and operations being performed. This activity is normal during the operation of an Azure Cache for Redis instance.
|Cache Hits||The number of successful key lookups during the specified reporting interval. This number maps to
|Cache Latency (Preview)||The latency of the cache calculated using the internode latency of the cache. This metric is measured in microseconds, and has three dimensions:
|Cache Misses||The number of failed key lookups during the specified reporting interval. This number maps to
|Cache Read||The amount of data read from the cache in Megabytes per second (MB/s) during the specified reporting interval. This value is derived from the network interface cards that support the virtual machine that hosts the cache and isn't Redis specific. This value corresponds to the network bandwidth used by this cache. If you want to set up alerts for server-side network bandwidth limits, then create it using this
|Cache Write||The amount of data written to the cache in Megabytes per second (MB/s) during the specified reporting interval. This value is derived from the network interface cards that support the virtual machine that hosts the cache and isn't Redis specific. This value corresponds to the network bandwidth of data sent to the cache from the client.|
|Connected Clients||The number of client connections to the cache during the specified reporting interval. This number maps to
|Connections Created Per Second||The number of instantaneous connections created per second on the cache via port 6379 or 6380 (SSL). This metric can help identify whether clients are frequently disconnecting and reconnecting, which can cause higher CPU usage and Redis Server Load.|
|Connections Closed Per Second||The number of instantaneous connections closed per second on the cache via port 6379 or 6380 (SSL). This metric can help identify whether clients are frequently disconnecting and reconnecting, which can cause higher CPU usage and Redis Server Load.|
|CPU||The CPU utilization of the Azure Cache for Redis server as a percentage during the specified reporting interval. This value maps to the operating system
|Errors||Specific failures and performance issues that the cache could be experiencing during a specified reporting interval. This metric has eight dimensions representing different error types, but could have more added in the future. The error types represented now are as follows:
|Evicted Keys||The number of items evicted from the cache during the specified reporting interval because of the
|Expired Keys||The number of items expired from the cache during the specified reporting interval. This value maps to
|Gets||The number of get operations from the cache during the specified reporting interval. This value is the sum of the following values from the Redis INFO all command:
|Operations per Second||The total number of commands processed per second by the cache server during the specified reporting interval. This value maps to "instantaneous_ops_per_sec" from the Redis INFO command.|
|Redis Server Load||The percentage of cycles in which the Redis server is busy processing and not waiting idle for messages. If this counter reaches 100, it means the Redis server has hit a performance ceiling and the CPU can't process work any faster. If you're seeing high Redis Server Load, then you see timeout exceptions in the client. In this case, you should consider scaling up or partitioning your data into multiple caches.|
|Sets||The number of set operations to the cache during the specified reporting interval. This value is the sum of the following values from the Redis INFO all command:
|Total Keys||The maximum number of keys in the cache during the past reporting time period. This number maps to
|Total Operations||The total number of commands processed by the cache server during the specified reporting interval. This value maps to
|Used Memory||The amount of cache memory in MB that is used for key/value pairs in the cache during the specified reporting interval. This value maps to
|Used Memory Percentage||The % of total memory that is being used during the specified reporting interval. This value references the
|Used Memory RSS||The amount of cache memory used in MB during the specified reporting interval, including fragmentation and metadata. This value maps to
You can configure to receive alerts based on metrics and activity logs. Azure Monitor allows you to configure an alert to do the following when it triggers:
- Send an email notification
- Call a webhook
- Invoke an Azure Logic App
To configure Alert rules for your cache, select Alert rules from the Resource menu.
For more information about configuring and using Alerts, see Overview of Alerts.
Submit and view feedback for