Monitor Azure Cache for Redis data using diagnostic settings
Artikkel
Diagnostic settings in Azure are used to collect resource logs. An Azure resource emits resource logs and provides rich, frequent data about the operation of that resource. These logs are captured per request and are also referred to as "data plane logs". See diagnostic settings in Azure Monitor for a recommended overview of the functionality in Azure. The content of these logs varies by resource type. In Azure Cache for Redis, two options are available to log:
Connection Logs logs connections to the cache for security and diagnostic purposes.
Scope of availability
Tier
Basic, Standard, and Premium
Enterprise and Enterprise Flash
Cache Metrics
Yes
Yes
Connection Logs
Yes
Yes
Cache Metrics
Azure Cache for Redis emits many metrics such as Server Load and Connections per Second that are useful to log. Selecting the AllMetrics option allows these and other cache metrics to be logged. You can configure how long the metrics are retained. See here for an example of exporting cache metrics to a storage account.
Connection Logs
Azure Cache for Redis uses Azure diagnostic settings to log information on client connections to your cache. Logging and analyzing this diagnostic setting helps you understand who is connecting to your caches and the timestamp of those connections. The log data could be used to identify the scope of a security breach and for security auditing purposes.
Differences Between Azure Cache for Redis Tiers
Implementation of connection logs is slightly different between tiers:
Basic, Standard, and Premium-tier caches polls client connections by IP address, including the number of connections originating from each unique IP address. These logs aren't cumulative. They represent point-in-time snapshots taken at 10-second intervals. Authentication events (successful and failed) and disconnection events aren't logged in these tiers.
Enterprise and Enterprise Flash-tier caches use the audit connection events functionality built-into Redis Enterprise. Audit connection events allow every connection, disconnection, and authentication event to be logged, including failed authentication events.
The connection logs produced look similar among the tiers, but have some differences. The two formats are shown in more detail later in the article.
Important
The connection logging in the Basic, Standard, and Premium tiers polls the current client connections in the cache. The same client IP addresses appears over and over again. Logging in the Enterprise and Enterprise Flash tiers is focused on each connection event. Logs only occur when the actual event occurred for the first time.
Prerequisites/Limitations of Connection Logging
Basic, Standard, and Premium tiers
Because connection logs in these tiers consist of point-in-time snapshots taken every 10 seconds, connections that are established and removed in-between 10-second intervals aren't logged.
Authentication events aren't logged.
All diagnostic settings may take up to 90 minutes to start flowing to your selected destination.
Enabling connection logs can cause a small performance degradation to the cache instance.
Only the Analytics Logs pricing plan is supported when streaming logs to Azure Log Analytics. For more information, see Azure Monitor pricing.
Enterprise and Enterprise Flash tiers
When you use OSS Cluster Policy, logs are emitted from each data node. When you use Enterprise Cluster Policy, only the node being used as a proxy emits logs. Both versions still cover all connections to the cache. This is just an architectural difference.
Data loss (that is, missing a connection event) is rare, but possible. Data loss is typically caused by networking issues.
Disconnection logs aren't yet fully stable and events may be missed.
Because connection logs on the Enterprise tiers are event-based, be careful of your retention policies. For instance, if retention is set to 10 days, and a connection event occurred 15 days ago, that connection might still exist, but the log for that connection isn't retained.
If using active geo-replication, logging must be configured for each cache instance in the geo-replication group individually.
All diagnostic settings may take up to 90 minutes to start flowing to your selected destination.
Enabling connection logs may cause a small performance degradation to the cache instance.
Note
It is always possible to use the INFO or CLIENT LIST commands to check who is connected to a cache instance on-demand.
Important
When selecting logs, you can chose either the specific Category or Category groups, which are predefined groupings of logs across Azure services. When you use Category groups, you can no longer configure the retention settings. If you need to determine retention duration for your connection logs, select the item in the Categories section instead.
Log Destinations
You can turn on diagnostic settings for Azure Cache for Redis instances and send resource logs to the following destinations:
Log Analytics workspace - doesn't need to be in the same region as the resource being monitored.
Event hub - diagnostic settings can't access event hub resources when virtual networks are enabled. Enable the Allow trusted Microsoft services to bypass this firewall? setting in event hubs to grant access to your event hub resources. The event hub must be in the same region as the cache.
Partner Solution - a list of potential partner logging solutions can be found here
You're charged normal data rates for storage account and event hub usage when you send diagnostic logs to either destination. You're billed under Azure Monitor not Azure Cache for Redis. When sending logs to Log Analytics, you're only charged for Log Analytics data ingestion.
Navigate to your Azure Cache for Redis account. Open the Diagnostic settings pane under the Monitoring section on the left. Then, select Add diagnostic setting.
In the Diagnostic settings pane, select ConnectedClientList from Categories.
Navigate to your Azure Cache for Redis account. Open the Diagnostic Settings - Auditing pane under the Monitoring section on the left. Then, select Add diagnostic setting.
In the Diagnostic Setting - Auditing pane, select Connection events from Categories.
Use the az monitor diagnostic-settings create command to create a diagnostic setting with the Azure CLI. For more for information on command and parameter descriptions, see Create diagnostic settings to send platform logs and metrics to different destinations. This example shows how to use the Azure CLI to stream data to four different endpoints:
Use the az monitor diagnostic-settings create command to create a diagnostic setting with the Azure CLI. For more for information on command and parameter descriptions, see Create diagnostic settings to send platform logs and metrics to different destinations. This example shows how to use the Azure CLI to stream data to four different endpoints:
These fields and properties appear in the ConnectedClientList log category. In Azure Monitor, logs are collected in the ACRConnectedClientList table under the resource provider name of MICROSOFT.CACHE.
Azure Storage field or property
Azure Monitor Logs property
Description
time
TimeGenerated
The timestamp of when the log was generated in UTC.
location
Location
The location (region) the Azure Cache for Redis instance was accessed in.
category
n/a
Available log categories: ConnectedClientList.
resourceId
_ResourceId
The Azure Cache for Redis resource for which logs are enabled.
operationName
OperationName
The Redis operation associated with the log record.
properties
n/a
The contents of this field are described in the rows that follow.
tenant
CacheName
The name of the Azure Cache for Redis instance.
roleInstance
RoleInstance
The role instance that logged the client list.
connectedClients.ip
ClientIp
The Redis client IP address.
connectedClients.privateLinkIpv6
PrivateLinkIpv6
The Redis client private link IPv6 address (if applicable).
connectedClients.count
ClientCount
The number of Redis client connections from the associated IP address.
Sample storage account log
If you send your logs to a storage account, the contents of the logs look like this.
These fields and properties appear in the ConnectionEvents log category. In Azure Monitor, logs are collected in the REDConnectionEvents table under the resource provider name of MICROSOFT.CACHE.
Azure Storage field or property
Azure Monitor Logs property
Description
time
TimeGenerated
The timestamp (UTC) when event log was captured.
location
Location
The location (region) the Azure Cache for Redis instance was accessed in.
category
n/a
Available log categories: ConnectionEvents.
resourceId
_ResourceId
The Azure Cache for Redis resource for which logs are enabled.
operationName
OperationName
The Redis operation associated with the log record.
properties
n/a
The contents of this field are described in the rows that follow.
eventEpochTime
EventEpochTime
The UNIX timestamp (number of seconds since January 1, 1970) when the event happened in UTC. The timestamp can be converted to datetime format using function unixtime_seconds_todatetime in log analytics workspace.
clientIP
ClientIP
The Redis client IP address. If using Azure storage, the IP address is IPv4 or private link IPv6 format based on cache type. If using Log Analytics, the result is always in IPv4, as a separate IPv6 field is provided.
n/a
PrivateLinkIPv6
The Redis client private link IPv6 address (only emitted if using both Private Link and log analytics).
id
ConnectionId
Unique connection ID assigned by Redis.
eventType
EventType
Type of connection event (new_conn, auth, or close_conn).
eventStatus
EventStatus
Results of an authentication request as a status code (only applicable for authentication event).
Note
If private link is used, only a IPv6 address will be logged (unless you are streaming the data to log analytics). You can convert the IPv6 address to the equivalent IPv4 address by looking at the last four bytes of data in the IPv6 address. For instance, in the private link IPv6 address "fd40:8913:31:6810:6c31:200:a01:104", the last four bytes in hexadecimal are "0a", "01", "01", and "04". (Note that leading zeros are omitted after each colon.) These correspond to "10", "1", "1", and "4" in decimal, giving us the IPv4 address "10.1.1.4".
Sample storage account log
If you send your logs to a storage account, a log for a connection event looks like this: