Настройка мониторинга для Функций 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.

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

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

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

Языковой стек Настройка пользовательских журналов
.NET (модель в процессе) host.json
.NET (изолированная модель) По умолчанию: host.json
Параметр отправки журналов напрямую: настройка приложения Аналитика в HostBuilder
Node.JS host.json
Python host.json
Java По умолчанию: host.json
Параметр отправки журналов напрямую: настройка агента Java для приложения Аналитика
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.

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

Категория Таблицу 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 функций.

Столбец 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при необходимости.
{
  "logging": {
    "fileLoggingMode": "debugOnly",
    "logLevel": {
      "default": "Warning",
      "Host.Aggregator": "Trace",
      "Host.Results": "Information",
      "Function": "Information"
    }
  }
}

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

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

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

Внимание

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

Из приведенных выше примеров:

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

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

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

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

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

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

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

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

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

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

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

Приложение Аналитика автоматически собирает данные о зависимостях для 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 Аналитика, используя только один из следующих параметров приложения:

Имя настройки Description
APPLICATIONINSIGHTS_CONNECTION_STRING Это рекомендуемый параметр, который требуется при запуске экземпляра Приложения Аналитика в суверенном облаке. Строка подключения поддерживает другие новые возможности.
APPINSIGHTS_INSTRUMENTATIONKEY Устаревший параметр, который устарел приложением Аналитика в пользу параметра строка подключения.

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

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

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

Screenshot of enabling Application Insights while creating a function app.

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

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

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

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

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

    Screenshot of enabling Application Insights from the portal.

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

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

    Screenshot of creating an Application Insights resource.

  4. Нажмите Применить.

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

  5. В приложении-функции выберите Конфигурация в разделе Параметры и выберите Параметры приложения. Если появится параметр APPLICATIONINSIGHTS_CONNECTION_STRING, это означает, что для приложения-функции в 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, отображаемые на вкладке Обзор функции:

    Screenshot of Host.Aggregator telemetry displayed in function Overview tab.

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

    Screenshot of Host.Aggregator telemetry in customMetrics Application Insights table.

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

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

    Screenshot of Host.Results telemetry in function Monitor tab.

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

    Screenshot of Host.Results telemetry in Application Insights Performance dashboard.

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

{
  "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"
      }
    }
  }
}

При использовании этой конфигурации:

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

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

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

  • Для категории 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.

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

Примечание.

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

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

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

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

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