Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье показано, как настроить функциональное приложение для экспорта лог-файлов и данных трассировки в формате OpenTelemetry. Функции Azure генерирует данные телеметрии ваших выполнения функций как из процесса узла Functions, так и из языково-специфического рабочего процесса, в котором выполняется код функции. По умолчанию эти данные телеметрии отправляются в Application Insights с помощью пакета SDK Application Insights. Однако вы можете экспортировать эти данные с помощью семантики OpenTelemetry. Хотя вы по-прежнему можете использовать формат OpenTelemetry для отправки данных в Application Insights, теперь можно экспортировать те же данные в любую другую конечную точку, совместимую с OpenTelemetry.
Эти преимущества можно получить, включив OpenTelemetry в приложении-функции:
- Сопоставляет данные между трассировками и журналами, создаваемыми как на узле, так и в коде приложения.
- Обеспечивает согласованное создание экспортируемых данных телеметрии на основе стандартов.
- Интегрируется с другими поставщиками, которые могут использовать данные, совместимые с OpenTelemetry.
При использовании этой статьи следует учитывать следующие рекомендации.
- Ознакомьтесь с руководством по OpenTelemetry, который поможет вам быстро приступить к работе с OpenTelemetry и Функции Azure. В этой статье используется интерфейс командной строки разработчика Azure (
azd) для создания и развертывания приложения-функции, использующего интеграцию OpenTelemetry для распределенной трассировки.
- Так как эта статья ориентирована на выбранный язык разработки, не забудьте выбрать правильный язык в верхней части статьи.
- В настоящее время OpenTelemetry не поддерживается для приложений внутрипроцессного процесса C#.
- OpenTelemetry включен на уровне функционального приложения, как в конфигурации узла (
host.json), так и в проекте кода. Функции также предоставляют оптимизированный клиентский опыт для экспорта данных OpenTelemetry из кода функции, выполняющегося в рабочем процессе, зависящем от языка.
Включение OpenTelemetry в узле функций
Если вы включите вывод данных OpenTelemetry в файле host.json приложения-функции, ваш хост экспортирует выходные данные OpenTelemetry независимо от используемого приложением языкового стека.
Чтобы включить вывод OpenTelemetry из хоста функций, обновите файл host.json в вашем проекте, чтобы добавить элемент в корневую "telemetryMode": "OpenTelemetry" коллекцию. С включенной функцией OpenTelemetry файл host.json может выглядеть следующим образом:
{
"version": "2.0",
"telemetryMode": "OpenTelemetry",
...
}
Настройка параметров приложения
При включении OpenTelemetry в host.json файле переменные среды приложения определяют конечные точки для отправки данных на основе параметров приложения, поддерживаемых OpenTelemetry.
Создайте определенные параметры функции в вашем приложении на основе назначения выходных данных OpenTelemetry. При предоставлении параметров подключения как для Application Insights, так и для экспортера протокола OpenTelemetry (OTLP) данные OpenTelemetry отправляются в обе конечные точки.
APPLICATIONINSIGHTS_CONNECTION_STRING: строка подключения для рабочей области Application Insights. Если этот параметр существует, данные OpenTelemetry отправляются в эту рабочую область. Используйте тот же параметр для подключения к Application Insights без включения OpenTelemetry. Если у приложения еще нет этого параметра, может потребоваться включить интеграцию Application Insights.
JAVA_APPLICATIONINSIGHTS_ENABLE_TELEMETRY: установите значение true, чтобы узел функций позволял Java-процессу передавать журналы OpenTelemetry напрямую, что предотвращает дублирование записей на уровне хоста.
PYTHON_APPLICATIONINSIGHTS_ENABLE_TELEMETRY: установите значение true, чтобы узел функций позволил Python рабочему процессу передавать журналы OpenTelemetry напрямую, что предотвращает дублирование записей на уровне узла.
Для приложений Go этот параметр настраивает экспорт OpenTelemetry из узла функций в Application Insights. Он не настраивает ПО промежуточного слоя OpenTelemetry для рабочей роли Go, которое экспортирует данные телеметрии рабочей роли с помощью параметров OTLP. Чтобы отправить рабочую телеметрию Go в Application Insights, перенаправите выходные данные OTLP через сборщик OpenTelemetry или другой конвейер OpenTelemetry, настроенный для экспорта в Azure Monitor.
Включение OpenTelemetry в приложении
После настройки узла Функций для использования OpenTelemetry обновите код приложения до вывода данных OpenTelemetry. Если включить OpenTelemetry как в хосте, так и в коде приложения, вы получите лучшую корреляцию между трейсами и журналами, которые процесс хоста функций и процесс рабочего языка программирования выдают.
Настройка вашего приложения для использования OpenTelemetry зависит от целевой конечной точки OpenTelemetry.
Примеры в этой статье предполагают, что приложение использует IHostApplicationBuilder, доступное в версии 2.x и более поздней версии Microsoft.Azure. Functions.Worker. Дополнительные сведения см. в руководстве по изолированной рабочей модели C# версии 2.x .
Выполните следующие команды, чтобы установить необходимые сборки в приложении:
Замечание
Начиная с версии 3.0, пакет
Microsoft.ApplicationInsights.WorkerServiceиспользует Azure Monitor Exporter. Этот пакет можно использовать для поддержания существующего поведения конфигурации Application Insights во время внутреннего использования конвейера Azure Monitor, включая экспортер OpenTelemetry. ПакетMicrosoft.ApplicationInsights.WorkerService(версии 3.0 или более поздней версии) можно использовать вместо пакетаAzure.Monitor.OpenTelemetry.Exporter, который показан в следующем примере.dotnet add package Microsoft.Azure.Functions.Worker.OpenTelemetry dotnet add package OpenTelemetry.Extensions.Hosting dotnet add package Azure.Monitor.OpenTelemetry.ExporterДобавьте в файл проекта Program.cs следующую
usingинструкцию:using Azure.Monitor.OpenTelemetry.Exporter;Настройте OpenTelemetry в зависимости от того, какой запуск проекта используется:
IHostBuilderилиIHostApplicationBuilder. Последний был представлен в версии 2.x расширения изолированной рабочей модели .NET.В program.cs добавьте эту строку кода после
ConfigureFunctionsWebApplication:builder.Services.AddOpenTelemetry() .UseFunctionsWorkerDefaults() .UseAzureMonitorExporter();Вы можете экспортировать данные на оба конечных пункта OpenTelemetry из одного приложения.
Добавьте необходимые библиотеки в приложение. Способ добавления библиотек зависит от того, развертываете ли вы с помощью Maven или Kotlin и хотите также отправлять данные в Application Insights.
<dependency> <groupId>com.microsoft.azure.functions</groupId> <artifactId>azure-functions-java-opentelemetry</artifactId> <version>1.0.0</version> </dependency> <dependency> <groupId>com.azure</groupId> <artifactId>azure-monitor-opentelemetry-autoconfigure</artifactId> <version>1.2.0</version> </dependency>(Необязательно) Добавьте этот код для создания пользовательских диапазонов:
import com.microsoft.azure.functions.opentelemetry.FunctionsOpenTelemetry; import io.opentelemetry.api.trace.Span; import io.opentelemetry.api.trace.SpanKind; import io.opentelemetry.context.Scope; Span span = FunctionsOpenTelemetry.startSpan( "com.contoso.PaymentFunction", // tracer name "validateCharge", // span name null, // parent = current context SpanKind.INTERNAL); try (Scope ignored = span.makeCurrent()) { // business logic here } finally { span.end(); }
Установите эти пакеты npm в проекте:
npm install @opentelemetry/api npm install @opentelemetry/auto-instrumentations-node npm install @azure/monitor-opentelemetry-exporter npm install @azure/functions-opentelemetry-instrumentation
Создайте файл кода в проекте, скопируйте и вставьте следующий код в этот новый файл и сохраните его следующим образом
src/index.js:const { AzureFunctionsInstrumentation } = require('@azure/functions-opentelemetry-instrumentation'); const { AzureMonitorLogExporter, AzureMonitorTraceExporter } = require('@azure/monitor-opentelemetry-exporter'); const { getNodeAutoInstrumentations, getResourceDetectors } = require('@opentelemetry/auto-instrumentations-node'); const { registerInstrumentations } = require('@opentelemetry/instrumentation'); const { detectResourcesSync } = require('@opentelemetry/resources'); const { LoggerProvider, SimpleLogRecordProcessor } = require('@opentelemetry/sdk-logs'); const { NodeTracerProvider, SimpleSpanProcessor } = require('@opentelemetry/sdk-trace-node'); const resource = detectResourcesSync({ detectors: getResourceDetectors() }); const tracerProvider = new NodeTracerProvider({ resource }); tracerProvider.addSpanProcessor(new SimpleSpanProcessor(new AzureMonitorTraceExporter())); tracerProvider.register(); const loggerProvider = new LoggerProvider({ resource }); loggerProvider.addLogRecordProcessor(new SimpleLogRecordProcessor(new AzureMonitorLogExporter())); registerInstrumentations({ tracerProvider, loggerProvider, instrumentations: [getNodeAutoInstrumentations(), new AzureFunctionsInstrumentation()], });Обновите поле
mainв файле package.json, чтобы включить новый файлsrc/index.js. Рассмотрим пример."main": "src/{index.js,functions/*.js}"
Создайте файл кода в проекте, скопируйте и вставьте следующий код в этот новый файл и сохраните его следующим образом
src/index.ts:import { AzureFunctionsInstrumentation } from '@azure/functions-opentelemetry-instrumentation'; import { AzureMonitorLogExporter, AzureMonitorTraceExporter } from '@azure/monitor-opentelemetry-exporter'; import { getNodeAutoInstrumentations, getResourceDetectors } from '@opentelemetry/auto-instrumentations-node'; import { registerInstrumentations } from '@opentelemetry/instrumentation'; import { detectResourcesSync } from '@opentelemetry/resources'; import { LoggerProvider, SimpleLogRecordProcessor } from '@opentelemetry/sdk-logs'; import { NodeTracerProvider, SimpleSpanProcessor } from '@opentelemetry/sdk-trace-node'; const resource = detectResourcesSync({ detectors: getResourceDetectors() }); const tracerProvider = new NodeTracerProvider({ resource }); tracerProvider.addSpanProcessor(new SimpleSpanProcessor(new AzureMonitorTraceExporter())); tracerProvider.register(); const loggerProvider = new LoggerProvider({ resource }); loggerProvider.addLogRecordProcessor(new SimpleLogRecordProcessor(new AzureMonitorLogExporter())); registerInstrumentations({ tracerProvider, loggerProvider, instrumentations: [getNodeAutoInstrumentations(), new AzureFunctionsInstrumentation()], });Обновите поле
mainв вашем файле package.json, чтобы включить данные вывода нового файлаsrc/index.ts, которые могут выглядеть примерно так:"main": "dist/src/{index.js,functions/*.js}"
Внимание
В настоящее время выход OpenTelemetry в Application Insights из рабочего процесса не поддерживается для приложений PowerShell. Вместо этого можно использовать конечную точку экспортера OTLP. При настройке узла для выходных данных OpenTelemetry в Application Insights журналы, созданные рабочим процессом PowerShell, по-прежнему перенаправляются, но распределенная трассировка в настоящее время не поддерживается.
Эти инструкции применяются только для экспортера OTLP:
Добавьте параметр приложения с именем
OTEL_FUNCTIONS_WORKER_ENABLEDсо значениемTrue.Создайте папку уровня приложения
Modulesи выполните следующую команду:Save-Module -Name AzureFunctions.PowerShell.OpenTelemetry.SDKЭта команда устанавливает необходимый
AzureFunctions.PowerShell.OpenTelemetry.SDKмодуль непосредственно в приложении.requirements.psd1Невозможно использовать файл для автоматической установки этой зависимости, поскольку в предварительной версии плана Flex Consumption не поддерживаются управляемые зависимости.Добавьте этот код в файл profile.ps1:
Import-Module AzureFunctions.PowerShell.OpenTelemetry.SDK -Force -ErrorAction Stop Initialize-FunctionsOpenTelemetry
Убедитесь, что эти библиотеки присутствуют в файле
requirements.txt, путем снятия комментариев или добавления их вручную.azure-monitor-opentelemetryДобавьте этот код в
function_app.pyфайл основной точки входа:Если вы уже добавили
PYTHON_APPLICATIONINSIGHTS_ENABLE_TELEMETRY=trueв параметры приложения, этот шаг можно пропустить. Чтобы вручную включить коллекцию Application Insights без автоматического инструментирования, добавьте этот код в приложение:from azure.monitor.opentelemetry import configure_azure_monitor configure_azure_monitor()Ознакомьтесь с документацией по использованию Azure Monitor Distro, чтобы узнать варианты дальнейшей настройки SDK.
Для приложений Go для любого назначения OpenTelemetry используется та же рабочая настройка. Промежуточное ПО экспортирует данные телеметрии рабочего процесса, используя параметры OTLP. Конечная точка OTLP может быть конечной точкой поставщика или сборщиком OpenTelemetry, который пересылает данные телеметрии в другое место назначения, например Azure Monitor.
Убедитесь, что проект использует версию рабочего пакета SDK Go, включающую ПО промежуточного слоя OpenTelemetry:
go get github.com/azure/azure-functions-golang-worker@latest go mod tidyВ файле
main.goимпортируйте промежуточное ПО OpenTelemetry и зарегистрируйте его, прежде чем регистрировать функции:package main import ( "fmt" "log/slog" "net/http" "github.com/azure/azure-functions-golang-worker/middleware/otelfunc" "github.com/azure/azure-functions-golang-worker/sdk" "github.com/azure/azure-functions-golang-worker/worker" ) func hello(w http.ResponseWriter, r *http.Request) { slog.InfoContext(r.Context(), "processing request", "path", r.URL.Path) fmt.Fprintln(w, "hello") } func main() { app := sdk.FunctionApp() app.Use(otelfunc.Middleware()) app.HTTP("hello", hello, sdk.WithMethods("GET"), sdk.WithAuth("anonymous"), ) worker.Start(app) }
Промежуточное ПО без аргументов использует стандартные параметры приложения OTEL_EXPORTER_OTLP_*, которые вы настроили ранее в этой статье. Он создает интервалы трассировки вызовов, сопоставляет записи slog, создаваемые во время вызова, с контекстом вызова и сбрасывает телеметрические данные после каждого вызова.
Чтобы создать настраиваемые дочерние диапазоны, используйте стандартные API OpenTelemetry Go с контекстом вызова. Для триггеров HTTP используйте r.Context() в качестве родительского контекста. Для других типов триггеров используйте параметр context.Context, передаваемый вашему обработчику.
Рекомендации по OpenTelemetry
При экспорте данных с помощью OpenTelemetry следует учитывать эти рекомендации.
Портал Azure поддерживает трассировки
Recent function invocationтолько в случае, если телеметрия отправляется в Azure Monitor.При настройке узла для использования OpenTelemetry портал Azure не поддерживает потоковую передачу журналов.
Если задано значение
telemetryModeOpenTelemetry, конфигурация вlogging.applicationInsightsразделе host.json не применяется.
Пользовательские диапазоны автоматически включают все атрибуты ресурсов и используют экспортеры, настроенные в приложении.
Когда приложение выполняется вне Azure, в том числе во время локальной разработки, детектор ресурсов по умолчанию задает атрибут
service.nameнаjava-function-app.Используйте эти флаги Java виртуальной машины (JVM), чтобы подавить телеметрию при локальном запуске во время модульных тестов.
-Dotel.traces.exporter=none-Dotel.metrics.exporter=none-Dotel.logs.exporter=none
- Вам не нужно вручную регистрировать промежуточное ПО; Java рабочие автоматического обнаружения
OpenTelemetryInvocationMiddleware.
Используйте методы с учетом контекста из стандартного
log/slogпакета, напримерslog.InfoContextиslog.ErrorContextдля сопоставления структурированных журналов с текущим вызовом и трассировкой.Промежуточный слой OpenTelemetry для воркера Go подключается опционально. Приложения, которые не импортируют и не регистрируют
middleware/otelfunc, не включают пакеты OpenTelemetry в скомпилированный двоичный файл.Чтобы временно отключить промежуточное ПО воркера Go без повторного развертывания приложения, установите для
AZURE_FUNCTIONS_WORKER_OPENTELEMETRY_DISABLEDзначениеtrue.Для расширенной настройки можно в коде настроить пользовательские провайдеры OpenTelemetry, экспортеры, атрибуты ресурсов и пропагаторы перед регистрацией промежуточного ПО.
Детекторы ресурсов и семантические соглашения
В Функции Azure атрибуты ресурсов описывают процесс приложения-функции и ее среду. Атрибуты диапазона описывают один вызов.
Поведение по умолчанию (не требуется никаких действий)
В Функции Azure в службе приложений детекторы ресурсов обычно заполняют общие атрибуты автоматически, включая:
-
service.name(по умолчанию используется имя приложения-функции) - Azure облачные атрибуты, такие как
cloud.provider,cloud.regionиcloud.resource_id
В большинстве случаев эти значения по умолчанию являются достаточными для правильной группировки карты приложений и контекста Azure.
Когда следует переопределять service.name (имя облачной роли)
Переопределите только в том случае, если требуется другое, стабильное имя узла в Application Insights (группирование карт приложений), например для нормализации именования между слотами или средами.
Задайте OTEL_SERVICE_NAME для переопределения обнаруженного значения:
export OTEL_SERVICE_NAME="my-function-app"
Атрибуты диапазона вызовов (обычно автоматически)
Если вы не создаете пользовательский диапазон вызовов, вам не придется устанавливать их вручную.
-
faas.name(имя функции) -
faas.trigger(напримерhttp, ,servicebuseventhubs) -
faas.execution(идентификатор вызова или выполнения)
Внимание
Приложения-функции могут размещать несколько функций в одном процессе. Не помещайте значения, связанные с функцией, на ресурс. Размещайте идентификаторы для каждого вызова в спанах.
Замечание
При локальном запуске (функции core Tools) или в контейнерных или локальных средах, где Azure метаданные недоступны, service.name может по умолчанию использовать универсальное значение. Установите OTEL_SERVICE_NAME локально, чтобы соответствовать именам в производственной среде.
Устранение неполадок
При экспорте данных с помощью OpenTelemetry следует учитывать эти распространенные проблемы и решения.
Фильтрация журналов
Чтобы правильно настроить фильтрацию журналов в функциональном приложении, необходимо понять разницу между процессом хоста и процессом обработчика.
Процесс host — это среда выполнения Функции Azure, которая управляет триггерами, масштабированием и выдает данные телеметрии уровня системы, такие как журналы инициализации, трассировки запросов и сведения о работоспособности среды выполнения.
Рабочий процесс зависит от языка, выполняет код вашей функции и независимо создает журналы приложений и телеметрию.
Внимание
Фильтры, определенные в host.json применяются только к журналам, созданным процессом узла. Для фильтрации журналов из рабочего процесса необходимо использовать параметры OpenTelemetry, относящиеся к языку.
Пример. Фильтрация журналов узлов для всех поставщиков в host.json
Используйте этот подход, чтобы задать глобальный уровень журнала для всех поставщиков, управляемых узлом:
{
"version": "2.0",
"telemetryMode": "OpenTelemetry",
"logging": {
"logLevel": {
"default": "Warning"
}
}
}
Пример. Фильтрация журналов только для поставщика средства ведения журнала OpenTelemetry
Используйте этот подход, чтобы нацелиться только на поставщика логгера OpenTelemetry, оставляя других поставщиков, таких как консольное или файловое логирование, нетронутыми.
{
"version": "2.0",
"telemetryMode": "OpenTelemetry",
"logging": {
"OpenTelemetry": {
"logLevel": {
"default": "Warning"
}
}
}
}
Логирование консоли
Хост функций автоматически захватывает все записи в stdout или stderr и пересылает их в конвейер телеметрии. Если вы также используете ConsoleExporter или записываете данные непосредственно в консоль в коде, в данных телеметрии могут возникать дублирующиеся записи.
Замечание
Чтобы избежать дублирования записей телеметрии, не добавляйте ConsoleExporter и не записывайте в консоль в производственном коде.
проверка подлинности Microsoft Entra
При использовании проверки подлинности Microsoft Entra с OpenTelemetry необходимо настроить проверку подлинности отдельно для хост-процесса и рабочего процесса.
Сведения о настройке проверки подлинности для процесса узла см. в статье Require Microsoft Entra authentication.
Сведения о настройке проверки подлинности для рабочего процесса см. в статье Enable Microsoft Entra authentication.
Поддержка атрибутов ресурсов
Поддержка атрибутов ресурсов в Azure Monitor сейчас доступна в предварительной версии. Чтобы включить эту функцию, задайте для переменной OTEL_DOTNET_AZURE_MONITOR_ENABLE_RESOURCE_METRICS среды значение true. Этот параметр возвращает атрибуты ресурсов в настраиваемую таблицу метрик.
Повторяющаяся телеметрия запроса
Процесс узла автоматически выдает данные телеметрии запроса. Если рабочий процесс также инструментирован с помощью библиотек отслеживания запросов (например, AspNetCoreInstrumentation в .NET), один и тот же запрос сообщается дважды.
Замечание
Поскольку дистрибутив Azure Monitor обычно включает AspNetCoreInstrumentation в .NET и аналогичный инструментарий для других языков, избегайте использования дистрибутива Azure Monitor в рабочем процессе, чтобы предотвратить дублирование телеметрии.
Области ведения журнала не включены
По умолчанию рабочий процесс не включает области в журналы. Чтобы включить права доступа, необходимо явно задать этот параметр в рабочем процессе. В следующем примере показано, как включить области в изолированном режиме .NET:
builder.Logging.AddOpenTelemetry(b => b.IncludeScopes = true);
Отсутствующие данные телеметрии запроса
Триггеры, такие как HTTP, служебная шина и Центры событий, зависят от распространения контекста для распределенной трассировки. При выборке на основе родителей в качестве поведения по умолчанию данные телеметрии запросов не создаются, когда входящий запрос или сообщение не подвергается выборке.
Повторяющийся идентификатор операции
В Функции Azure значение OperationId, используемое для корреляции телеметрии, поступает непосредственно из значения traceparent в входящего запроса или сообщения. Если несколько вызовов используют одно и то же traceparent значение повторно, все они получают одинаковые OperationId.
Настройка OpenTelemetry с переменными среды
Поведение OpenTelemetry можно настроить с помощью стандартных переменных среды. Эти переменные обеспечивают согласованный способ управления поведением на разных языках и средах выполнения. Вы можете настроить стратегии выборки, параметры экспортера и атрибуты ресурсов. Дополнительные сведения о поддерживаемых переменных среды см. в документации по OpenTelemetry.
Использование диагностики для устранения неполадок мониторинга
Диагностика Функции Azure на портале Azure является полезным ресурсом для обнаружения и диагностики потенциальных проблем, связанных с мониторингом.
Чтобы получить доступ к диагностике в приложении, выполните приведенные далее действия.
В портале Azure откройте ресурс вашего приложения функции.
На левой панели выберите "Диагностика и устранение проблем" и найдите приложение-функцию, отсутствующее в приложении телеметрии Application Insights или рабочем процессе OpenTelemetry .
Выберите этот рабочий процесс, выберите метод приема и нажмите кнопку "Далее".
Ознакомьтесь с инструкциями и рекомендациями, предоставленными средством устранения неполадок.
Дальнейшие шаги
Дополнительные сведения о OpenTelemetry и мониторинге Функции Azure: