Procedure consigliate per il monitoraggio di Archiviazione code di Azure
Questo articolo include una raccolta di scenari comuni di monitoraggio di Archiviazione code e fornisce linee guida sulle procedure consigliate per eseguirle.
Monitorare i conteggi dei messaggi in ogni coda
È possibile monitorare il conteggio dei messaggi per tutte le code in un account di archiviazione usando la metrica QueueMessageCount. Questa metrica viene aggiornata ogni giorno.
Se si usa PowerShell, è possibile usare un comando simile al seguente:
(Get-AzMetric -ResourceId /subscriptions/xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/contosogroup/providers/Microsoft.Storage/storageAccounts/contoso/queueServices/default -MetricName "QueueMessageCount").data.Average
Se è necessario determinare in modo dinamico se modificare i carichi di lavoro per gestire il volume dei messaggi, è possibile eseguire query sul conteggio approssimativo dei messaggi in ogni coda e quindi rispondere con l'azione appropriata. Usare l'operazione REST Get Queue Metadata o uno degli SDK di archiviazione Blob supportati per ottenere il conteggio approssimativo dei messaggi.
L'esempio seguente usa la libreria .NET v12 di Archiviazione di Azure per ottenere il conteggio approssimativo dei messaggi.
static async Task<string> RetrieveNextMessageAsync(QueueClient theQueue)
{
if (await theQueue.ExistsAsync())
{
QueueProperties properties = await theQueue.GetPropertiesAsync();
if (properties.ApproximateMessagesCount > 0)
{
QueueMessage[] retrievedMessage = await theQueue.ReceiveMessagesAsync(1);
string theMessage = retrievedMessage[0].MessageText;
await theQueue.DeleteMessageAsync(retrievedMessage[0].MessageId, retrievedMessage[0].PopReceipt);
return theMessage;
}
return null;
}
return null;
}
Prendere in considerazione anche l'uso del bus di servizio, che supporta i messaggi in base all’entità. Per altre informazioni, vedere Monitoraggio del riferimento dei dati del bus di servizio di Azure.
Controllo dell'attività dell'account
In molti casi è necessario effettuare un controllo di sicurezza e conformità delle attività degli account di archiviazione. Le operazioni sugli account di archiviazione rientrano in due categorie: Piano di controllo e Piano dati.
Un'operazione del piano di controllo è qualsiasi richiesta di Azure Resource Manager per creare un account di archiviazione o per aggiornare una proprietà di un account di archiviazione esistente. Per altre informazioni, vedere Azure Resource Manager.
Un'operazione del piano dati è un'operazione sui dati in un account di archiviazione risultante da una richiesta all'endpoint del servizio di archiviazione. Ad esempio, un'operazione del piano dati viene eseguita quando si aggiunge un messaggio alla coda. Per altre informazioni, vedere API di Archiviazione di Azure.
La sezione illustra come identificare le informazioni "when", "who", "what" e "how" ("quando", "chi", "cosa" e "come") delle operazioni del controllo e del piano dati.
Controllo sulle operazioni del piano di controllo
Le operazioni di Resource Manager vengono acquisite nel Log attività di Azure. Per visualizzare il log attività, aprire l'account di archiviazione nel portale di Azure e quindi selezionare Log attività.
Aprire qualsiasi voce di log per visualizzare JSON che descrive l'attività. Il codice JSON seguente mostra le informazioni "when", "what" e "how" ("quando", "chi", "cosa" e "come") di un'operazione del piano di controllo:
La disponibilità delle informazioni"who" ("chi") dipende dal metodo di autenticazione usato per eseguire l'operazione del piano di controllo. Se l'autorizzazione è stata eseguita da un'entità di sicurezza Microsoft Entra, l'identificatore dell'oggetto dell'entità di sicurezza verrà visualizzato anche in questo output JSON (ad esempio: "http://schemas.microsoft.com/identity/claims/objectidentifier": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx"). Poiché è possibile che non vengano sempre visualizzate altre informazioni correlate all'identità, ad esempio un indirizzo di posta elettronica o un nome, l'identificatore dell'oggetto è sempre il modo migliore per identificare in modo univoco l'entità di sicurezza.
È possibile trovare il nome descrittivo dell'entità di sicurezza prendendo il valore dell'identificatore di oggetto e cercando l'entità di sicurezza nella pagina ID di Microsoft Entra del portale di Azure. Lo screenshot seguente mostra un risultato della ricerca in Microsoft Entra ID.
Controllo delle operazioni del piano dati
Le operazioni del piano dati vengono acquisite nei log delle risorse di Azure per l'Archiviazione. È possibile configurare l'impostazione di diagnostica per esportare i log nell'area di lavoro Log Analytics per un'esperienza di query nativa.
Ecco una query di Log Analytics che recupera le informazioni "when", "who", "what" e "how" ("quando", "chi", "cosa" e "come") in un elenco di voci di log.
StorageQueueLogs
| where TimeGenerated > ago(3d)
| project TimeGenerated, AuthenticationType, RequesterObjectId, OperationName, Uri
Per la parte "when" ("quando") del controllo, il campo TimeGenerated viene visualizzato quando è stata registrata la voce di log.
Per la parte "what" ("cosa") del controllo, il campo Uri mostra che l'elemento è stato modificato o letto.
Per la parte "how" ("come") del controllo, il campo OperationName mostra quale operazione è stata eseguita.
Per la parte "who" ("chi") del controllo, AuthenticationType indica il tipo di autenticazione usato per effettuare una richiesta. Questo campo può mostrare uno qualsiasi dei tipi di autenticazione supportati da Archiviazione di Azure, tra cui l'uso di una chiave dell'account, un token di firma di accesso condiviso o l'autenticazione di Microsoft Entra.
Se una richiesta è stata autenticata tramite Microsoft Entra ID, il campo RequesterObjectId fornisce il modo più affidabile per identificare l'entità di sicurezza. È possibile trovare il nome descrittivo dell'entità di sicurezza prendendo il valore del campo RequesterObjectId e cercando l'entità di sicurezza nella pagina ID di Microsoft Entra del portale di Azure. Lo screenshot seguente mostra un risultato della ricerca in Microsoft Entra ID.
In alcuni casi nei log potrebbe essere visualizzato un nome dell'entità utente o un UPN. Ad esempio, se l'entità di sicurezza è un utente di Microsoft Entra, verrà probabilmente visualizzato l'UPN. Per altri tipi di entità di sicurezza, ad esempio identità gestite assegnate dall'utente o in determinati scenari, ad esempio l'autenticazione tra tenant di Microsoft Entra, l'UPN non verrà visualizzato nei log.
Questa query mostra tutte le operazioni di scrittura eseguite dalle entità di sicurezza OAuth.
StorageQueueLogs
| where TimeGenerated > ago(3d)
and OperationName == "PutMessage"
and AuthenticationType == "OAuth"
| project TimeGenerated, AuthenticationType, RequesterObjectId, OperationName, Uri
L'autenticazione con chiave condivisa e firma di accesso condiviso non consente di controllare le singole identità. Pertanto, se si vuole migliorare la possibilità di controllare in base all'identità, è consigliabile passare a Microsoft Entra ID e impedire l'autenticazione con chiave condivisa e firma di accesso condiviso. Per informazioni su come impedire l'autenticazione con chiave condivisa e firma di accesso condiviso, vedere Impedire l'autorizzazione con chiave condivisa per un account di archiviazione di Azure. Per iniziare a usare Microsoft Entra ID, vedere Autorizzare l'accesso ai BLOB tramite Microsoft Entra ID
Ottimizzare i costi per le query poco frequenti
È possibile esportare i log in Log Analytics per funzionalità di query native avanzate. Quando si hanno transazioni di grandi dimensioni nell'account di archiviazione, il costo dell'uso dei log con Log Analytics potrebbe essere elevato. Vedere Prezzi di Azure Log Analytics. Se si prevede di eseguire query sui log solo occasionalmente, ad esempio sui log di query per il controllo della conformità, è possibile considerare la possibilità di ridurre il costo totale esportando i log nell'account di archiviazione per poi usare una soluzione di query serverless sui dati di log, ad esempio Azure Synapse.
Con Azure Synapse è possibile creare un pool SQL serverless per eseguire query sui dati di log quando necessario. Ciò potrebbe ridurre significativamente i costi.
Esportare i log nell'account di archiviazione. Vedere Creazione di un'impostazione di diagnostica.
Creare e configurare un'area di lavoro Synapse. Vedere Avvio rapido: Creare un'area di lavoro di Synapse.
Log di query. Vedere Eseguire query sui file JSON usando il pool SQL serverless in Azure Synapse Analytics.
Ecco un esempio:
select JSON_VALUE(doc, '$.time') AS time, JSON_VALUE(doc, '$.properties.accountName') AS accountName, JSON_VALUE(doc, '$.identity.type') AS identityType, JSON_VALUE(doc, '$.identity.requester.objectId') AS requesterObjectId, JSON_VALUE(doc, '$.operationName') AS operationName, JSON_VALUE(doc, '$.callerIpAddress') AS callerIpAddress, JSON_VALUE(doc, '$.uri') AS uri doc from openrowset( bulk 'https://demo2uswest4log.blob.core.windows.net/insights-logs-storageread/resourceId=/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/mytestrp/providers/Microsoft.Storage/storageAccounts/demo2uswest/blobServices/default/y=2021/m=03/d=19/h=*/m=*/PT1H.json', format = 'csv', fieldterminator ='0x0b', fieldquote = '0x0b' ) with (doc nvarchar(max)) as rows order by JSON_VALUE(doc, '$.time') desc