How to monitor Azure Cache for Redis
Azure Cache for Redis uses Azure Monitor to provide several options for monitoring your cache instances. You can 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. These tools enable you to monitor the health of your Azure Cache for Redis instances and help you manage your caching applications.
Metrics for Azure Cache for Redis instances are collected using the Redis INFO command approximately twice per minute and automatically stored for 30 days (see Export cache metrics to configure a different retention policy) so they can be displayed in the metrics charts and evaluated by alert rules. For more information about the different INFO values used for each cache metric, see Available metrics and reporting intervals.
To view cache metrics, browse to your cache instance in the Azure portal. Azure Cache for Redis provides some built-in charts on the Overview blade and the Redis metrics blade. Each chart can be customized by adding or removing metrics and changing the reporting interval.
View pre-configured metrics charts
The Overview blade has the following pre-configured monitoring charts.
The Monitoring section in the Overview blade has Hits and Misses, Gets and Sets, Connections, and Total Commands charts.
The Usage section in the Overview blade 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 with Azure monitor
To view Redis metrics and create custom charts using Azure Monitor, click Metrics from the Resource menu, and customize your chart using the desired metrics, reporting interval, chart type, and more.
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 retain the metrics data forever, set Retention (days) to 0.
- Click 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, and 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. The Metric blade 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.
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 based off 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 is not 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 is not 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
|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 due to 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 are seeing high Redis Server Load, then you will 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 used for key/value pairs in the cache in MB 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, click Alert rules from the Resource menu.
For more information about configuring and using Alerts, see Overview of Alerts.
Activity logs provide insight into the operations that were performed on your Azure Cache for Redis instances. It was previously known as "audit logs" or "operational logs". Using activity logs, you can determine the "what, who, and when" for any write operations (PUT, POST, DELETE) taken on your Azure Cache for Redis instances.
Activity logs do not include read (GET) operations.
To view activity logs for your cache, click Activity logs from the Resource menu.
For more information about Activity logs, see Overview of the Azure Activity Log.