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

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

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

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

В средстве ведения журнала Функций 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.

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

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

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

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

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

Для проверки создаваемого ресурса 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 в качестве значения.

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

{
  "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 (в том числе для категорий "Майкрософт" и "Рабочая роль"). Поэтому по умолчанию собираются все ошибки и предупреждения, созданные средой выполнения и настраиваемыми журналами.

• Для 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.

Параметры можно переопределить непосредственно на панели Конфигурация приложений функции портал 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) и "Выделенный" (Служба приложений). Проверка работоспособности не является вариантом плана потребления. Дополнительные сведения см. в статье Мониторинг экземпляров Службы приложений с помощью проверки работоспособности. Приложение-функция должна иметь функцию триггера HTTP, которая отвечает с кодом состояния HTTP 200 на той же конечной точке, что и для Path параметра проверки работоспособности. Вы также можете сделать так, чтобы эта функция выполняла дополнительные проверки, чтобы вы могли убедиться, что зависимые службы доступны и работают.

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

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