Aanbevolen procedures voor het bewaken van Azure Queue Storage
In dit artikel vindt u een verzameling veelvoorkomende scenario's voor Queue Storage-bewaking en krijgt u richtlijnen voor aanbevolen procedures om deze te bereiken.
Aantal berichten in elke wachtrij bewaken
U kunt het aantal berichten voor alle wachtrijen in een opslagaccount bewaken met behulp van de QueueMessageCount metrische gegevens. Deze metrische waarde wordt dagelijks vernieuwd.
Als u PowerShell gebruikt, kunt u een opdracht gebruiken die vergelijkbaar is met de volgende:
(Get-AzMetric -ResourceId /subscriptions/xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/contosogroup/providers/Microsoft.Storage/storageAccounts/contoso/queueServices/default -MetricName "QueueMessageCount").data.Average
Als u dynamisch wilt bepalen of werkbelastingen moeten worden aangepast om het berichtvolume te verwerken, kunt u een query uitvoeren op het aantal berichten in elke wachtrij en vervolgens reageren met de juiste actie. Gebruik de REST-bewerking Wachtrijmetagegevens ophalen of gebruik een van de ondersteunde Blob Storage-SDK's om het geschatte aantal berichten op te halen.
In het volgende voorbeeld wordt de Azure Storage .NET v12-bibliotheek gebruikt om het geschatte aantal berichten op te halen.
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;
}
Overweeg ook Service Bus te gebruiken die berichten per entiteit ondersteunt. Zie De naslaginformatie over Azure Service Bus-gegevens bewaken voor meer informatie.
Accountactiviteit controleren
In veel gevallen moet u de activiteiten van uw opslagaccounts controleren op beveiliging en naleving. Bewerkingen voor opslagaccounts vallen in twee categorieën: Besturingsvlak en Gegevensvlak.
Een besturingsvlakbewerking is een Azure Resource Manager-aanvraag voor het maken van een opslagaccount of het bijwerken van een eigenschap van een bestaand opslagaccount. Zie Azure Resource Manager voor meer informatie.
Een gegevensvlakbewerking is een bewerking op de gegevens in een opslagaccount dat het resultaat is van een aanvraag naar het eindpunt van de opslagservice. Een gegevensvlakbewerking wordt bijvoorbeeld uitgevoerd wanneer u een bericht aan de wachtrij toevoegt. Zie Azure Storage-API voor meer informatie.
In de sectie wordt beschreven hoe u de informatie 'wanneer', 'wie', 'wat' en 'hoe' van besturings- en gegevensvlakbewerkingen identificeert.
Besturingsvlakbewerkingen controleren
Resource Manager-bewerkingen worden vastgelegd in het Azure-activiteitenlogboek. Als u het activiteitenlogboek wilt weergeven, opent u uw opslagaccount in Azure Portal en selecteert u vervolgens Activiteitenlogboek.
Open een logboekvermelding om JSON weer te geven waarin de activiteit wordt beschreven. In de volgende JSON ziet u de informatie 'when', 'what' en 'how' van een besturingsvlakbewerking:
De beschikbaarheid van de 'wie'-informatie is afhankelijk van de verificatiemethode die is gebruikt om de besturingsvlakbewerking uit te voeren. Als de autorisatie is uitgevoerd door een Microsoft Entra-beveiligingsprincipaal, wordt de object-id van die beveiligingsprincipaal ook weergegeven in deze JSON-uitvoer (bijvoorbeeld: "http://schemas.microsoft.com/identity/claims/objectidentifier": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx"). Omdat u mogelijk niet altijd andere identiteitsgerelateerde informatie zoals een e-mailadres of naam ziet, is de object-id altijd de beste manier om de beveiligingsprincipaal uniek te identificeren.
U vindt de beschrijvende naam van die beveiligingsprincipaal door de waarde van de object-id te gebruiken en te zoeken naar de beveiligingsprincipaal op de pagina Microsoft Entra-id van Azure Portal. In de volgende schermopname ziet u een zoekresultaat in Microsoft Entra ID.
Bewerkingen van het gegevensvlak controleren
Gegevensvlakbewerkingen worden vastgelegd in Azure-resourcelogboeken voor Storage. U kunt de diagnostische instelling configureren voor het exporteren van logboeken naar de Log Analytics-werkruimte voor een systeemeigen query-ervaring.
Hier volgt een Log Analytics-query waarmee de gegevens 'when', 'who', 'what' en 'how' worden opgehaald in een lijst met logboekvermeldingen.
StorageQueueLogs
| where TimeGenerated > ago(3d)
| project TimeGenerated, AuthenticationType, RequesterObjectId, OperationName, Uri
Voor het 'wanneer'-gedeelte van uw controle wordt het TimeGenerated veld weergegeven wanneer de logboekvermelding is vastgelegd.
Voor het 'wat'-gedeelte van uw controle toont het Uri veld dat het item is gewijzigd of gelezen.
Voor het gedeelte 'hoe' van uw controle wordt in het OperationName veld weergegeven welke bewerking is uitgevoerd.
Voor het 'wie'-gedeelte van uw controle AuthenticationType geeft u aan welk type verificatie is gebruikt om een aanvraag te doen. In dit veld kunnen alle typen verificatie worden weergegeven die door Azure Storage worden ondersteund, waaronder het gebruik van een accountsleutel, een SAS-token of Microsoft Entra-verificatie.
Als een aanvraag is geverifieerd met behulp van Microsoft Entra ID, biedt het RequesterObjectId veld de meest betrouwbare manier om de beveiligingsprincipaal te identificeren. U vindt de beschrijvende naam van die beveiligingsprincipaal door de waarde van het RequesterObjectId veld te gebruiken en te zoeken naar de beveiligingsprincipaal op de pagina Microsoft Entra-id van Azure Portal. In de volgende schermopname ziet u een zoekresultaat in Microsoft Entra ID.
In sommige gevallen kan een user principal name of UPN worden weergegeven in logboeken. Als de beveiligingsprincipaal bijvoorbeeld een Microsoft Entra-gebruiker is, wordt de UPN waarschijnlijk weergegeven. Voor andere typen beveiligings-principals, zoals door de gebruiker toegewezen beheerde identiteiten, of in bepaalde scenario's, zoals verificatie via meerdere Microsoft Entra-tenants, wordt de UPN niet weergegeven in logboeken.
Deze query toont alle schrijfbewerkingen die worden uitgevoerd door OAuth-beveiligingsprinciplen.
StorageQueueLogs
| where TimeGenerated > ago(3d)
and OperationName == "PutMessage"
and AuthenticationType == "OAuth"
| project TimeGenerated, AuthenticationType, RequesterObjectId, OperationName, Uri
Gedeelde sleutel- en SAS-verificatie bieden geen middelen om afzonderlijke identiteiten te controleren. Als u daarom de mogelijkheid wilt verbeteren om te controleren op basis van identiteit, raden we u aan over te stappen op Microsoft Entra-id en gedeelde sleutel- en SAS-verificatie te voorkomen. Zie Autorisatie van gedeelde sleutels voorkomen voor een Azure Storage-account voor meer informatie over het voorkomen van gedeelde sleutel- en SAS-verificatie. Zie Toegang tot blobs autoriseren met behulp van Microsoft Entra-id om aan de slag te gaan met Microsoft Entra-id
Kosten optimaliseren voor onregelmatige query's
U kunt logboeken exporteren naar Log Analytics voor uitgebreide systeemeigen querymogelijkheden. Wanneer u enorme transacties voor uw opslagaccount hebt, zijn de kosten voor het gebruik van logboeken met Log Analytics mogelijk hoog. Zie prijzen voor Azure Log Analytics. Als u alleen query's wilt uitvoeren op logboeken (bijvoorbeeld querylogboeken voor nalevingscontrole), kunt u overwegen de totale kosten te verlagen door logboeken naar het opslagaccount te exporteren en vervolgens een serverloze queryoplossing te gebruiken boven op logboekgegevens, bijvoorbeeld Azure Synapse.
Met Azure Synapse kunt u serverloze SQL-pool maken om logboekgegevens op te vragen wanneer u dat nodig hebt. Dit kan kosten aanzienlijk besparen.
Exporteer logboeken naar het opslagaccount. Zie Een diagnostische instelling maken.
Een Synapse-werkruimte maken en configureren. Zie Snelstart: een Synapse-werkruimte maken.
Querylogboeken. Zie JSON-bestanden opvragen met behulp van een serverloze SQL-pool in Azure Synapse Analytics.
Hier volgt een voorbeeld:
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