Поделиться через

Рекомендации по мониторингу Хранилища очередей Azure

  • Статья

В этой статье рассматриваются типичные сценарии мониторинга Хранилища очередей, а также приводятся рекомендации по их реализации.

Мониторинг количества сообщений в каждой очереди

Количество сообщений для всех очередей в учетной записи хранения можно отслеживать с помощью метрики QueueMessageCount. Эта метрика обновляется ежедневно.

Если вы работаете с PowerShell, можно использовать команду, аналогичную следующей:

(Get-AzMetric -ResourceId /subscriptions/xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/contosogroup/providers/Microsoft.Storage/storageAccounts/contoso/queueServices/default -MetricName "QueueMessageCount").data.Average

Если необходимо динамически определить, нужно ли настраивать рабочие нагрузки для обработки объема сообщений, можно запросить приблизительное число сообщений в каждой очереди и затем ответить, выполнив соответствующее действие. Чтобы получить приблизительное число сообщений, используйте операцию REST Получение метаданных очереди или любой из поддерживаемых пакетов SDK для хранилища BLOB-объектов.

Для получения приблизительного числа сообщений в следующем примере используется библиотека .NET службы хранилища Azure версии 12.

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;
}

Также рекомендуется использовать служебную шину, которая поддерживает сообщение на каждую сущность. Дополнительные сведения см. в статье Справочник по мониторингу данных Служебной шины Azure.

Аудит действий учетной записи

Во многих случаях для обеспечения безопасности и соответствия требованиям требуется аудит действий учетных записей хранения. Операции с учетными записями хранения можно разделить на две категории: уровень управления и плоскость данных.

Операция уровня управления представляет собой любой запрос Azure Resource Manager на создание учетной записи хранения или обновление свойства существующей учетной записи хранения. Дополнительные сведения см. в статье об Azure Resource Manager.

Операция в плоскости данных — это операция с данными в учетной записи хранения, полученная в результате запроса к конечной точке службы хранилища. Например, операция в плоскости данных выполняется при добавлении сообщения в очередь. Дополнительные сведения см. в статье об API службы хранилища Azure.

В этом разделе объясняется, показано, как ответить на вопросы "когда", "кто", "что" и "как" об операциях уровня управления и плоскости данных.

Аудит операций уровня управления

Операции Resource Manager фиксируются в журнале действий Azure. Чтобы просмотреть журнал действий, откройте учетную запись хранения на портале Azure, а затем выберите Журнал действий.

Журнал действий

Откройте любую запись журнала, чтобы просмотреть код JSON, описывающий действие. В следующем примере JSON показаны сведения "когда", "что" и "как" об операции плоскости управления:

JSON журнала действий

Доступность ответов на вопрос "кто" зависит от способа проверки подлинности, который использовался для операции на уровне управления. Если авторизация была выполнена субъектом безопасности Microsoft Entra, идентификатор объекта этого субъекта безопасности также будет отображаться в выходных данных JSON (например: "http://schemas.microsoft.com/identity/claims/objectidentifier": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx"). Поскольку другие сведения, связанные с удостоверениями, такие как адрес электронной почты или имя, отображаются не всегда, идентификатор объекта всегда лучше всего уникальным образом идентифицирует субъекта безопасности.

Понятное имя этого субъекта безопасности можно найти, принимая значение идентификатора объекта и выполняя поиск субъекта безопасности на странице идентификатора Microsoft Entra ID портал Azure. На следующем снимке экрана показан результат поиска в идентификаторе Microsoft Entra.

Поиск идентификатора Microsoft Entra

Аудит операций в плоскости данных

Операции в плоскости данных фиксируются в журналах ресурсов Azure для службы хранилища. Вы можете настроить параметр диагностики для экспорта журналов в рабочую область Log Analytics для использования встроенных средств работы с запросами.

Ниже приведен запрос Log Analytics, который получает сведения "когда", "кто", "что" и "как" в списке записей журнала.

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

Для аудита сведений категории "когда" в поле TimeGenerated показано время создания записи журнала.

Для аудита сведений категории "что" в поле Uri указано, какой именно объект был изменен или прочитан.

Для аудита сведений категории "как" в поле OperationName показано, какая операция была выполнена.

Для аудита сведений категории "что" в поле AuthenticationType показано, какой тип проверки подлинности использовался для выполнения запроса. Это поле может показать любой из типов проверки подлинности, которые служба хранилища Azure поддерживает, включая использование ключа учетной записи, маркера SAS или проверки подлинности Microsoft Entra.

Если запрос прошел проверку подлинности с помощью идентификатора Microsoft Entra, RequesterObjectId поле предоставляет наиболее надежный способ идентификации субъекта безопасности. Вы можете найти понятное имя этого субъекта безопасности, выполнив значение RequesterObjectId поля и выполнив поиск субъекта безопасности на странице идентификатора Microsoft Entra портал Azure. На следующем снимке экрана показан результат поиска в идентификаторе Microsoft Entra.

Поиск в Microsoft Entra ID-2

В некоторых случаях в журналах может отображаться имя субъекта-пользователя или UPN. Например, если субъект безопасности является пользователем Microsoft Entra, имя участника-пользователя, скорее всего, появится. Для других типов субъектов безопасности, таких как назначенные пользователем управляемые удостоверения, или в некоторых сценариях, таких как проверка подлинности клиента Microsoft Entra, имя участника-пользователя не будет отображаться в журналах.

В этом запросе отображаются все операции записи, выполняемые субъектами безопасности OAuth.

StorageQueueLogs
| where TimeGenerated > ago(3d)
  and OperationName == "PutMessage"
  and AuthenticationType == "OAuth"
| project TimeGenerated, AuthenticationType, RequesterObjectId, OperationName, Uri

Общий ключ и проверка подлинности SAS не позволяют проводить аудит отдельных удостоверений. Поэтому, если вы хотите улучшить возможность аудита на основе удостоверений, рекомендуется перейти на идентификатор Microsoft Entra и запретить проверку подлинности SAS и общий ключ. Сведения о том, как запретить проверку подлинности на основе общего ключа и SAS, см. в статье о запрете авторизации с использованием общего ключа для учетной записи хранения Azure. Сведения о начале работы с идентификатором Microsoft Entra см. в статье "Авторизация доступа к BLOB-объектам с помощью идентификатора Microsoft Entra"

Оптимизация затрат для нечастых запросов

Для выполнения расширенных запросов журналы можно экспортировать в Log Analytics. При большом объеме транзакций в учетной записи хранения стоимость использования журналов с Log Analytics может быть высокой. См. цены на Azure Log Analytics. Если запрашивать журналы планируется нечасто (например, для аудита соответствия), вы можете сократить общую стоимость, экспортировав их в учетную запись хранения, а затем используя бессерверное решение для запросов на основе данных журналов, например Azure Synapse.

С помощью Azure Synapse можно создать бессерверный пул SQL для запроса данных журналов по мере необходимости. Это позволяет значительно снизить затраты.

  1. Экспортируйте журналы в учетную запись хранения. См. документ Создание параметра диагностики.

  2. Создайте и настройте рабочую область Synapse. См. краткое руководство по созданию рабочей области Synapse.

  3. Запрашивайте журналы. См. документЗапрос файлов JSON с помощью бессерверного пула SQL в Azure Synapse Analytics.

    Приведем пример:

     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

См. также