Мониторинг предоставляет аналитические сведения о поведении и работоспособности систем и помогает создать целостное представление о среде, исторических тенденциях, сопоставить различные факторы и оценить изменения производительности, потребления или скорости ошибок.
Функции 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
- Обработка бессерверных событий представляет собой эталонную архитектуру, деталисируя типичную архитектуру этого типа, с примерами кода и обсуждением важных аспектов.