Meilleures pratiques pour la surveillance du Stockage File d’attente Azure
Cet article présente des scénarios courants de surveillance du Stockage File d’attente, ainsi que des recommandations de meilleures pratiques pour les mettre en œuvre.
Surveiller le nombre de messages dans chaque file d’attente
Vous pouvez surveiller le nombre de messages dans toutes les files d’attente d’un compte de stockage à l’aide de la métrique QueueMessageCount. Cette métrique est actualisée quotidiennement.
Si vous utilisez PowerShell, vous pouvez vous servir d’une commande similaire à la suivante :
(Get-AzMetric -ResourceId /subscriptions/xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/contosogroup/providers/Microsoft.Storage/storageAccounts/contoso/queueServices/default -MetricName "QueueMessageCount").data.Average
Vous pouvez déterminer de manière dynamique si des charges de travail doivent être ajustées pour gérer le volume des messages en interrogeant le nombre approximatif de messages dans chaque file d’attente, avant de prendre une mesure appropriée. Pour obtenir le nombre approximatif de messages, utilisez l’opération REST Get Queue Metadata (obtenir les métadonnées de file d’attente) ou l’un des kits de développement logiciel (SDK) de Stockage Blob pris en charge.
L’exemple suivant utilise la bibliothèque Stockage Azure .NET v12 pour obtenir le nombre approximatif de messages.
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;
}
Songez également à utiliser Service Bus qui prend en charge les messages par entité. Pour en savoir plus, consultez Informations de référence sur l’analyse des données Azure Service Bus.
Auditer l’activité du compte
Dans de nombreux cas, vous devez auditer les activités de vos comptes de stockage à des fins de sécurité et de conformité. Les opérations sur les comptes de stockage se répartissent en deux catégories : Plan de contrôle et Plan de données.
Une opération de plan de contrôle est une demande Azure Resource Manager de création de compte de stockage ou de mise à jour d’une propriété d’un compte de stockage existant. Pour plus d’informations, consultez Azure Resource Manager.
Une opération de plan de données est une opération sur les données d’un compte de stockage, qui résulte d’une demande adressée au point de terminaison du service de stockage. Par exemple, une opération de plan de données est exécutée lorsque vous ajoutez un message à la file d’attente. Pour plus d’informations, consultez API de Stockage Azure.
La section montre comment trouver les informations sur le « quand », le « qui », le « quoi » et le « comment » des opérations de plan de contrôle et de plan de données.
Audit des opérations de plan de contrôle
Les opérations de Resource Manager sont capturées dans le journal d’activité Azure. Pour afficher le journal d’activité, ouvrez votre compte de stockage dans le portail Azure, puis sélectionnez Journal d’activité.
Ouvrez une entrée de journal pour afficher un JSON décrivant l’activité. Le JSON suivant présente des informations sur le « quand », le « quoi » et le « comment » d’une opération de plan de contrôle :
La disponibilité des informations sur le « qui » dépend de la méthode d’authentification utilisée pour effectuer l’opération de plan de contrôle. Si l’autorisation est le fait d’un principal de sécurité Microsoft Entra, l’identificateur d’objet de celui-ci apparaît également dans cette sortie JSON (par exemple, "http://schemas.microsoft.com/identity/claims/objectidentifier": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx"). Étant donné que vous ne verrez peut-être pas toujours d’autres informations relatives à l’identité, telles qu’une adresse e-mail ou un nom, l’identificateur d’objet est toujours la meilleure façon d’identifier de manière unique le principal de sécurité.
Vous pouvez trouver le nom convivial de celui-ci en prenant la valeur de l’identificateur d’objet et en recherchant le principal de sécurité dans la page Microsoft Entra ID du portail Azure. La capture d’écran suivante montre un résultat de recherche dans Microsoft Entra ID.
Audit des opérations de plan de données
Les opérations de plan de données sont capturées dans des journaux de ressources Azure pour le Stockage. Vous pouvez configurer un paramètre de diagnostic afin d’exporter les journaux vers l’espace de travail Log Analytics pour une expérience de requête native.
Voici une requête Log Analytics qui extrait les informations sur le « quand », le « qui », le « quoi » et le « comment » dans une liste d’entrées de journal.
StorageQueueLogs
| where TimeGenerated > ago(3d)
| project TimeGenerated, AuthenticationType, RequesterObjectId, OperationName, Uri
Pour la partie « quand » de votre audit, le champ TimeGenerated indique quand l’entrée de journal a été enregistrée.
Pour la partie « quoi » de votre audit, le champ Uri indique l’élément qui a été modifié ou lu.
Pour la partie « comment » de votre audit, le champ OperationName indique l’opération qui a été exécutée.
Pour la partie « qui » de votre audit, le champ AuthenticationType indique le type d’authentification utilisé pour effectuer une demande. Ce champ peut afficher tout type d’authentification pris en charge par Stockage Azure, y compris l’utilisation d’une clé de compte, d’un jeton de signature d’accès partagé (SAP) ou d’une authentification Microsoft Entra.
Si une requête a été authentifiée à l’aide de Microsoft Entra ID, le champ RequesterObjectId constitue la méthode la plus fiable pour identifier le principal de sécurité. Vous pouvez trouver le nom convivial de celui-ci en prenant la valeur du champ RequesterObjectId et en recherchant le principal de sécurité dans la page Microsoft Entra ID du portail Azure. La capture d’écran suivante montre un résultat de recherche dans Microsoft Entra ID.
Dans certains cas, un nom d’utilisateur principal, ou UPN, peut apparaître dans les journaux. Par exemple, si le principal de sécurité est un utilisateur Microsoft Entra, l’UPN s’affichera probablement. Pour d’autres types de principaux de sécurité tels que les identités managées attribuées par l’utilisateur, ou dans certains scénarios tels que l’authentification croisée de locataire Microsoft Entra, l’UPN n’apparaît pas dans les journaux.
Cette requête affiche toutes les opérations d’écriture effectuées par les principaux de sécurité OAuth.
StorageQueueLogs
| where TimeGenerated > ago(3d)
and OperationName == "PutMessage"
and AuthenticationType == "OAuth"
| project TimeGenerated, AuthenticationType, RequesterObjectId, OperationName, Uri
L’authentification avec clé partagée et SAP n’offre aucun moyen d’auditer des identités individuelles. Par conséquent, si vous souhaitez améliorer votre capacité à auditer sur la base de l’identité, nous vous recommandons de passer à Microsoft Entra ID et d’empêcher l’authentification avec clé partagée et SAP. Pour savoir comment empêcher l’authentification avec clé partagée et SAP, consultez Empêcher l’autorisation avec clé partagée pour un compte de stockage Azure. Pour commencer à utiliser Microsoft Entra ID, consultez Autoriser l’accès aux objets blob à l’aide de Microsoft Entra ID
Optimiser les coûts des requêtes peu fréquentes
Vous pouvez exporter les journaux vers Log Analytics afin de bénéficier de fonctionnalités de requête natives riches. Lorsque vous avez des transactions massives sur votre compte de stockage, le coût d’utilisation des journaux avec Log Analytics peut être élevé. Consultez Tarification d’Azure Log Analytics. Si vous n’envisagez d’interroger des journaux qu’occasionnellement (par exemple, à des fins d’audit de conformité), vous pouvez envisager de réduire le coût total de ces requêtes en exportant les journaux vers un compte de stockage, puis en utilisant une solution de requête serverless sur données de journal, telle qu’Azure Synapse.
Azure Synapse vous permet de créer un pool SQL serverless pour interroger des données de journal quand vous en avez besoin. Cela peut réduire sensiblement les coûts.
Exportez les journaux vers un compte de stockage. Consultez Création d’un paramètre de diagnostic.
Créez et configurez un espace de travail Synapse. Consultez Démarrage rapide : créer un espace de travail Synapse.
Interrogez les journaux. Consultez Interroger des fichiers JSON à l’aide d’un pool SQL serverless dans Azure Synapse Analytics.
Voici un exemple :
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