Monitorare i dati della cache di Azure per Redis usando le impostazioni di diagnostica
Articolo
Le impostazioni di diagnostica in Azure vengono usate per raccogliere i log delle risorse. Una risorsa di Azure genera i log delle risorse e fornisce dati completi e frequenti sul funzionamento di tale risorsa. Questi log vengono acquisiti per richiesta e vengono definiti anche "log del piano dati". Per una panoramica consigliata delle funzionalità in Azure, vedere Impostazioni di diagnostica in Monitoraggio di Azure. Il contenuto di questi log varia in base al tipo di risorsa. In cache di Azure per Redis sono disponibili due opzioni per la registrazione:
Connessione ion Registra le connessioni alla cache per scopi di sicurezza e diagnostica.
Ambito della disponibilità
Livello
Basic, Standard e Premium
Enterprise ed Enterprise Flash
Metrica della cache
Sì
Sì
log di Connessione ion
Sì
Sì
Metrica della cache
cache di Azure per Redis genera molte metriche, ad esempio il carico del server e le Connessione al secondo, utili per registrare. Se si seleziona l'opzione AllMetrics , è possibile registrare queste metriche e altre metriche della cache. È possibile configurare per quanto tempo vengono mantenute le metriche. Vedere qui per un esempio di esportazione delle metriche della cache in un account di archiviazione.
log di Connessione ion
cache di Azure per Redis usa le impostazioni di diagnostica di Azure per registrare informazioni sulle connessioni client alla cache. La registrazione e l'analisi di questa impostazione di diagnostica consentono di comprendere chi si connette alle cache e il timestamp di tali connessioni. I dati di log possono essere usati per identificare l'ambito di una violazione della sicurezza e per scopi di controllo della sicurezza.
Differenze tra i livelli di cache di Azure per Redis
L'implementazione dei log di connessione è leggermente diversa tra i livelli:
Le cache di livello Basic, Standard e Premium eseguano il polling delle connessioni client in base all'indirizzo IP, incluso il numero di connessioni provenienti da ogni indirizzo IP univoco. Questi log non sono cumulativi. Rappresentano snapshot temporizzato creati a intervalli di 10 secondi. Gli eventi di autenticazione (riusciti e non riusciti) e gli eventi di disconnessione non vengono registrati in questi livelli.
Le cache di livello Enterprise ed Enterprise Flash usano la funzionalità degli eventi di connessione di controllo incorporata in Redis Enterprise. Gli eventi di connessione di controllo consentono la registrazione di ogni connessione, disconnessione e evento di autenticazione, inclusi gli eventi di autenticazione non riusciti.
I log di connessione prodotti hanno un aspetto simile tra i livelli, ma presentano alcune differenze. I due formati vengono visualizzati in modo più dettagliato più avanti nell'articolo.
Importante
La registrazione della connessione nei livelli Basic, Standard e Premium esegue il polling delle connessioni client correnti nella cache. Gli stessi indirizzi IP client appaiono più e più volte. La registrazione nei livelli Enterprise ed Enterprise Flash è incentrata su ogni evento di connessione. I log si verificano solo quando si è verificato l'evento effettivo per la prima volta.
Prerequisiti/limitazioni della registrazione di Connessione ion
Livelli Basic, Standard e Premium
Poiché i log di connessione in questi livelli sono costituiti da snapshot temporizzato creati ogni 10 secondi, le connessioni stabilite e rimosse tra intervalli di 10 secondi non vengono registrate.
Gli eventi di autenticazione non vengono registrati.
Tutte le impostazioni di diagnostica possono richiedere fino a 90 minuti per iniziare a passare alla destinazione selezionata.
L'abilitazione dei log di connessione può causare una riduzione delle prestazioni ridotta all'istanza della cache.
Solo il piano tariffario Log di Analisi è supportato durante lo streaming dei log in Azure Log Analytics. Per altre informazioni, vedere Prezzi di Monitoraggio di Azure.
Livelli Enterprise e Enterprise Flash
Quando si usano i criteri del cluster OSS, i log vengono generati da ogni nodo dati. Quando si usano Criteri cluster aziendali, solo il nodo usato come proxy genera log. Entrambe le versioni coprono comunque tutte le connessioni alla cache. Questa è solo una differenza architetturale.
La perdita di dati (ovvero manca un evento di connessione) è rara, ma possibile. La perdita di dati è in genere causata da problemi di rete.
I log di disconnessione non sono ancora completamente stabili e gli eventi potrebbero non essere visualizzati.
Poiché i log di connessione nei livelli Enterprise sono basati su eventi, prestare attenzione ai criteri di conservazione. Ad esempio, se la conservazione è impostata su 10 giorni e un evento di connessione si è verificato 15 giorni fa, tale connessione potrebbe ancora esistere, ma il log per tale connessione non viene mantenuto.
Se si usa la replica geografica attiva, la registrazione deve essere configurata singolarmente per ogni istanza della cache nel gruppo di replica geografica.
Tutte le impostazioni di diagnostica possono richiedere fino a 90 minuti per iniziare a passare alla destinazione selezionata.
L'abilitazione dei log di connessione può causare una riduzione delle prestazioni ridotta all'istanza della cache.
Nota
È sempre possibile usare i comandi INFO o CLIENT LIST per verificare chi è connesso a un'istanza della cache su richiesta.
Importante
Quando si selezionano i log, è possibile scegliere i gruppi di categorie o categoria specifici, che sono raggruppamenti predefiniti dei log nei servizi di Azure. Quando si usano gruppi di categorie, non è più possibile configurare le impostazioni di conservazione. Se è necessario determinare la durata di conservazione per i log di connessione, selezionare l'elemento nella sezione Categorie .
Destinazioni log
È possibile attivare le impostazioni di diagnostica per cache di Azure per Redis istanze e inviare i log delle risorse alle destinazioni seguenti:
Area di lavoro Log Analytics: non deve trovarsi nella stessa area della risorsa monitorata.
Hub eventi: le impostazioni di diagnostica non possono accedere alle risorse dell'hub eventi quando sono abilitate le reti virtuali. Abilitare l'impostazione Consenti servizi Microsoft attendibile di ignorare questo firewall? negli hub eventi per concedere l'accesso alle risorse dell'hub eventi. L'hub eventi deve trovarsi nella stessa area della cache.
Soluzione partner: un elenco delle potenziali soluzioni di registrazione dei partner è disponibile qui
Per altre informazioni sui requisiti di diagnostica, vedere Impostazioni di diagnostica.
Vengono addebitate le normali tariffe dei dati per l'utilizzo dell'account di archiviazione e dell'hub eventi quando si inviano i log di diagnostica a una delle due destinazioni. L'addebito viene addebitato in Monitoraggio di Azure non cache di Azure per Redis. Quando si inviano log a Log Analytics, vengono addebitati solo i costi per l'inserimento dei dati di Log Analytics.
Passare all'account cache di Azure per Redis. Aprire il riquadro Impostazioni di diagnostica nella sezione Monitoraggio a sinistra. Selezionare quindi Aggiungi impostazione di diagnostica.
Nel riquadro Impostazioni di diagnostica selezionare Connessione edClientList da Categorie.
Per altri dettagli sui dati registrati, vedere il contenuto dei log di Connessione ion.
Dopo aver selezionato Connessione edClientList, inviare i log alla destinazione preferita. Selezionare le informazioni nel riquadro di lavoro.
Passare all'account cache di Azure per Redis. Aprire il riquadro Diagnostica Impostazioni - Controllo nella sezione Monitoraggio a sinistra. Selezionare quindi Aggiungi impostazione di diagnostica.
Nel riquadro Impostazioni di diagnostica - Controllo selezionare Connessione eventi di Connessione da Categorie.
Per altri dettagli sui dati registrati, vedere il contenuto dei log di Connessione ion.
Dopo aver selezionato Connessione eventi di Connessione ion, inviare i log alla destinazione preferita. Selezionare le informazioni nel riquadro di lavoro.
Abilitare la registrazione delle connessioni usando l'API REST
Usare l'API REST di Monitoraggio di Azure per creare un'impostazione di diagnostica tramite la console interattiva. Per altre informazioni, vedere Creare o aggiornare.
Richiesta
PUT https://management.azure.com/{resourceUri}/providers/Microsoft.Insights/diagnosticSettings/{name}?api-version=2017-05-01-preview
Usare l'API REST di Monitoraggio di Azure per creare un'impostazione di diagnostica tramite la console interattiva. Per altre informazioni, vedere Creare o aggiornare.
Richiesta
PUT https://management.azure.com/{resourceUri}/providers/Microsoft.Insights/diagnosticSettings/{name}?api-version=2017-05-01-preview
Usare il az monitor diagnostic-settings create comando per creare un'impostazione di diagnostica con l'interfaccia della riga di comando di Azure. Per altre informazioni sulle descrizioni dei comandi e dei parametri, vedere Creare impostazioni di diagnostica per inviare i log e le metriche della piattaforma a destinazioni diverse. Questo esempio illustra come usare l'interfaccia della riga di comando di Azure per trasmettere i dati a quattro endpoint diversi:
Usare il az monitor diagnostic-settings create comando per creare un'impostazione di diagnostica con l'interfaccia della riga di comando di Azure. Per altre informazioni sulle descrizioni dei comandi e dei parametri, vedere Creare impostazioni di diagnostica per inviare i log e le metriche della piattaforma a destinazioni diverse. Questo esempio illustra come usare l'interfaccia della riga di comando di Azure per trasmettere i dati a quattro endpoint diversi:
Questi campi e proprietà vengono visualizzati nella ConnectedClientList categoria di log. In Monitoraggio di Azure i log vengono raccolti nella ACRConnectedClientList tabella sotto il nome del provider di risorse .MICROSOFT.CACHE
Proprietà o campo di Archiviazione di Azure
Proprietà Log di Monitoraggio di Azure
Descrizione
time
TimeGenerated
Timestamp di quando il log è stato generato in formato UTC.
location
Location
Percorso (area) in cui è stata eseguita l'accesso all'istanza di cache di Azure per Redis.
category
N/D
Categorie di log disponibili: ConnectedClientList.
resourceId
_ResourceId
Risorsa cache di Azure per Redis per cui sono abilitati i log.
operationName
OperationName
Operazione Redis associata al record di log.
properties
N/D
Il contenuto di questo campo è descritto nelle righe seguenti.
tenant
CacheName
Nome dell'istanza di cache di Azure per Redis.
roleInstance
RoleInstance
Istanza del ruolo che ha registrato l'elenco dei client.
connectedClients.ip
ClientIp
Indirizzo IP del client Redis.
connectedClients.privateLinkIpv6
PrivateLinkIpv6
Indirizzo IPv6 del collegamento privato del client Redis (se applicabile).
connectedClients.count
ClientCount
Numero di connessioni client Redis dall'indirizzo IP associato.
Log dell'account di archiviazione di esempio
Se si inviano i log a un account di archiviazione, il contenuto dei log sarà simile al seguente.
Questi campi e proprietà vengono visualizzati nella ConnectionEvents categoria di log. In Monitoraggio di Azure i log vengono raccolti nella REDConnectionEvents tabella sotto il nome del provider di risorse .MICROSOFT.CACHE
Proprietà o campo di Archiviazione di Azure
Proprietà Log di Monitoraggio di Azure
Descrizione
time
TimeGenerated
Timestamp (UTC) durante l'acquisizione del registro eventi.
location
Location
Percorso (area) in cui è stata eseguita l'accesso all'istanza di cache di Azure per Redis.
category
N/D
Categorie di log disponibili: ConnectionEvents.
resourceId
_ResourceId
Risorsa cache di Azure per Redis per cui sono abilitati i log.
operationName
OperationName
Operazione Redis associata al record di log.
properties
N/D
Il contenuto di questo campo è descritto nelle righe seguenti.
eventEpochTime
EventEpochTime
Timestamp UNIX (numero di secondi dal 1° gennaio 1970) quando si è verificato l'evento in formato UTC. Il timestamp può essere convertito in formato datetime usando la funzione unixtime_seconds_todatetime nell'area di lavoro Log Analytics.
clientIP
ClientIP
Indirizzo IP del client Redis. Se si usa l'archiviazione di Azure, l'indirizzo IP è il formato IPv4 o IPv6 del collegamento privato in base al tipo di cache. Se si usa Log Analytics, il risultato è sempre in IPv4, come viene fornito un campo IPv6 separato.
N/D
PrivateLinkIPv6
Indirizzo IPv6 del collegamento privato del client Redis (generato solo se si usano sia collegamento privato che log analytics).
id
ConnectionId
ID di connessione univoco assegnato da Redis.
eventType
EventType
Tipo di evento di connessione (new_conn, autenticazione o close_conn).
eventStatus
EventStatus
Risultati di una richiesta di autenticazione come codice di stato (applicabile solo per l'evento di autenticazione).
Nota
Se si usa un collegamento privato, verrà registrato solo un indirizzo IPv6 (a meno che non si esegua lo streaming dei dati in Log Analytics). È possibile convertire l'indirizzo IPv6 nell'indirizzo IPv4 equivalente esaminando gli ultimi quattro byte di dati nell'indirizzo IPv6. Ad esempio, nell'indirizzo IPv6 del collegamento privato "fd40:8913:31:6810:6c31:200:a01:104", gli ultimi quattro byte in esadecimale sono "0a", "01", "01" e "04". Si noti che gli zeri iniziali vengono omessi dopo ogni due punti. Questi corrispondono a "10", "1", "1" e "4" in decimale, fornendo l'indirizzo IPv4 "10.1.1.4".
Log dell'account di archiviazione di esempio
Se si inviano i log a un account di archiviazione, un log per un evento di connessione è simile al seguente:
Per un'esercitazione su come usare Azure Log Analytics, vedere Panoramica di Log Analytics in Monitoraggio di Azure. Tenere presente che potrebbero essere necessari fino a 90 minuti prima che i log vengano visualizzati in Analtyics log.
cache di Azure per Redis connessioni client all'ora entro l'intervallo di indirizzi IP specificato:
let IpRange = "10.1.1.0/24";
ACRConnectedClientList
// For particular datetime filtering, add '| where TimeGenerated between (StartTime .. EndTime)'
| where ipv4_is_in_range(ClientIp, IpRange)
| summarize ConnectionCount = sum(ClientCount) by TimeRange = bin(TimeGenerated, 1h)
Indirizzi IP client Redis univoci connessi alla cache:
ACRConnectedClientList
| summarize count() by ClientIp
cache di Azure per Redis connessioni all'ora entro l'intervallo di indirizzi IP specificato:
REDConnectionEvents
// For particular datetime filtering, add '| where EventTime between (StartTime .. EndTime)'
// For particular IP range filtering, add '| where ipv4_is_in_range(ClientIp, IpRange)'
// IP range can be defined like this 'let IpRange = "10.1.1.0/24";' at the top of query.
| extend EventTime = unixtime_seconds_todatetime(EventEpochTime)
| where EventType == "new_conn"
| summarize ConnectionCount = count() by TimeRange = bin(EventTime, 1h)
cache di Azure per Redis richieste di autenticazione all'ora entro l'intervallo di indirizzi IP specificato:
REDConnectionEvents
| extend EventTime = unixtime_seconds_todatetime(EventEpochTime)
// For particular datetime filtering, add '| where EventTime between (StartTime .. EndTime)'
// For particular IP range filtering, add '| where ipv4_is_in_range(ClientIp, IpRange)'
// IP range can be defined like this 'let IpRange = "10.1.1.0/24";' at the top of query.
| where EventType == "auth"
| summarize AuthencationRequestsCount = count() by TimeRange = bin(EventTime, 1h)
Indirizzi IP client Redis univoci connessi alla cache:
REDConnectionEvents
// https://docs.redis.com/latest/rs/security/audit-events/#status-result-codes
// EventStatus :
// 0 AUTHENTICATION_FAILED - Invalid username and/or password.
// 1 AUTHENTICATION_FAILED_TOO_LONG - Username or password are too long.
// 2 AUTHENTICATION_NOT_REQUIRED - Client tried to authenticate, but authentication isn’t necessary.
// 3 AUTHENTICATION_DIRECTORY_PENDING - Attempting to receive authentication info from the directory in async mode.
// 4 AUTHENTICATION_DIRECTORY_ERROR - Authentication attempt failed because there was a directory connection error.
// 5 AUTHENTICATION_SYNCER_IN_PROGRESS - Syncer SASL handshake. Return SASL response and wait for the next request.
// 6 AUTHENTICATION_SYNCER_FAILED - Syncer SASL handshake. Returned SASL response and closed the connection.
// 7 AUTHENTICATION_SYNCER_OK - Syncer authenticated. Returned SASL response.
// 8 AUTHENTICATION_OK - Client successfully authenticated.
| where EventType == "auth" and EventStatus == 2 or EventStatus == 8 or EventStatus == 7
| summarize count() by ClientIp
Tentativi di autenticazione non riusciti nella cache
REDConnectionEvents
// https://docs.redis.com/latest/rs/security/audit-events/#status-result-codes
// EventStatus :
// 0 AUTHENTICATION_FAILED - Invalid username and/or password.
// 1 AUTHENTICATION_FAILED_TOO_LONG - Username or password are too long.
// 2 AUTHENTICATION_NOT_REQUIRED - Client tried to authenticate, but authentication isn’t necessary.
// 3 AUTHENTICATION_DIRECTORY_PENDING - Attempting to receive authentication info from the directory in async mode.
// 4 AUTHENTICATION_DIRECTORY_ERROR - Authentication attempt failed because there was a directory connection error.
// 5 AUTHENTICATION_SYNCER_IN_PROGRESS - Syncer SASL handshake. Return SASL response and wait for the next request.
// 6 AUTHENTICATION_SYNCER_FAILED - Syncer SASL handshake. Returned SASL response and closed the connection.
// 7 AUTHENTICATION_SYNCER_OK - Syncer authenticated. Returned SASL response.
// 8 AUTHENTICATION_OK - Client successfully authenticated.
| where EventType == "auth" and EventStatus != 2 and EventStatus != 8 and EventStatus != 7
| project ClientIp, EventStatus, ConnectionId
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.