Настройка мониторинга для Функций Azure

Функции Azure интегрируются с Application Insights, что позволяет вам лучше отслеживать свои приложения-функции. Application Insights, компонент Azure Monitor, — это расширяемая служба управления производительностью приложений (APM), которая собирает данные, создаваемые приложением-функцией, включая сведения, записываемые им в журналы. Интеграция с Application Insights обычно настраивается при создании приложения-функции. Если в приложении не задан ключ инструментирования, необходимо сначала включить интеграцию с Application Insights.

Вы можете использовать Application Insights без какой бы то ни было настройки конфигурации. Однако конфигурация по умолчанию может привести к большим объемам данных. Если вы используете подписку Azure для Visual Studio, объем данных Application Insights может достигнуть установленного верхнего предела. Дополнительные сведения о затратах на Application Insights см. в разделе Выставление счетов Application Insights. Дополнительные сведения см. в разделе Решения с большим объемом данных телеметрии.

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

Примечание.

Вы можете использовать специально настроенные параметры приложения для представления определенных параметров в файле host.json для определенной среды. Это позволяет эффективно изменять параметры host.json без необходимости повторно публиковать файл host.json в проекте. Дополнительные сведения см. в разделе Переопределение значений из host.json.

Пользовательские журналы приложений

По умолчанию пользовательские журналы приложений отправляются в узел Функций, который затем отправляет их в Application Insights в категорию рабочей роли. Некоторые стеки языков позволяют вместо этого отправлять журналы непосредственно в Application Insights, что обеспечивает полный контроль над тем, как создаются журналы. В этом случае конвейер ведения журнала изменяется на worker -> Functions host -> Application Insights worker -> Application Insights.

В следующей таблице перечислены параметры конфигурации, доступные для каждого стека:

Языковой стек	Где настроить пользовательские журналы
.NET (модель в процессе)	host.json
.NET (изолированная модель)	По умолчанию (отправка пользовательских журналов в узел функций): host.json Сведения о отправке журналов непосредственно в Application Insights см. в статье "Настройка Application Insights" в HostBuilder
Node.JS	host.json
Python	host.json
Java	По умолчанию (отправка пользовательских журналов в узел функций): host.json Сведения о отправке журналов непосредственно в Application Insights см. в статье "Настройка агента Java Application Insights"
PowerShell	host.json

Когда вы настраиваете отправку журналов пользовательских приложений напрямую, узел больше не выдает их и host.json больше не управляет их поведением. Аналогичным образом параметры, предоставляемые каждым стеком, применяются только к пользовательским журналам, и они не изменяют поведение других журналов среды выполнения, описанных в этой статье. В этом случае для управления поведением всех журналов может потребоваться внести изменения в обе конфигурации.

Настройка категорий

В средстве ведения журнала Функций Azure предусмотрена категория для каждого журнала. Категория указывает, какая часть кода среды выполнения или кода функции записывала данные в этот журнал. Категории в версии 1.x и более поздних версиях различаются.

Имена категорий назначаются по-разному в Функциях по сравнению с другими платформами .NET. Например, при использовании ILogger<T> в ASP.NET категория — это имя универсального типа. Функции C# также используются ILogger<T>, но вместо задания имени универсального типа в качестве категории среда выполнения назначает категории на основе источника. Например:

• Записи, связанные с выполнением функции, назначаются категории Function.<FUNCTION_NAME>.
• Записи, созданные пользовательским кодом в функции, например при вызове logger.LogInformation(), назначаются категории Function.<FUNCTION_NAME>.User.

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

Версия 2.x+

Категория	Таблицу	Description
Function	traces	Включает журналы, запущенные и завершенные функции для всех запусков функций. Успешные выполнения регистрируются в этих журналах на уровне Information. Исключения записываются на уровне Error. Кроме того, среда выполнения создает записи в журналах уровня Warning, например когда сообщения очереди отправляются в очередь подозрительных сообщений.
Function.<YOUR_FUNCTION_NAME>	dependencies	Данные зависимостей собираются для некоторых служб автоматически. Успешные выполнения регистрируются в этих журналах на уровне Information. Дополнительные сведения см. в разделе Зависимости. Исключения записываются на уровне Error. Кроме того, среда выполнения создает записи в журналах уровня Warning, например когда сообщения очереди отправляются в очередь подозрительных сообщений.
Function.<YOUR_FUNCTION_NAME>	customMetrics customEvents	Пакеты SDK для C# и JavaScript позволяют собирать пользовательские метрики и вести журналы пользовательских событий. Дополнительные сведения см. в разделе Настраиваемые данные телеметрии.
Function.<YOUR_FUNCTION_NAME>	traces	Включает записи о запущенных и завершенных функциях для их конкретных выполнений. Успешные выполнения регистрируются в этих журналах на уровне Information. Исключения записываются на уровне Error. Кроме того, среда выполнения создает записи в журналах уровня Warning, например когда сообщения очереди отправляются в очередь подозрительных сообщений.
Function.<YOUR_FUNCTION_NAME>.User	traces	Созданные пользователем записи в журналах (их уровень может быть любым). Дополнительные сведения о записи данных в журналы из функций см. в разделе Запись в журналы.
Host.Aggregator	customMetrics	Эти создаваемые во время выполнения записи в журналах содержат счетчики и средние значения по вызовам функций за настраиваемый период. По умолчанию используется период 30 секунд или 1000 результатов в зависимости от того, что из этого наступит раньше. Например, здесь вы найдете число запусков, долю успешных попыток и длительность выполнения. Все эти журналы записываются на Information уровне. Если вы фильтруете Warning по адресу или выше, вы не видите никаких этих данных.
Host.Results	requests	Эти создаваемые во время выполнения записи в журналах содержат сведения об успешном или неудачном выполнении функции. Все эти журналы записываются на Information уровне. Если вы фильтруете Warning по адресу или выше, вы не видите никаких этих данных.
Microsoft	traces	Полная категория журналов, отражающая компонент среды выполнения .NET, вызываемый узлом.
Worker	traces	Записи в журналах, создаваемые рабочим процессом языка для языков, не относящихся к .NET. Записи в журналах рабочих процессов языков также могут относиться к категории Microsoft.*, например Microsoft.Azure.WebJobs.Script.Workers.Rpc.RpcFunctionInvocationDispatcher. Эти журналы записываются на Information уровне.

Примечание.

Для функций библиотеки классов .NET в этих категориях предполагается, что вы используете ILogger, а не ILogger<T>. Дополнительные сведения см. в документации по ILogger функций.

v1.x

Категория	Таблицу	Description
Function	traces	Созданные пользователем записи в журналах (их уровень может быть любым). Дополнительные сведения о записи данных в журналы из функций см. в разделе Запись в журналы.
Host.Aggregator	customMetrics	Эти создаваемые во время выполнения записи в журналах содержат счетчики и средние значения по вызовам функций за настраиваемый период. По умолчанию используется период 30 секунд или 1000 результатов в зависимости от того, что из этого наступит раньше. Например, здесь вы найдете число запусков, долю успешных попыток и длительность выполнения. Все эти журналы записываются на уровне Information. Если вы фильтруете Warning по адресу или выше, вы не видите никаких этих данных.
Host.Executor	traces	Включает записи о запущенных и завершенных функциях для их конкретных выполнений. Успешные выполнения регистрируются в этих журналах на уровне Information. Исключения записываются на уровне Error. Среда выполнения также создает журналы на Warningуровне, например, когда сообщения очереди отправляются в очередь яда.
Host.Results	requests	Эти создаваемые во время выполнения записи в журналах содержат сведения об успешном или неудачном выполнении функции. Все эти журналы записываются на Information уровне. Если вы фильтруете Warning по адресу или выше, вы не видите никаких этих данных.

Столбец Table указывает, в какую таблицу Application Insights записывается журнал.

Настройка уровней ведения журнала

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

LogLevel	Код	Описание
Трассировка	0	Журналы, содержащие наиболее подробные сообщения. Эти сообщения могут содержать конфиденциальные данные приложения. Эти сообщения по умолчанию отключены, и их никогда не следует включать в рабочей среде.
Отладка	1	Журналы, используемые для интерактивного исследования во время разработки. Эти журналы в основном содержат сведения, полезные при отладки и не представляющие ценности в долгосрочной перспективе.
Информация	2	Журналы, отслеживающие общий поток работы приложения. Эти журналы должны быть полезны в долгосрочной перспективе.
Предупреждение	3	Журналы, которые выделяют ненормальное или неожиданное событие в потоке приложения, но не вызывают остановки выполнения приложения.
Ошибка	4	Журналы, которые выделяют, когда текущий поток выполнения остановлен из-за сбоя. Эти ошибки должны указывать на сбой в текущем действии, а не на сбой всего приложения.
Критически важно	5	Журналы, описывающие неустранимый сбой приложения или системы либо неустранимый сбой, который требует немедленного внимания.
нет	6	Отключает ведение журнала для указанной категории.

Конфигурация host.json файла определяет, сколько журналов приложение функций отправляет в Application Insights.

В каждой категории вы можете указать минимальный уровень ведения журнала для отправки данных. Параметры в файле host.json зависят от версии среды выполнения Функций.

Следующие примеры определяют ведение журнала на основе следующих правил:

• Уровень ведения журнала по умолчанию предназначен для Warning предотвращения чрезмерного ведения журнала для непреднамеренных категорий.
• Host.Aggregator и Host.Results устанавливаются на более низкие уровни. Установка слишком высоких уровней ведения журнала (особенно выше Information) может привести к потере метрик и данных о производительности.
• Для выполнения ведения журнала для выполнения функций задано значение Information. При необходимости можно переопределить этот параметр в локальной разработке Debug или Trace.

Версия 2.x+

{
  "logging": {
    "fileLoggingMode": "debugOnly",
    "logLevel": {
      "default": "Warning",
      "Host.Aggregator": "Trace",
      "Host.Results": "Information",
      "Function": "Information"
    }
  }
}

v1.x

{
  "logger": {
    "categoryFilter": {
      "defaultLevel": "Warning",
      "categoryLevels": {
        "Host.Results": "Information",
        "Host.Aggregator": "Trace",
        "Function": "Information"
      }
    }
  }
}

Если host.json содержит несколько журналов с одинаковым началом строки, поиск для сопоставления начинается с журналов с более полным определением. Рассмотрим следующий пример, в котором все события в среде выполнения, за исключением Host.Aggregator, регистрируются на уровне Error:

Версия 2.x+

{
  "logging": {
    "fileLoggingMode": "debugOnly",
    "logLevel": {
      "default": "Information",
      "Host": "Error",
      "Function": "Error",
      "Host.Aggregator": "Information"
    }
  }
}

v1.x

{
  "logger": {
    "categoryFilter": {
      "defaultLevel": "Information",
      "categoryLevels": {
        "Host": "Error",
        "Function": "Error",
        "Host.Aggregator": "Information"
      }
    }
  }
}

Запретить ведение журнала для определенной категории можно с помощью параметра уровня журнала None.

Внимание

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

Например, для предыдущих примеров:

• Если задать Host.Results категорию Error на уровне журнала, Azure собирает только события телеметрии выполнения узла в requests таблице для неудачных выполнений функций, предотвращая отображение сведений о выполнении узла успешных выполнений на вкладках Application Insights и монитора функций.
• Если вы установите Function категорию на Error уровне журнала, она перестает собирать данные телеметрии функции, связанные с dependencies, customMetricsи customEvents для всех функций, не позволяя просматривать какие-либо из этих данных в Application Insights. Azure собирает только traces зарегистрированные Error на уровне.

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

Настройка агрегатора

Как отмечалось в предыдущем разделе, среда выполнения собирает данные о выполнении функции за определенный период времени. По умолчанию используется период в 30 секунд или 1000 запусков в зависимости от того, что из этого наступит раньше. Этот параметр можно настроить в файле host.json. Например:

{
    "aggregator": {
      "batchSize": 1000,
      "flushTimeout": "00:00:30"
    }
}

Настройка выборки

В Application Insights есть функция выборки, которая позволяет избежать создания слишком большого объема данных телеметрии для завершенных выполнений в периоды пиковой нагрузки. Если скорость входящих выполнений превышает заданное пороговое значение, служба Application Insights будет случайным образом игнорировать часть входящих выполнений. Максимальное количество выполнений в секунду по умолчанию — 20 (пять в версии 1.x). Вы можете настроить выборку в файле host.json. Приведем пример:

Версия 2.x+

{
  "logging": {
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true,
        "maxTelemetryItemsPerSecond" : 20,
        "excludedTypes": "Request;Exception"
      }
    }
  }
}

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

v1.x

{
  "applicationInsights": {
    "sampling": {
      "isEnabled": true,
      "maxTelemetryItemsPerSecond" : 5
    }
  }
}

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

Включение сбора запросов SQL

Application Insights автоматически собирает данные о зависимостях для HTTP-запросов, вызовов баз данных и для нескольких привязок. Дополнительные сведения см. в разделе Зависимости. Для вызовов SQL имя сервера и базы данных всегда собирается и хранится, но текст SQL-запроса не собирается по умолчанию. Вы можете использовать dependencyTrackingOptions.enableSqlCommandTextInstrumentation для включения ведения журнала текста SQL-запроса с помощью следующих параметров (как минимум) в файле host.json:

"logging": {
    "applicationInsights": {
        "enableDependencyTracking": true,    
        "dependencyTrackingOptions": {
            "enableSqlCommandTextInstrumentation": true
        }
    }
}

Дополнительные сведения см. в статье "Расширенное отслеживание SQL", чтобы получить полный SQL-запрос.

Настройка журналов контроллера масштабирования

Эта функция предоставляется в предварительной версии.

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

Чтобы включить эту функцию, добавьте параметр приложения с именем SCALE_CONTROLLER_LOGGING_ENABLED в параметры приложения-функции. Следующее значение параметра должно быть в формате <DESTINATION>:<VERBOSITY>. Дополнительные сведения приведены в таблице ниже.

Свойство	Description
<DESTINATION>	Место назначения, в которое отправляются журналы. Допустимые значения — AppInsights и Blob. При использовании AppInsights убедитесь, что в приложении-функции включена функция Application Insights. Если для назначения задано значение Blob, то журналы создаются в контейнере больших двоичных объектов с именем azure-functions-scale-controller в учетной записи хранения по умолчанию, заданной в параметре AzureWebJobsStorage приложения.
<VERBOSITY>	Определяет уровень ведения журнала. Поддерживаются значения None, Warning и Verbose. Если задано значение Verbose, контроллер масштабирования регистрирует причину каждого изменения количества рабочих ролей, а также сведения о триггерах, которые влияют на эти решения. Подробные журналы содержат предупреждения триггеров и хэши, использованные триггерами до и после запуска контроллера масштабирования.

Совет

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

Например, следующая команда Azure CLI включает подробное журналирование из контроллера масштабирования в Application Insights:

az functionapp config appsettings set --name <FUNCTION_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--settings SCALE_CONTROLLER_LOGGING_ENABLED=AppInsights:Verbose

В этом примере замените <FUNCTION_APP_NAME> и <RESOURCE_GROUP_NAME> именем приложения-функции и именем группы ресурсов соответственно.

Следующая команда Azure CLI отключает журналирование, устанавливая уровень детализации None:

az functionapp config appsettings set --name <FUNCTION_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--settings SCALE_CONTROLLER_LOGGING_ENABLED=AppInsights:None

Отключить журналирование также можно, удалив параметр SCALE_CONTROLLER_LOGGING_ENABLED с помощью следующей команды Azure CLI:

az functionapp config appsettings delete --name <FUNCTION_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--setting-names SCALE_CONTROLLER_LOGGING_ENABLED

Если включено журналирование на контроллере масштабирования, можно отправлять запросы к журналам контроллера масштабирования.

Включение интеграции с Application Insights

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

Имя настройки	Description
APPLICATIONINSIGHTS_CONNECTION_STRING	Этот параметр рекомендуется и требуется, если экземпляр Application Insights работает в суверенном облаке. Строка подключения поддерживает другие новые возможности.
APPLICATIONINSIGHTS_AUTHENTICATION_STRING	Подключается к Application Insights с помощью проверки подлинности Microsoft Entra. Значение содержит идентификатор клиента, назначаемого системой или назначаемого пользователем управляемого удостоверения, которое разрешено публиковать данные телеметрии в рабочей области Application Insights. Строка имеет формат ClientId=<YOUR_CLIENT_ID>;Authorization=AAD. Дополнительные сведения см. в разделе проверки подлинности Microsoft Entra для Application Insights.
APPINSIGHTS_INSTRUMENTATIONKEY	Устаревший параметр, который Application Insights не рекомендуется использовать для параметра строка подключения.

При создании приложения-функции на портале Azure из командной строки с помощью Azure Functions Core Tools или в Visual Studio Code интеграция с Application Insights включена по умолчанию. Ресурс Application Insights имеет то же имя, что и приложение-функцию, и создается либо в одном регионе, либо в ближайшем регионе.

Примечание.

При использовании APPLICATIONINSIGHTS_AUTHENTICATION_STRING для подключения к Application Insights с помощью проверки подлинности Microsoft Entra необходимо также отключить локальную проверку подлинности для Application Insights. Эта конфигурация требует проверки подлинности Microsoft Entra для приема данных телеметрии в рабочую область.

Создание приложения-функции на портале Azure

Для проверки создаваемого ресурса Application Insights выберите его, чтобы развернуть окно Application Insights. Вы можете задать новое имя ресурса или выбрать другое расположение в географическом регионе Azure, где будут храниться данные.

При выборе команды Создать создается ресурс Application Insights с приложением-функцией, в параметрах приложения которого задано APPLICATIONINSIGHTS_CONNECTION_STRING. Все готово к работе.

Добавление имеющегося приложения-функции

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

1. На портале Azure найдите приложение-функцию и выберите его.

2. Щелкните баннер Application Insights не настроено в верхней части окна. Если вы не видите этот баннер, возможно, для приложения уже включено Application Insights.

   

3. Разверните пункт Изменить ресурс и создайте ресурс Application Insights с помощью параметров, указанных в следующей таблице:

   Параметр	Предлагаемое значение	Description
   Новое название ресурса	Уникальное имя приложения	Проще всего использовать имя приложения-функции, которое должно быть уникальным в вашей подписке.
   Местонахождение	Западная Европа	Если возможно, используйте регион приложения-функции или ближайший к нему.

   

4. Выберите Применить.

   Ресурс Application Insights создается в той же группе ресурсов и подписке, что и приложение-функция. После создания ресурса закройте окно Application Insights.

5. В приложении-функции разверните узел "Параметры" и выберите переменные среды. На вкладке "Параметры приложения", если вы видите параметр приложения с именем APPLICATIONINSIGHTS_CONNECTION_STRING, интеграция Application Insights включена для приложения-функции, работающего в Azure. Если этот параметр не существует, добавьте его с помощью строка подключения Application Insights в качестве значения.

Примечание.

Старые приложения-функции могут использовать APPINSIGHTS_INSTRUMENTATIONKEY вместо APPLICATIONINSIGHTS_CONNECTION_STRING. По возможности обновите приложение, чтобы использовать строка подключения вместо ключа инструментирования.

Отключение встроенного ведения журнала

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

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

Решения с большим объемом данных телеметрии

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

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

• Использование выборки: как упоминалось ранее, выборка помогает значительно сократить объем событий телеметрии, которые приема при сохранении статистически правильного анализа. Это может произойти, что даже при использовании выборки вы по-прежнему получаете большой объем телеметрии. Ознакомьтесь с параметрами, которые предоставляет адаптивная выборка. Например, задайте для maxTelemetryItemsPerSecond значение, которое сбалансирует объем создаваемых данных и ваши потребности мониторинга. Помните, что выборка телеметрии применяется для каждого узла, выполняющего приложение-функцию.

• Уровень журнала по умолчанию. Используйте Warning или Error в качестве значения по умолчанию для всех категорий телеметрии. Позже вы можете решить, какие категории необходимо задать на Information уровне, чтобы отслеживать и диагностировать функции должным образом.

• Настройте данные телеметрии функций: с заданным по умолчанию уровнем Error журнала или Warningне собираются подробные сведения из каждой функции (зависимости, пользовательские метрики, пользовательские события и трассировки). Для этих функций, которые являются ключевыми для мониторинга рабочей среды, определите явную запись для категории и задайте для нее Function.<YOUR_FUNCTION_NAME> Informationзначение, чтобы получить подробные сведения. Чтобы избежать сбора созданных пользователем журналов на Information уровне, задайте категорию Function.<YOUR_FUNCTION_NAME>.User на Error уровне или Warning уровень журнала.

• Категория Host.Aggregator. как описано в разделе Настройка категорий, эта категория предоставляет агрегированные сведения о вызовах функций. Сведения из этой категории собираются в таблице Application Insights customMetrics и отображаются на вкладке "Обзор функции" в портал Azure. В зависимости от того, как настроить агрегатор, рассмотрите возможность задержки, определяемой flushTimeout параметром, в собранных данных телеметрии. Если для этой категории задано значение, отличное от Informationзначения, вы перестаете собирать данные в customMetrics таблице и не отображать метрики на вкладке "Обзор функции".

  На приведенным ниже снимке экрана приведены данные телеметрии Host.Aggregator, отображаемые на вкладке Обзор функции:

  

  На следующем снимке экрана показаны данные телеметрии Host.Aggregator в таблице customMetrics в Application Insights:

  

• Категория Host.Results. Как описано в разделе Настройка категорий, эта категория предоставляет журналы, созданные средой выполнения, указывающие на успех или сбой вызова функции. Сведения из этой категории собираются в таблице Application Insights и отображаются на вкладке "Монитор функций" и на разных панелях мониторинга Application Insights requests (производительность, сбои и т. д.). Если для этой категории задано значение, отличное Informationот значения, вы собираете только данные телеметрии, созданные на определенном уровне журнала (или выше). Например, если задать значение error, будут отслеживаться только данные запросов для неудачных выполнений.

  На приведенным ниже снимке экрана приведены данные телеметрии Host.Results, отображаемые на вкладке Монитор функции:

  

  На приведенном ниже снимке экрана приведены данные телеметрии Host.Results, которые отображаются на панели мониторинга "Производительность" в Application Insights:

  

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

Версия 2.x+

{
  "version": "2.0",  
  "logging": {
    "logLevel": {
      "default": "Warning",
      "Function": "Error",
      "Host.Aggregator": "Error",
      "Host.Results": "Information", 
      "Function.Function1": "Information",
      "Function.Function1.User": "Error"
    },
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true,
        "maxTelemetryItemsPerSecond": 1,
        "excludedTypes": "Exception"
      }
    }
  }
} 

v1.x

{
  "logger": {
    "categoryFilter": {
      "defaultLevel": "Warning",
      "categoryLevels": {
        "Function": "Error",
        "Host.Aggregator": "Error",
        "Host.Results": "Information",
        "Host.Executor": "Warning"
      }
    }
  },
  "applicationInsights": {
    "sampling": {
      "isEnabled": true,
      "maxTelemetryItemsPerSecond" : 5
    }
  }
}

С этой конфигурацией:

• По умолчанию для всех категорий функций и телеметрии задано значение Warning (в том числе для категорий "Майкрософт" и "Рабочая роль"). Поэтому по умолчанию собираются все ошибки и предупреждения, созданные средой выполнения и настраиваемыми журналами.

• Для Function всех функций по умолчанию устанавливается Errorуровень журнала категорий, поэтому собираются только исключения и журналы ошибок. Пропускаются зависимости, метрики, созданные пользователем, и созданные пользователем события.

• Host.Aggregator Для категории, так как оно установлено Error на уровне журнала, агрегированные сведения из вызовов функций не собираются в customMetrics таблице Application Insights, а сведения о количествах выполнения (общее, успешное и неудачное) не отображаются на панели мониторинга обзора функций.

• Для категории Host.Results все сведения о выполнении узла собираются в таблице Application Insights requests. Все результаты вызовов отображаются на панели мониторинга функций и на панелях мониторинга Application Insights.

• Для вызываемой Function1функции мы задали уровень Informationжурнала. Поэтому для этой конкретной функции собираются все данные телеметрии (зависимости, пользовательские метрики и пользовательские события). Для той же функции мы устанавливаем Function1.User категорию (созданные пользователем трассировки), Errorпоэтому собирается только настраиваемое ведение журнала ошибок.

  Примечание.

  Конфигурация для каждой функции не поддерживается в среде выполнения Функций версии 1.x.

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

  Примечание.

  Счетчики метрик, например частота запросов и частота исключений, корректируются с учетом частоты выборки, так что в обозревателе метрик отображаются приблизительно точные значения.

Совет

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

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

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

Чтобы настроить эти значения на уровне параметров приложения (и избежать повторного развертывания только ради изменений в файле host.json), следует переопределить конкретные значения host.json, создав эквивалентное значение в качестве параметра приложения. Когда среда выполнения находит параметр приложения в формате AzureFunctionsJobHost__path__to__setting, она переопределяет эквивалентный параметр host.json, расположенный в path.to.setting в файле JSON. При выражении в качестве параметра приложения двойный символ подчеркивания () заменяет точку (__.), используемую для указания иерархии JSON. Например, можно использовать следующие параметры приложения для настройки отдельных уровней журналов функций в host.json.

Путь к файлу host.json	Параметр приложения
logging.logLevel.default	AzureFunctionsJobHost__logging__logLevel__default
logging.logLevel.Host.Aggregator	AzureFunctionsJobHost__logging__logLevel__Host__Aggregator
logging.logLevel.Function	AzureFunctionsJobHost__logging__logLevel__Function
logging.logLevel.Function.Function1	AzureFunctionsJobHost__logging__logLevel__Function__Function1
logging.logLevel.Function.Function1.User	AzureFunctionsJobHost__logging__logLevel__Function__Function1__User

Параметры можно переопределить непосредственно на панели Конфигурация приложений функции портал Azure или с помощью скрипта Azure CLI или PowerShell.

Azure CLI

az functionapp config appsettings set --name MyFunctionApp --resource-group MyResourceGroup --settings "AzureFunctionsJobHost__logging__logLevel__Host__Aggregator=Information"

PowerShell

Update-AzFunctionAppSetting -Name MyAppName -ResourceGroupName MyResourceGroupName -AppSetting @{"AzureFunctionsJobHost__logging__logLevel__Host__Aggregator" = "Information"}

Примечание.

Переопределение host.json путем изменения параметров приложения перезапустит приложение-функцию. Параметры приложения, содержащие период, не поддерживаются при запуске в Linux в плане Elastic Premium или выделенном (Служба приложений) плане. В этих средах размещения следует продолжать использовать файл host.json .

Мониторинг приложений-функций с помощью проверки работоспособности

Функцию проверки работоспособности можно использовать для мониторинга приложений-функций в планах "Премиум" (Elastic Premium) и "Выделенный" (Служба приложений). Проверка работоспособности не является вариантом плана потребления. Дополнительные сведения см. в статье Мониторинг экземпляров Службы приложений с помощью проверки работоспособности. Приложение-функция должна иметь функцию триггера HTTP, которая отвечает с кодом состояния HTTP 200 на той же конечной точке, что и для Path параметра проверки работоспособности. Вы также можете сделать так, чтобы эта функция выполняла дополнительные проверки, чтобы вы могли убедиться, что зависимые службы доступны и работают.

Связанный контент

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

• Мониторинг Функций Azure
• Анализ данных телеметрии Функций Azure в Application Insights
• Общие сведения об Application Insights