Share via


Procedure consigliate per il monitoraggio di Archiviazione code di Azure

Questo articolo include una raccolta di scenari di monitoraggio comuni di queue Archiviazione e fornisce linee guida sulle procedure consigliate per eseguirle.

Monitorare i conteggi dei messaggi in ogni coda

È possibile monitorare il numero di messaggi per tutte le code in un account di archiviazione usando la QueueMessageCount metrica . 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 (Ottieni metadati coda) o usare uno degli SDK di archiviazione BLOB supportati per ottenere il conteggio approssimativo dei messaggi.

Nell'esempio seguente viene usata la libreria Archiviazione di Azure .NET v12 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 di bus di servizio che supporta il messaggio per entità. Per altre informazioni, vedere Monitoraggio bus di servizio di Azure informazioni di riferimento sui dati.

Controllo dell'attività dell'account

In molti casi, è necessario controllare le attività degli account di archiviazione per la sicurezza e la conformità. 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 ARCHIVIAZIONE DI AZURE API.

La sezione illustra come identificare le informazioni "when", "who", "what" e "how" delle operazioni del controllo e del piano dati.

Operazioni del piano di controllo 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à.

Activity Log

Aprire qualsiasi voce di log per visualizzare JSON che descrive l'attività. Il codice JSON seguente mostra le informazioni "when", "what" e "how" di un'operazione del piano di controllo:

Activity Log JSON

La disponibilità delle informazioni "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 dell'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.

Search Microsoft Entra ID

Controllo delle operazioni del piano dati

Le operazioni del piano dati vengono acquisite nei log delle risorse di Azure per 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" in un elenco di voci di log.

StorageQueueLogs 
| where TimeGenerated > ago(3d) 
| project TimeGenerated, AuthenticationType, RequesterObjectId, OperationName, Uri

Per la parte "when" del controllo, il TimeGenerated campo viene visualizzato quando è stata registrata la voce di log.

Per la parte "what" del controllo, il Uri campo mostra che l'elemento è stato modificato o letto.

Per la parte "how" del controllo, il OperationName campo mostra quale operazione è stata eseguita.

Per la parte "chi" del controllo, AuthenticationType indica il tipo di autenticazione usato per effettuare una richiesta. Questo campo può visualizzare uno dei tipi di autenticazione supportati 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 RequesterObjectId campo fornisce il modo più affidabile per identificare l'entità di sicurezza. È possibile trovare il nome descrittivo dell'entità di sicurezza prendendo il valore del RequesterObjectId campo 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.

Search Microsoft Entra ID-2

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 Archiviazione di Azure. Per iniziare a usare Microsoft Entra ID, vedere Autorizzare l'accesso ai BLOB con 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 i log di query per il controllo della conformità, è possibile valutare la possibilità di ridurre il costo totale esportando i log nell'account di archiviazione e quindi usando una soluzione di query serverless sui dati di log, ad esempio Azure Synapse.

Con Azure Synapse è possibile creare un pool SQL senza server per eseguire query sui dati di log quando necessario. Ciò potrebbe ridurre significativamente i costi.

  1. Esportare i log nell'account di archiviazione. Vedere Creazione di un'impostazione di diagnostica.

  2. Creare e configurare un'area di lavoro di Synapse. Vedere Avvio rapido: Creare un'area di lavoro di Synapse.

  3. Log di query. Vedere Eseguire query su 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
    
    

Vedi anche