Мониторинг Функций Azure и Центров событий Azure

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

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

В этом разделе представлены полезные функции и аналитические сведения, которые можно получить из Application Insights для центров событий и решения "Функции".

Схема сопоставления приложений

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

После отправки ожидаемой загрузки в систему вы можете перейти в Application Insights в портал Azure и на боковой панели выберите "Карта приложений". Ниже приведена карта, показывающая три функции, три концентратора событий и очевидные сбои при записи в нижестойную базу данных:

Сведения о сквозной транзакции

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

Метрики платформы и данные телеметрии

Метрики, созданные платформой в Azure Monitor для Центров событий и Функции Azure, можно использовать для общего мониторинга поведения и работоспособности решения:

• Центры событий Azure метрики в Azure Monitor заинтересованы в сборе полезных сведений для Центров событий (например, агрегирования входящих запросов, исходящих запросов, регулирование запросов, успешных запросов, входящих сообщений, исходящих сообщений, входящие сообщения, входящие байты, исходящие байты, захваченные байты, ошибки пользователей).

• Функции Azure метрики используют многие метрики из службы приложение Azure с добавлением единиц выполнения функций и единиц выполнения функций, которые можно использовать для понимания использования и стоимости плана потребления. Другие интересующие вас метрики : подключения, данные в, выход данных, средний рабочий набор памяти, число потоков, запросы и время отклика.

Функции Azure интегрируется с Application Insights для предоставления расширенных и подробных данных телеметрии и аналитических сведений о выполнении узлов и функций Функций. Дополнительные сведения см. в статье "Анализ Функции Azure телеметрии в Application Insights". При использовании Application Insights для мониторинга топологии доступны различные конфигурации. Дополнительные сведения см. в статье Настройка мониторинга для Функций Azure.

Ниже приведен пример дополнительной телеметрии для активируемых функций Центров событий, созданных в таблице трассировок :

Trigger Details: PartionId: 6, Offset: 3985758552064-3985758624640, EnqueueTimeUtc: 2022-10-31T12:51:58.1750000+00:00-2022-10-31T12:52:03.8160000+00:00, SequenceNumber: 3712266-3712275, Count: 10

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

• Идентификатор секции (6)
• Диапазон смещения секции (3985758552064-3985758624640)
• Диапазон времени в формате UTC (2022-10-31T12:51:58.17500000+00:00-2022-10-31T12:52:03.81600000+00:00)
• Диапазон последовательности 3712266-3712275
• Количество сообщений (10)

Дополнительные сведения об использовании этой телеметрии см. в разделе "Примеры запросов Application Insights".

Пользовательские данные телеметрии также можно использовать для разных языков (библиотека классов C#, изолированная библиотека C#, скрипт C#, JavaScript, Java, PowerShell и Python). Это ведение журнала отображается в таблице трассировок в Application Insights. Вы можете создать собственные записи в Application Insights и добавить пользовательские измерения, которые можно использовать для запроса данных и создания пользовательских панелей мониторинга.

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

Для Центров событий корреляция внедряется в полезные данные события, и в событиях отображается свойство Diagnostic-Id :

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

Примеры запросов Application Insights

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

Если выборка включена в Application Insights, в данных могут быть пробелы.

Подробные сведения об обработке событий

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

• Значение dispatchTimeMilliseconds приблизит продолжительность времени между записью события в концентратор событий и когда оно было выбрано приложением-функцией для обработки.
• dispatchTimeMilliseconds может быть отрицательным или иным образом неточным из-за смещения часов между сервером концентратора событий и приложением-функцией.
• Секции Центров событий обрабатываются последовательно. Сообщение не будет отправлено в код функции для обработки до тех пор, пока не будут обработаны все предыдущие сообщения. Отслеживайте время выполнения функций, так как более длительное время выполнения приведет к задержкам отправки.
• Вычисление использует enqueueTime первого сообщения в пакете. Время отправки может быть меньше для других сообщений в пакете.
• dispatchTimeMilliseconds основан на точке во времени.
• Порядковые номера являются секционированием и могут возникать повторяющиеся обработки, так как Центры событий не гарантируют точно однократную доставку сообщений.

traces
| where message startswith "Trigger Details: Parti"
| parse message with * "tionId: " partitionId:string ", Offset: "
offsetStart:string "-" offsetEnd:string", EnqueueTimeUtc: "
enqueueTimeStart:datetime "+00:00-" enqueueTimeEnd:datetime "+00:00, SequenceNumber: "
sequenceNumberStart:string "-" sequenceNumberEnd:string ", Count: "
messageCount:int
| extend dispatchTimeMilliseconds = (timestamp - enqueueTimeStart) / 1ms
| project timestamp, cloud_RoleInstance, operation_Name, processId =
customDimensions.ProcessId, partitionId, messageCount, sequenceNumberStart,
sequenceNumberEnd, enqueueTimeStart, enqueueTimeEnd, dispatchTimeMilliseconds

Визуализация задержки отправки

Этот запрос визуализирует задержку отправки событий 50-й и 90-й процентили для заданной функции, активируемой концентратором событий. Дополнительные сведения и заметки см. в приведенном выше запросе.

traces
| where operation_Name == "<ENTER THE NAME OF YOUR FUNCTION HERE>"
| where message startswith "Trigger Details: Parti"
| parse message with * "tionId: " partitionId:string ", Offset: "
offsetStart:string "-" offsetEnd:string", EnqueueTimeUtc: "
enqueueTimeStart:datetime "+00:00-" enqueueTimeEnd:datetime "+00:00, SequenceNumber: "
sequenceNumberStart:string "-" sequenceNumberEnd:string ", Count: "
messageCount:int
| extend dispatchTimeMilliseconds = (timestamp - enqueueTimeStart) / 1ms
| summarize percentiles(dispatchTimeMilliseconds, 50, 90) by bin(timestamp, 5m)
| render timechart

Сводка по задержке отправки

Этот запрос аналогичен приведенному выше, но отображает представление сводки.

traces
| where message startswith "Trigger Details: Parti"
| parse message with * "tionId: " partitionId:string ", Offset: "
offsetStart:string "-" offsetEnd:string", EnqueueTimeUtc: "
enqueueTimeStart:datetime "+00:00-" enqueueTimeEnd:datetime "+00:00, SequenceNumber: "
sequenceNumberStart:string "-" sequenceNumberEnd:string ", Count: "
messageCount:int
| extend dispatchTimeMilliseconds = (timestamp - enqueueTimeStart) / 1ms
| summarize messageCount = sum(messageCount),
percentiles(dispatchTimeMilliseconds, 50, 90, 99, 99.9, 99.99) by operation_Name

Распределение сообщений по секциям

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

traces
| where message startswith "Trigger Details: Parti"
| parse message with * "tionId: " partitionId:string ", Offset: "
offsetStart:string "-" offsetEnd:string", EnqueueTimeUtc: "
enqueueTimeStart:datetime "+00:00-" enqueueTimeEnd:datetime "+00:00, SequenceNumber: "
sequenceNumberStart:string "-" sequenceNumberEnd:string ", Count: "
messageCount:int
| summarize messageCount = sum(messageCount) by cloud_RoleInstance,
bin(timestamp, 5m)
| render areachart kind=stacked

Распределение сообщений между экземплярами

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

traces
| where message startswith "Trigger Details: Parti"
| parse message with * "tionId: " partitionId:string ", Offset: "
offsetStart:string "-" offsetEnd:string", EnqueueTimeUtc: "
enqueueTimeStart:datetime "+00:00-" enqueueTimeEnd:datetime "+00:00, SequenceNumber: "
sequenceNumberStart:string "-" sequenceNumberEnd:string ", Count: "
messageCount:int
| summarize messageCount = sum(messageCount) by cloud_RoleInstance,
bin(timestamp, 5m)
| render areachart kind=stacked

Выполнение экземпляров и выделенных экземпляров

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

traces
| where message startswith "Trigger Details: Parti"
| summarize type = "Executing Instances", Count = dcount(cloud_RoleInstance) by
bin(timestamp, 60s)
| union (
    traces
    | summarize type = "Allocated Instances", Count = dcount(cloud_RoleInstance) by
bin(timestamp, 60s)
)
| project timestamp, type, Count
| render timechart

Все данные телеметрии для определенного выполнения функции

Поле operation_Id можно использовать в разных таблицах в Application Insights. Для центров событий, активируемых Функции Azure следующий запрос, например, приведет к получению сведений о триггере, телеметрии из журналов в коде функции, а также зависимостей и исключений:

union isfuzzy=true requests, exceptions, traces, dependencies
| where * has "<ENTER THE OPERATION_ID OF YOUR FUNCTION EXECUTION HERE>"
| order by timestamp asc

Сквозная задержка для события

Как свойство enqueueTimeUtc в трассировке сведений триггера показывает время закручения только первого события каждого пакета, обрабатываемого функцией, более расширенный запрос можно использовать для вычисления сквозной задержки событий между двумя функциями с центрами событий между центрами событий. Этот запрос развернет ссылки на операции (если таковые) в запросе второй функции и сопоставит время окончания с тем же идентификатором операции первого времени запуска функции.

let start = view(){
requests
| where operation_Name == "FirstFunction"
| project start_t = timestamp, first_operation_Id = operation_Id
};
let link = view(){
requests
| where operation_Name == "SecondFunction"
| mv-expand ex = parse_json(tostring(customDimensions["_MS.links"]))
| extend parent = case(isnotempty(ex.operation_Id), ex.operation_Id, operation_Id )
| project first_operation_Id = parent, second_operation_Id = operation_Id
};
let finish = view(){
traces
| where customDimensions["EventName"] == "FunctionCompleted" and operation_Name
== "SecondFunction"
| project end_t = timestamp, second_operation_Id = operation_Id
};
start
| join kind=inner (
link
| join kind=inner finish on second_operation_Id
) on first_operation_Id
| project start_t, end_t, first_operation_Id, second_operation_Id
| summarize avg(datetime_diff('second', end_t, start_t))

Соавторы

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

Автор субъекта:

• Дэвид Баркол | Главный специалист по решению GBB

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

Следующие шаги

Дополнительные сведения см. в следующих статьях:

• Анализ телеметрии Функций Azure в Application Insights
• Настройка мониторинга для Функции Azure
• Анализ телеметрии Функций Azure в Application Insights
• Метрики в Azure Monitor — Центры событий Azure
• язык запросов Kusto
• Обработка бессерверных событий представляет собой эталонную архитектуру, деталисируя типичную архитектуру этого типа, с примерами кода и обсуждением важных аспектов.