Бөлісу құралы:


Использование OpenTelemetry с Функции Azure

В этой статье показано, как настроить функциональное приложение для экспорта лог-файлов и данных трассировки в формате OpenTelemetry. Функции Azure генерирует данные телеметрии ваших выполнения функций как из процесса узла Functions, так и из языково-специфического рабочего процесса, в котором выполняется код функции. По умолчанию эти данные телеметрии отправляются в Application Insights с помощью пакета SDK Application Insights. Однако вы можете экспортировать эти данные с помощью семантики OpenTelemetry. Хотя вы по-прежнему можете использовать формат OpenTelemetry для отправки данных в Application Insights, теперь можно экспортировать те же данные в любую другую конечную точку, совместимую с OpenTelemetry.

Эти преимущества можно получить, включив OpenTelemetry в приложении-функции:

  • Сопоставляет данные между трассировками и журналами, создаваемыми как на узле, так и в коде приложения.
  • Обеспечивает согласованное создание экспортируемых данных телеметрии на основе стандартов.
  • Интегрируется с другими поставщиками, которые могут использовать данные, совместимые с OpenTelemetry.

При использовании этой статьи следует учитывать следующие рекомендации.

  • Ознакомьтесь с руководством по OpenTelemetry, который поможет вам быстро приступить к работе с OpenTelemetry и Функции Azure. В этой статье используется интерфейс командной строки разработчика Azure (azd) для создания и развертывания приложения-функции, использующего интеграцию OpenTelemetry для распределенной трассировки.

  • Так как эта статья ориентирована на выбранный язык разработки, не забудьте выбрать правильный язык в верхней части статьи.

  • 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 напрямую, что предотвращает дублирование записей на уровне узла.

Включение OpenTelemetry в приложении

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

Настройка вашего приложения для использования OpenTelemetry зависит от целевой конечной точки OpenTelemetry.

Примеры в этой статье предполагают, что приложение использует IHostApplicationBuilder, доступное в версии 2.x и более поздней версии Майкрософт.Azure. Functions.Worker. Дополнительные сведения см. в руководстве по изолированной рабочей модели C# версии 2.x .

  1. Выполните следующие команды, чтобы установить необходимые сборки в приложении:

    Замечание

    Начиная с версии 3.0, пакет Майкрософт.ApplicationInsights.WorkerService использует Azure Monitor Exporter. Этот пакет можно использовать для поддержания существующего поведения конфигурации Application Insights во время внутреннего использования конвейера Azure Monitor, включая экспортер OpenTelemetry. Пакет Майкрософт.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  
    
  2. Добавьте в файл проекта Program.cs следующую using инструкцию:

    using Azure.Monitor.OpenTelemetry.Exporter; 
    
  3. Настройте OpenTelemetry в зависимости от того, какой запуск проекта используется: IHostBuilder или IHostApplicationBuilder. Последний был представлен в версии 2.x расширения изолированной рабочей модели .NET.

    В program.cs добавьте эту строку кода после ConfigureFunctionsWebApplication:

    builder.Services.AddOpenTelemetry()
        .UseFunctionsWorkerDefaults()
        .UseAzureMonitorExporter();
    

    Вы можете экспортировать данные на оба конечных пункта OpenTelemetry из одного приложения.

  1. Добавьте необходимые библиотеки в приложение. Способ добавления библиотек зависит от того, развертываете ли вы с помощью 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>
    
  2. (Необязательно) Добавьте этот код для создания пользовательских диапазонов:

    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();
    }
    
  1. Установите эти пакеты npm в проекте:

    npm install @opentelemetry/api 
    npm install @opentelemetry/auto-instrumentations-node 
    npm install @azure/monitor-opentelemetry-exporter 
    npm install @azure/functions-opentelemetry-instrumentation
    
  1. Создайте файл кода в проекте, скопируйте и вставьте следующий код в этот новый файл и сохраните его следующим образом 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()],
    });
    
  2. Обновите поле main в файле package.json, чтобы включить новый файл src/index.js. Рассмотрим пример.

    "main": "src/{index.js,functions/*.js}"
    
  1. Создайте файл кода в проекте, скопируйте и вставьте следующий код в этот новый файл и сохраните его следующим образом 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()],
    });
    
  2. Обновите поле main в вашем файле package.json, чтобы включить данные вывода нового файла src/index.ts, которые могут выглядеть примерно так:

    "main": "dist/src/{index.js,functions/*.js}"
    

Внимание

В настоящее время выход OpenTelemetry в Application Insights из рабочего процесса не поддерживается для приложений PowerShell. Вместо этого можно использовать конечную точку экспортера OTLP. При настройке узла для выходных данных OpenTelemetry в Application Insights журналы, созданные рабочим процессом PowerShell, по-прежнему перенаправляются, но распределенная трассировка в настоящее время не поддерживается.

Эти инструкции применяются только для экспортера OTLP:

  1. Добавьте параметр приложения с именем OTEL_FUNCTIONS_WORKER_ENABLED со значением True.

  2. Создайте папку уровня приложения в корне вашего приложения и выполните следующую команду:

    Save-Module -Name AzureFunctions.PowerShell.OpenTelemetry.SDK
    

    Эта команда устанавливает необходимый AzureFunctions.PowerShell.OpenTelemetry.SDK модуль непосредственно в приложении. requirements.psd1 Невозможно использовать файл для автоматической установки этой зависимости, поскольку в предварительной версии плана Flex Consumption не поддерживаются управляемые зависимости.

  3. Добавьте этот код в файл profile.ps1:

    Import-Module AzureFunctions.PowerShell.OpenTelemetry.SDK -Force -ErrorAction Stop 
    Initialize-FunctionsOpenTelemetry 
    
  1. Убедитесь, что эти библиотеки присутствуют в файле requirements.txt, путем снятия комментариев или добавления их вручную.

    azure-monitor-opentelemetry
    
  2. Добавьте этот код в function_app.py файл основной точки входа:

    Если вы уже добавили PYTHON_APPLICATIONINSIGHTS_ENABLE_TELEMETRY=true в параметры приложения, этот шаг можно пропустить. Чтобы вручную включить коллекцию Application Insights без автоматического инструментирования, добавьте этот код в приложение:

    from azure.monitor.opentelemetry import configure_azure_monitor 
    configure_azure_monitor() 
    
  3. Ознакомьтесь с документацией по использованию Azure Monitor Distro, чтобы узнать варианты дальнейшей настройки SDK.

Рекомендации по 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.

Детекторы ресурсов и семантические соглашения

В Функции 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 является полезным ресурсом для обнаружения и диагностики потенциальных проблем, связанных с мониторингом.

Чтобы получить доступ к диагностике в приложении, выполните приведенные далее действия.

  1. В портале Azure откройте ресурс вашего приложения функции.

  2. На левой панели выберите "Диагностика и устранение проблем" и найдите приложение-функцию, отсутствующее в приложении телеметрии Application Insights или рабочем процессе OpenTelemetry .

  3. Выберите этот рабочий процесс, выберите метод приема и нажмите кнопку "Далее".

  4. Ознакомьтесь с инструкциями и рекомендациями, предоставленными средством устранения неполадок.

Дальнейшие шаги

Дополнительные сведения о OpenTelemetry и мониторинге Функции Azure: