Мониторинг обработки бессерверных событий

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

Мониторинг позволяет получить представление о поведении и работоспособности систем. Она помогает сформировать целостное представление об окружающей среде, получить исторические тенденции, сопоставить различные факторы и измерить изменения в производительности, потреблении или частоте ошибок. Мониторинг можно использовать для определения оповещений при возникновении условий, которые могут повлиять на качество службы, или при возникновении условий, представляющих особый интерес для конкретной среды.

В этой статье демонстрируется использование Azure Monitor для мониторинга бессерверного приложения, созданного с помощью Центров событий и Функции Azure. В нем рассматриваются полезные метрики для мониторинга, описывается интеграция с Application Insights и сбор пользовательских метрик, а также приведены примеры кода.

Предположения

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

• События поступают в Центры событий Azure.
• Приложение-функция запускается для обработки события.
• Azure Monitor доступен для использования с вашей архитектурой.

Метрики из Azure Monitor

Прежде чем приступить к формированию полезных аналитических сведений об архитектуре, необходимо решить, какие метрики потребуются. Каждый ресурс выполняет разные задачи и, в свою очередь, создает разные метрики.

Эти метрики из Концентратора событий будут интересны для получения полезных аналитических сведений:

• Входящие запросы
• Исходящие запросы
• Регулируемые запросы
• Успешные запросы.
• Входящие сообщения
• Исходящие сообщения
• Захваченные сообщения
• Входящие байты
• Исходящие байты
• Захваченные байты
• Ошибки пользователей

Аналогичным образом, эти метрики из Функции Azure будут интересны для получения полезных аналитических сведений:

• Число выполнений функции
• Соединения
• Данные в
• Выход данных
• Ошибки HTTP-сервера
• Requests
• Запросы в очереди приложений
• Время отклика

Использование ведения журнала диагностика для сбора аналитических сведений

При совместном анализе приведенные выше метрики можно использовать для формирования и сбора следующих аналитических сведений:

• Частота запросов, обрабатываемых Центрами событий
• Частота запросов, обрабатываемых Функции Azure
• Общая пропускная способность концентратора событий
• Ошибки пользователей
• Длительность Функции Azure
• Сквозная задержка
• Задержка на каждом этапе
• Число потерянных сообщений
• Количество сообщений, обработанных более одного раза

Чтобы убедиться, что Центры событий записывают необходимые метрики, сначала необходимо включить журналы диагностики (которые отключены по умолчанию). Затем необходимо выбрать нужные журналы и настроить правильную рабочую область Log Analytics в качестве назначения для них.

Интересующие нас категории журналов и метрик:

• OperationalLogs
• AutoScaleLogs
• KafkaCoordinatorLogs (для рабочих нагрузок Apache Kafka)
• KafkaUserErrorLogs (для рабочих нагрузок Apache Kafka)
• EventHubVNetConnectionEvent
• AllMetrics

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

Примечание

Чтобы использовать диагностика журналов для сбора аналитических сведений, необходимо создавать центры событий в разных пространствах имен. Это связано с ограничением в Azure.

Центры событий, заданные в заданном пространстве имен Центров событий, представлены в метриках Azure Monitor в измерении с именем EntityName. В портал Azure данные для определенного концентратора событий обычно можно просматривать в этом экземпляре Azure Monitor. Но когда данные метрик направляются в диагностика журнала, в настоящее время невозможно просмотреть данные для каждого концентратора событий путем фильтрации по измерениюEntityName.

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

Работа с Application Insights

Вы можете включить Application Insights для сбора метрик и пользовательских данных телеметрии из Функции Azure. Это позволяет определить аналитику, которая соответствует вашим собственным целям, предоставляя еще один способ получения важных аналитических сведений для сценария бессерверной обработки событий.

На снимках экрана показан пример списка пользовательских метрик и телеметрии в Application Insights:

Пользовательские метрики по умолчанию

В Application Insights пользовательские метрики для Функции Azure хранятся в customMetrics таблице. Он включает следующие значения, охватывающие временная шкала для разных экземпляров функций:

• AvgDurationMs
• MaxDurationMs
• MinDurationMs
• Successes
• Failures
• SuccessRate
• Count

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

На этом снимке экрана показано, как выглядят эти пользовательские метрики по умолчанию при просмотре в Application Insights:

Пользовательские сообщения

Пользовательские сообщения, зарегистрированные в коде функции Azure (с помощью ILogger), получаются из таблицы Application Insights traces .

Таблица traces имеет следующие важные свойства (среди прочего):

• timestamp
• cloud_RoleInstance
• operation_Id
• operation_Name
• message

Ниже приведен пример того, как может выглядеть пользовательское сообщение в интерфейсе Application Insights:

Если входящее сообщение концентратора событий или EventData[] регистрируется как часть этого пользовательского ILogger сообщения, это также становится доступным в Application Insights. Это может быть очень полезно.

В нашем сценарии обработки бессерверных событий мы регистрируем сериализованный текст сообщения JSON, полученный из концентратора событий. Это позволяет записывать необработанный массив байтов, а также SystemPropertiesx-opt-sequence-number, x-opt-offsetи x-opt-enqueued-time. Чтобы определить, когда каждое сообщение было получено концентратором событий, x-opt-enqueued-time используется свойство .

Пример запроса

traces
| where timestamp between(min_t .. max_t)
| where message contains "Body"
| extend m = parse_json(message))
| project timestamp = todatetime(m.SystemProperties.["x-opt-enqueued-time"])

Пример запроса вернет сообщение, аналогичное приведенному в следующем примере результата, которое регистрируется по умолчанию в Application Insights. Свойства можно использовать для поиска и сбора дополнительных аналитических сведений о сообщениях Trigger Details , полученных для PartitionId, Offsetи SequenceNumber.

Пример результата примера запроса:

"message": Trigger Details: PartitionId: 26, Offset: 17194119200, EnqueueTimeUtc: 2020-11-03T02:14:01.7740000Z, SequenceNumber: 843572, Count: 10,

Предупреждение

В настоящее время в библиотеке для Функций Java Azure возникает проблема, которая препятствует доступу к PartitionID и PartitionContext при использовании EventHubTrigger. Дополнительные сведения см. в этом отчете о проблеме GitHub.

Отслеживание потока сообщений с помощью идентификатора транзакции с помощью Application Insights

В Application Insights можно просмотреть все данные телеметрии, связанные с конкретной транзакцией, выполнив запрос поиска транзакций по значению транзакции Operation Id . Это может быть особенно полезно для записи значений процентиля среднего времени для сообщений при перемещении транзакции через конвейер потока событий.

На следующем снимке экрана показан пример поиска транзакций в интерфейсе Application Insights. Требуемый Operation ID объект вводится в поле запроса, идентифицируется значком лупы (и отображается здесь в красной рамке). В нижней части области main на вкладке Results отображаются соответствующие события в последовательном порядке. В каждой Operation ID записи события значение выделено темно-синим цветом для удобства проверки.

Запрос, созданный для определенного идентификатора операции, будет выглядеть следующим образом. Обратите внимание, что Operation ID GUID указан в предложении where * has третьей строки. Этот пример дополнительно сужает запрос между двумя разными datetimes.

union isfuzzy=true availabilityResults, requests, exceptions, pageViews, traces, customEvents, dependencies
| where timestamp > datetime("2020-10-09T06:58:40.024Z") and timestamp < datetime("2020-11-11T06:58:40.024Z")
| where * has "1c8c9d7073a00e4bbdcc8f2e6570e46"
| order by timestamp desc
| take 100

Ниже приведен снимок экрана: запрос и соответствующие результаты могут выглядеть в интерфейсе Application Insights:

Сбор пользовательских метрик из Функции Azure

Функции .NET

Структурированное ведение журнала используется в функциях Azure .NET для записи пользовательских измерений в таблице трассировок Application Insights. Затем эти пользовательские измерения можно использовать для запроса данных.

В качестве примера ниже приведена инструкция журнала в .NET TransformingFunction:

log.LogInformation("TransformingFunction: Processed sensorDataJson={sensorDataJson}, " +
    "partitionId={partitionId}, offset={offset} at {enqueuedTimeUtc}, " +
    "inputEH_enqueuedTime={inputEH_enqueuedTime}, processedTime={processedTime}, " +
    "transformingLatencyInMs={transformingLatencyInMs}, processingLatencyInMs={processingLatencyInMs}",
    sensorDataJson,
    partitionId,
    offset,
    enqueuedTimeUtc,
    inputEH_enqueuedTime,
    processedTime,
    transformingLatency,
    processingLatency);

Полученные журналы, созданные в Application Insights, содержат указанные выше параметры в виде пользовательских измерений, как показано на этом снимке экрана:

Эти журналы можно запрашивать следующим образом:

traces
| where timestamp between(min_t .. max_t)
// Function name should be of the function consuming from the Event Hub of interest
| where operation_Name == "{Function_Name}"
| where message has "{Function_Name}: Processed"
| project timestamp = todatetime(customDimensions.prop__enqueuedTimeUtc)

Примечание

Чтобы убедиться, что мы не влияем на производительность в этих тестах, мы включили параметры выборки журналов функций Azure для Application Insights с помощью host.json файла, как показано ниже. Это означает, что вся статистика, полученная в результате ведения журнала, считается средними значениями, а не фактическими значениями.

Пример host.json:

"logging": {
    "applicationInsights": {
        "samplingExcludedTypes": "Request",
        "samplingSettings": {
            "isEnabled": true
        }
    }
}

Функции Java

В настоящее время структурированное ведение журнала не поддерживается в функциях Java Azure для записи пользовательских измерений в таблице трассировок Application Insights.

В качестве примера ниже приведена инструкция журнала в Java TransformingFunction:

LoggingUtilities.logSuccessInfo(
    context.getLogger(), 
    "TransformingFunction", 
    "SuccessInfo", 
    offset, 
    processedTimeString, 
    dateformatter.format(enqueuedTime), 
    transformingLatency
);

Полученные журналы, созданные в Application Insights, содержат указанные выше параметры в сообщении, как показано ниже:

Эти журналы можно запрашивать следующим образом:

traces
| where timestamp between(min_t .. max_t)
// Function name should be of the function consuming from the Event Hub of interest
| where operation_Name in ("{Function name}") and message contains "SuccessInfo"
| project timestamp = todatetime(tostring(parse_json(message).enqueuedTime))

Примечание

Чтобы убедиться, что мы не влияем на производительность в этих тестах, мы включили параметры выборки журналов функций Azure для Application Insights с помощью host.json файла, как показано ниже. Это означает, что вся статистика, полученная в результате ведения журнала, считается средними значениями, а не фактическими значениями.

Пример host.json:

"logging": {
    "applicationInsights": {
        "samplingExcludedTypes": "Request",
        "samplingSettings": {
            "isEnabled": true
        }
    }
}

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально она была написана следующими авторами.

Основной автор:

• Раджаса Савант | Старший инженер по программному обеспечению

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Связанные ресурсы

• Бессерверная обработка событий — это эталонная архитектура с подробным описанием типичной архитектуры этого типа с примерами кода и обсуждением важных аспектов.
• Депакетирование и фильтрация при бессерверной обработке событий с помощью Центров событий более подробно описывает, как работают эти части эталонной архитектуры.
• Сценарий приватного канала в обработке потока событий — это решение для реализации аналогичной архитектуры в виртуальной сети с частными конечными точками для повышения безопасности.
• Azure Kubernetes в обработке потока событий описывает разновидность бессерверной архитектуры, управляемой событиями, работающей в Azure Kubernetes с масштабировщиком KEDA.