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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Конфигурация 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"
    }
  }
}

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

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

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

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

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

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

Как отмечалось в предыдущем разделе, среда выполнения собирает данные о выполнении функции за определенный период времени. По умолчанию используется период в 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"
      }
    }
  }
}

{
  "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>. Дополнительные сведения приведены в таблице ниже.

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

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

Требовать аутентификацию с помощью Microsoft Entra

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

Значение содержит Authorization=AAD управляемое удостоверение, назначаемое системой, или ClientId=<YOUR_CLIENT_ID>;Authorization=AAD управляемое удостоверение, назначаемое пользователем. Управляемое удостоверение уже должно быть доступно функции-приложению с назначенной ролью, эквивалентной Monitoring Metrics Publisher. Дополнительные сведения см. в разделе аутентификация Microsoft Entra для Application Insights.

Параметр APPLICATIONINSIGHTS_CONNECTION_STRING по-прежнему требуется.

Новое приложение-функция на портале

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

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

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

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

1. В портале Azure найдите и выберите Function App, а затем выберите ваше приложение-функцию.

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

   

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

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

   

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  

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

  

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

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

  

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

  

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

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

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

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

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

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

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

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

az functionapp config appsettings set --name MyFunctionApp --resource-group MyResourceGroup --settings "AzureFunctionsJobHost__logging__logLevel__Host.Aggregator=Information"

Update-AzFunctionAppSetting -Name MyAppName -ResourceGroupName MyResourceGroupName -AppSetting @{"AzureFunctionsJobHost__logging__logLevel__Host.Aggregator" = "Information"}

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

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

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

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

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