#Настройка OpenTelemetry Collector

#Обзор возможностей

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

• Концепции сбора данных, чтобы понять, к какому репозиторию относится OpenTelemetry Collector.
• Рекомендации по безопасности.

#Структура конфигурации

Структура любого файла конфигурации Collector состоит из четырех типов компонентов пайплайна, которые взаимодействуют с телеметрическими данными:

• Receivers
• Processors
• Exporters
• Connectors

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

Помимо компонентов пайплайна, вы можете настроить Extensions, которые предоставляют дополнительные функции, добавляемые в Collector, например средства диагностики. Extensions не нуждаются в прямом доступе к телеметрическим данным и включаются через раздел service.

Ниже приведен пример конфигурации Collector, включающей receivers, processors, exporters и три extension.

Важно: Хотя при подключении всех клиентов локально обычно связывают endpoints с localhost, в нашей примерной конфигурации для удобства используется адрес 0.0.0.0, обозначающий "неопределенный" адрес. В настоящее время Collector по умолчанию использует localhost. Подробную информацию об этих значениях конфигурации endpoint см. в разделе Security Measures to Prevent Denial of Service Attacks.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
processors:
  batch:

exporters:
  otlp:
    endpoint: otelcol:4317

extensions:
  health_check:
  pprof:
  zpages:

service:
  extensions: [health_check, pprof, zpages]
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]

Обратите внимание, что receivers, processors, exporters и pipelines определяются с использованием идентификатора компонента в формате type[/name], например otlp или otlp/2. Пока идентификатор уникален, один и тот же тип компонента можно определить несколько раз. Например:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
  otlp/2:
    protocols:
      grpc:
        endpoint: 0.0.0.0:55690

processors:
  batch:
  batch/test:

exporters:
  otlp:
    endpoint: otelcol:4317
  otlp/2:
    endpoint: otelcol2:4317

extensions:
  health_check:
  pprof:
  zpages:

service:
  extensions: [health_check, pprof, zpages]
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]
    traces/2:
      receivers: [otlp/2]
      processors: [batch/test]
      exporters: [otlp/2]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]

Конфигурация также может включать другие файлы, позволяя Collector объединять их в единую конфигурацию YAML в памяти:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

exporters: ${file:exporters.yaml}

service:
  extensions: []
  pipelines:
    traces:
      receivers: [otlp]
      processors: []
      exporters: [otlp]

Файл exporters.yaml может содержать:

otlp:
  endpoint: otelcol.observability.svc.cluster.local:443

Итоговая конфигурация в памяти будет выглядеть так:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

exporters:
  otlp:
    endpoint: otelcol.observability.svc.cluster.local:443

service:
  extensions: []
  pipelines:
    traces:
      receivers: [otlp]
      processors: []
      exporters: [otlp]

#Receivers

Receivers собирают телеметрические данные из одного или нескольких источников. Они могут работать по модели pull или push и могут поддерживать один или несколько источников данных.

Обычно receiver принимает данные в заданном формате, преобразует их во внутренний формат, а затем передает их processors и exporters, определенным в соответствующем пайплайне.

Receivers настраиваются в разделе receivers. По умолчанию receivers не настроены. Необходимо настроить один или несколько receivers. Многие receivers имеют параметры по умолчанию, поэтому достаточно указать имя receiver. Если требуется настроить или изменить конфигурацию по умолчанию, это можно сделать в данном разделе. Любые указанные вами параметры переопределят значения по умолчанию, если они существуют.

Примечание: Настройка receiver не включает его. Receiver включается путем добавления его в соответствующий пайплайн в разделе service.

Ниже приведены распространенные примеры настройки receivers.

Совет: Более подробные конфигурации receivers см. в README receiver.

#OTLP Receiver

OTLP receiver принимает traces, metrics и logs с использованием OpenTelemetry Protocol (OTLP).

Пример YAML

  config: |
    receivers:
      otlp:
        protocols:
          grpc:
            endpoint: 0.0.0.0:4317
            tls:
              ca_file: ca.pem
              cert_file: cert.pem
              key_file: key.pem
              client_ca_file: client.pem
              reload_interval: 1h
          http:
            endpoint: 0.0.0.0:4318

    service:
      pipelines:
        traces:
          receivers: [otlp]
        metrics:
          receivers: [otlp]

Описание параметров protocols

#Jaeger Receiver

Jaeger receiver принимает traces в формате Jaeger.

Пример YAML

  config: |
    receivers:
      jaeger:
        protocols:
          grpc:
            endpoint: 0.0.0.0:14250
          thrift_http:
            endpoint: 0.0.0.0:14268
          thrift_compact:
            endpoint: 0.0.0.0:6831
          thrift_binary:
            endpoint: 0.0.0.0:6832

    service:
      pipelines:
        traces:
          receivers: [jaeger]

Описание параметров protocols

#Zipkin Receiver

Zipkin receiver принимает traces как в формате Zipkin v1, так и v2.

Пример YAML

  config: |
    receivers:
      zipkin:
        endpoint: 0.0.0.0:9411

    service:
      pipelines:
        traces:
          receivers: [zipkin]

Описание параметра zipkin

#Processors

Processors изменяют или преобразуют данные, собранные receivers, перед отправкой их в exporters. Обработка данных основана на правилах или настройках, определенных для каждого processor, и может включать фильтрацию, удаление, переименование или пересчет телеметрических данных. Порядок processors в пайплайне определяет последовательность, в которой Collector применяет операции обработки к signals.

Processors не являются обязательными, однако некоторые из них рекомендуются.

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

Примечание: Настройка processor не включает его. Processor должен быть включен путем добавления в соответствующий пайплайн в разделе service. По умолчанию ни один processor не включен.

Ниже приведены примеры распространенных конфигураций processors.

Совет: Полный список processors можно получить, объединив списки из opentelemetry-collector-contrib и opentelemetry-collector. Более подробные конфигурации processors см. в README processor.

#Batch Processor

Batch Processor группирует и сжимает spans, metrics или logs на основе размера или времени. Группирование может помочь уменьшить количество запросов на отправку, выполняемых exporters, а также регулировать поток телеметрии от нескольких или одного receiver в пайплайне.

Пример YAML

  config: |
    processor:
      batch:
        timeout: 5s
        send_batch_max_size: 10000
    service:
      pipelines:
        traces:
          processors: [batch]
        metrics:
          processors: [batch]

Описание параметров batch

#Memory Limiter Processor

Memory Limiter Processor периодически проверяет использование памяти Collector и приостанавливает обработку данных, когда достигается мягкий предел памяти, предотвращая ситуации out-of-memory. Этот processor поддерживает spans, metrics и logs. Обычно это первый компонент после receivers, который ожидает повторных попыток для отправки тех же данных и, возможно, создает обратное давление на входящие данные. Когда использование памяти превышает жесткий предел, Memory Limiter Processor инициирует сборку мусора.

Пример YAML

  config: |
    processor:
      memory_limiter:
        check_interval: 1s
        limit_mib: 4000
        spike_limit_mib: 800
    service:
      pipelines:
        traces:
          processors: [batch]
        metrics:
          processors: [batch]

Описание параметров memory_limiter

#Filter Processor

Filter Processor фильтрует spans, metrics или logs на основе условий, заданных в его конфигурации. Типичный сценарий использования Filter Processor — исключение телеметрических данных, не относящихся к системе observability, например некритичных logs или spans, чтобы уменьшить шум в данных.

Фильтрация работает с allow- и deny-списками, которые включают или исключают телеметрию на основе регулярных выражений и атрибутов ресурса. Для более точного описания сигналов, которые нужно отфильтровать, также можно использовать OpenTelemetry Transformation Language (OTTL). Processor поддерживает все типы пайплайнов.

Пример YAML

config: |
  processors:
    filter/ottl:
      error_mode: ignore
      traces:
        span:
          - 'attributes["container.name"] == "app_container_1"'
          - 'resource.attributes["host.name"] == "localhost"'

Описание параметров filter/ottl

#Metrics Transform Processor

Metrics Transform Processor разделяет некоторые функции с Attributes Processor и обычно используется для выполнения следующих задач:

• Добавление, переименование или удаление ключей и значений labels.
• Масштабирование и агрегация metrics на основе labels или значений labels.
• Processor поддерживает только переименование и агрегацию внутри одной партии metrics. Он не выполняет межпакетную агрегацию, поэтому не используйте его для агрегации metrics из нескольких источников, например нескольких nodes или clients.

Полный список поддерживаемых операций см. в разделе Available Operations.

Пример YAML

config: |
  processors:
    metricstransform/rename:
      transforms:
        include: system.cpu.usage
        action: update
        new_name: system.cpu.usage_time

Metrics Transform processor также поддерживает использование регулярных выражений, что позволяет применять правила преобразования одновременно к нескольким именам metrics или labels metrics. В следующем примере cluster_name переименовывается в cluster-name во всех metrics:

config: |
  processors:
    metricstransform/clustername:
      transforms:
        - include: ^.*$
          match_type: regexp
          action: update
          operations:
            - action: update_label
              label: cluster_name
              new_label: cluster-name

Доступные операции

Processor может выполнять следующие операции:

• Переименование metrics. Например, переименование system.cpu.usage в system.cpu.usage_time.
• Добавление labels. Например, можно добавить новый label identifier со значением 1 ко всем точкам.
• Переименование ключей labels. Например, переименование label state в cpu_state.
• Переименование значений labels. Например, переименование значения idle в - внутри label state.
• Удаление точек данных. Например, удаление всех точек, где label state имеет значение idle.
• Изменение типов данных. Можно преобразовать точки данных int в точки данных double.
• Масштабирование значений. Например, умножение значений на 1000 для преобразования секунд в миллисекунды.
• Агрегация по наборам labels. Например, сохранение только label state и вычисление среднего для всех точек с одинаковым значением этого label.
• Агрегация по значениям labels. Например, суммирование точек со значениями user или system в label state как used = user + system.

Применяются следующие правила:

• Вы можете применять операции только к одному или нескольким metrics с использованием фильтра strict или regexp.
• Используя свойство action, вы можете:
  • Обновлять metrics на месте (update).
  • Дублировать и обновлять дублированные metrics (insert).
  • Объединять metrics в новую вставленную metric путем слияния всех точек данных из набора совпавших metrics в одну metric (combine). Исходные совпавшие metrics также удаляются.
• При переименовании metrics группы захвата в фильтре regexp будут развернуты.

#Transform Processor

Transform Processor изменяет совпавшие spans, metrics или logs с помощью выражений. Сценарии использования включают, помимо прочего, преобразование metrics в другие типы, замену или удаление ключей, а также установку полей на основе заранее определенных условий.

Выражения являются функциями OpenTelemetry Transformation Language (OTTL) и применяются к телеметрическим данным в соответствии с их порядком в списке. Transform processor включает дополнительные функции для преобразования типов metrics. Выражения преобразуют данные в соответствии с контекстом OTTL, который вы определяете, например Span или DataPoint.

Поддерживаемые контексты для transform processor:

Выражения могут преобразовывать телеметрические данные более высокого контекста. Например, выражение, примененное к data point, может получить доступ к metric и resource этой data point. Контексты более низкого уровня недоступны; например, нельзя использовать выражение span для преобразования отдельных событий span. Обычно выражения связываются с тем контекстом, который вы хотите преобразовать.

Пример использования transform processor для задания статуса span. В следующем примере статус span устанавливается в Ok, когда атрибут http.request.status_code равен 400:

Пример YAML

config: |
  transform:
    error_mode: ignore
    trace_statements:
      - context: span
        statements:
          - set(status.code, STATUS_CODE_OK) where attributes["http.request.status_code"] == 400

Поле error_mode описывает, как processor реагирует на ошибки при обработке выражений:

• "error_mode: ignore" указывает processor игнорировать ошибки и продолжать выполнение. Это режим ошибок по умолчанию.
• "error_mode: propagate" указывает processor возвращать ошибку. В результате collector будет отбрасывать данные.

#Дополнительные возможности

• Вы также можете использовать transform processor для изменения имен span на основе атрибутов span или для извлечения атрибутов span из имени span. Примеры см. в примере файла конфигурации transform processor.
• Transform processor также предоставляет расширенные возможности преобразования атрибутов. Transform processor позволяет конечным пользователям задавать преобразования для metrics, logs и traces с использованием OpenTelemetry Transformation Language (OTTL).
• Дополнительные сведения о функциях и синтаксисе OTTL см. здесь:
  • Синтаксис OTTL: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/pkg/ottl/README.md
  • Функции OTTL: https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/pkg/ottl/ottlfuncs
  • Контексты OTTL: https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/pkg/ottl/contexts

#Exporters

Exporters отправляют данные в один или несколько backend'ов или destinations. Exporters могут работать по модели pull или push и могут поддерживать один или несколько источников данных.

Вы можете настраивать exporters в разделе exporters файла конфигурации Collector. Большинству exporters требуется как минимум destination и параметры безопасности, такие как токены аутентификации или TLS-сертификаты. Любые указанные вами параметры переопределят значения по умолчанию, если они существуют.

Примечание: Настройка exporter не включает его. Exporter нужно включить, добавив его в соответствующий пайплайн в разделе service. По умолчанию exporters не включены.

Collector требует один или несколько exporters. Ниже приведены распространенные примеры конфигурации exporters:

Совет: Некоторые exporters требуют x.509 сертификаты для установления защищенного соединения, как описано в разделе Setting up Certificates. Более подробные конфигурации exporters см. в README exporter.

#OTLP Exporter

OTLP exporter отправляет metrics, traces и logs в формате OTLP по gRPC. Поддерживаемые типы пайплайнов включают spans, metrics и logs. По умолчанию этот exporter требует TLS и поддерживает функцию очереди повторных попыток. Для отправки OTLP-данных по HTTP используйте OTLP/HTTP exporter. Инструкции см. в разделе OTLP/HTTP exporter.

Пример YAML

config: |
  exporters:
    otlp:
      endpoint: tempo-ingester:4317
      tls:
        ca_file: ca.pem
        cert_file: cert.pem
        key_file: key.pem
        insecure: false
        insecure_skip_verify: false
        reload_interval: 1h
        server_name_override: <name>
      headers:
        X-Scope-OrgID: "dev"
  service:
    pipelines:
      traces:
        exporters: [otlp]
      metrics:
        exporters: [otlp]

Описание параметров otlp

#OTLP HTTP Exporter

OTLP HTTP Exporter экспортирует traces и metrics с использованием OpenTelemetry Protocol (OTLP).

Пример YAML

  config: |
    exporters:
      otlphttp:
        endpoint: http://tempo-ingester:4318
        tls:
        headers:
          X-Scope-OrgID: "dev"
        disable_keep_alives: false

    service:
      pipelines:
        traces:
          exporters: [otlphttp]
        metrics:
          exporters: [otlphttp]

Описание параметров otlphttp

#Debug Exporter

Debug Exporter выводит телеметрические данные в консоль для целей отладки.

Пример YAML

  config: |
    exporters:
      debug:
        verbosity: detailed
    service:
      pipelines:
        traces:
          exporters: [logging]
        metrics:
          exporters: [logging]

Поле debug.verbosity управляет уровнем детализации экспортируемых данных в журналах (detailed|normal|basic). При значении detailed данные пайплайна записываются подробно.

#Load Balancing Exporter

Load Balancing Exporter может экспортировать spans, metrics и logs в несколько backend'ов. Поддерживаемые типы пайплайнов включают metrics, spans и logs. Load Balancing Exporter может использовать политики маршрутизации для одновременной отправки телеметрических данных в несколько backend'ов. Вы можете настроить routing_key, чтобы с помощью политик маршрутизации классифицировать телеметрические данные по группам и сопоставлять эти группы с конкретными endpoints.

Используя Load Balancing Exporter, вы также можете отправлять данные в другие запущенные экземпляры OpenTelemetry Collector через collector endpoints. Например, вы можете отправлять все traces в один запущенный экземпляр collector, а все logs — в другой. Это позволяет обрабатывать или изменять данные в различных окружениях collector.

Пример YAML

  config: |
    exporters:
      loadbalancing:
        routing_key: "service"
        protocol:
          otlp:
            timeout: 1s
        resolver:
          static:
            hostnames:
            - backend-1:4317
            - backend-2:4317
          dns:
            hostname: otelcol-headless.observability.svc.cluster.local
          k8s:
            service: lb-svc.kube-public
            ports:
              - 15317
              - 16317

Описание параметров loadbalancing

#Prometheus Exporter

Prometheus Exporter экспортирует данные metrics в формате Prometheus или OpenMetrics, позволяя серверам Prometheus выполнять scrape данных. Ниже приведены сведения о настройке и использовании Prometheus Exporter.

Обязательная конфигурация

• endpoint: Указывает адрес, по которому будут доступны данные metrics по пути /metrics. Этот параметр обязательно должен быть настроен и не имеет значения по умолчанию.

Необязательная конфигурация

• const_labels: Labels в виде пар ключ-значение, применяемые к каждому экспортируемому metric; по умолчанию не задаются.
• namespace: Если задан, все экспортируемые metrics будут использовать это пространство имен; значения по умолчанию нет.
• send_timestamps: Отправлять ли timestamps для образцов metrics в ответе; по умолчанию false.
• metric_expiration: Определяет, как долго metrics остаются доступными без обновлений; по умолчанию 5m.
• resource_to_telemetry_conversion:
  • enabled: По умолчанию false. При включении атрибуты ресурса преобразуются в labels metrics.
• enable_open_metrics: По умолчанию false. При включении metrics экспортируются в формате OpenMetrics.
• add_metric_suffixes: По умолчанию true. Определяет, нужно ли добавлять суффиксы типа и единиц измерения.

Конфигурация TLS

TLS-сертификаты можно задать с помощью ca_file, cert_file и key_file, чтобы обеспечить безопасную передачу данных.

Пример YAML-конфигурации

Ниже приведен пример конфигурации для Prometheus Exporter:

exporters:
  prometheus:
    endpoint: "0.0.0.0:8889"
    tls:
      ca_file: "/path/to/ca.pem"
      cert_file: "/path/to/cert.pem"
      key_file: "/path/to/key.pem"
    namespace: "prefix"
    const_labels:
      label1: "value1"
    send_timestamps: true
    metric_expiration: "180m"
    enable_open_metrics: true
    add_metric_suffixes: false
    resource_to_telemetry_conversion:
      enabled: true

Эта конфигурация публикует Prometheus metrics по адресу 0.0.0.0:8889/metrics и настраивает TLS-сертификаты и другие параметры.

Рекомендации по использованию

1. В OpenTelemetry имена metrics и labels стандартизируются в соответствии с соглашениями именования Prometheus.
2. По умолчанию атрибуты ресурса добавляются в metric target_info. Вы можете использовать запросы Prometheus, чтобы выбирать и группировать эти атрибуты как labels metrics.
3. Чтобы упростить запросы и группировку, рекомендуется использовать transform processor для прямого преобразования часто используемых атрибутов ресурса в labels metrics.

#Connectors

Connectors связывают два пайплайна, выступая одновременно как exporters и receivers. Connector принимает данные как exporter в конце одного пайплайна и отправляет данные как receiver в начале другого пайплайна. Получаемые и отправляемые данные могут быть одного или разных типов. Вы можете использовать connectors для агрегации, дублирования или маршрутизации данных.

Вы можете настраивать один или несколько connectors в разделе connectors файла конфигурации Collector. По умолчанию connectors не настроены. Каждый тип connector предназначен для обработки одной или нескольких комбинаций типов данных и может использоваться только для соединения пайплайнов соответствующего типа данных.

Примечание: Настройка connector не включает его. Connectors нужно включить, добавив их в соответствующие пайплайны в разделе service.

Совет: Более подробную конфигурацию connector см. в README connector.

#ASM Service Graph Connector

ASM Service Graph Connector строит карту, отображающую связи между различными services в системе. Этот connector анализирует данные spans и генерирует metrics, описывающие связи между services. Эти metrics могут использоваться приложениями визуализации данных, такими как Grafana, для построения service graph.

Примечание: Этот компонент является пользовательской версией community-компонента Service Graph Connector и не может быть напрямую заменен на нативный community-компонент. Конкретные различия в параметрах описаны ниже.

Топологии сервисов очень полезны во многих сценариях:

• Определение топологии распределенной системы. По мере роста распределенные системы становятся все сложнее. Service graph помогает понять структуру системы.
• Предоставление общего представления о состоянии системы. Service graph отображают частоту ошибок, задержку и другие важные данные.
• Предоставление исторического представления о топологии системы. Распределенные системы часто меняются, и service graph позволяют отслеживать, как эти системы развиваются со временем.

Пример YAML

  config: |
    connectors:
      asmservicegraph:
        dimensions: []
        extra_dimensions:
          mesh_id:
          cluster_name:
        store:
          ttl: 5s
          max_items: 500

Описание параметров asmservicegraph

#Extensions

Extensions добавляют возможности Collector. Например, extensions могут автоматически добавлять функции аутентификации к receivers и exporters.

Extensions — это необязательные компоненты, используемые для расширения функциональности Collector в задачах, не связанных с обработкой телеметрических данных. Например, можно добавить extensions для мониторинга состояния, обнаружения сервисов или пересылки данных.

Вы можете настраивать extensions в разделе extensions файла конфигурации Collector. Большинство extensions уже имеют параметры по умолчанию, поэтому для их настройки достаточно указать имя extension. Любые указанные параметры переопределят значения по умолчанию, если они существуют.

Примечание: Настройка extension не включает его. Extensions необходимо включать в разделе service. По умолчанию extensions не настроены.

Совет: Более подробную конфигурацию extension см. в README extension.

#Раздел service

Раздел service используется для включения компонентов Collector на основе конфигурации в разделах receivers, processors, exporters и extensions. Если компонент настроен, но не указан в разделе service, он не будет включен.

Раздел service включает три подраздела:

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

   service:
     extensions: [health_check, pprof, zpages]

2. Pipelines: Настраивает пайплайны следующих типов:

   • traces: Собирает и обрабатывает trace-данные.
   • metrics: Собирает и обрабатывает metric-данные.
   • logs: Собирает и обрабатывает log-данные.

   Пайплайн состоит из набора receivers, processors и exporters. Перед включением receiver, processor или exporter в пайплайн убедитесь, что их конфигурация определена в соответствующих разделах.

   Один и тот же receiver, processor или exporter можно использовать в нескольких пайплайнах. Когда processor используется в нескольких пайплайнах, для каждого пайплайна создается отдельный экземпляр этого processor.

   Ниже приведен пример конфигурации пайплайна. Обратите внимание, что порядок processors определяет последовательность обработки данных:

   service:
     pipelines:
       metrics:
         receivers: [opencensus, prometheus]
         processors: [batch]
         exporters: [opencensus, prometheus]
       traces:
         receivers: [opencensus, jaeger]
         processors: [batch, memory_limiter]
         exporters: [opencensus, zipkin]

3. Telemetry: Раздел telemetry используется для настройки observability самого Collector. Он состоит из подразделов logs и metrics. Информацию о том, как настраивать эти signals, см. в разделе Activating Internal Telemetry in the Collector.

#Дополнительная информация

#Переменные окружения

Конфигурации Collector поддерживают использование и расширение переменных окружения. Например, чтобы использовать значения, хранящиеся в переменных окружения DB_KEY и OPERATION, можно написать:

processors:
  attributes/example:
    actions:
      - key: ${env:DB_KEY}
        action: ${env:OPERATION}

Используйте $$ для представления буквального $. Например, чтобы представить $DataVisualization, можно написать:

exporters:
  prometheus:
    endpoint: prometheus:8889
    namespace: $$DataVisualization

#Поддержка прокси

Exporters, использующие пакет net/http, поддерживают следующие переменные окружения прокси:

• HTTP_PROXY: Адрес HTTP proxy.
• HTTPS_PROXY: Адрес HTTPS proxy.
• NO_PROXY: Адреса, для которых следует обходить proxy.

Если эти переменные заданы при запуске Collector, exporters будут направлять трафик через proxy или обходить proxy в соответствии с этими переменными окружения, независимо от протокола.

#Аутентификация

Большинство receivers, предоставляющих HTTP- или gRPC-порты, могут быть защищены с использованием механизмов аутентификации Collector. Аналогично, большинство exporters, использующих HTTP- или gRPC-клиенты, могут добавлять аутентификацию к исходящим запросам.

Механизм аутентификации в Collector использует механизм extension, позволяя интегрировать в дистрибутив Collector пользовательские аутентификаторы. Каждое extension аутентификации можно использовать двумя способами:

1. Как клиентский аутентификатор для exporters, добавляющий данные аутентификации в исходящие запросы.
2. Как серверный аутентификатор для receivers, выполняющий аутентификацию входящих соединений.

Список известных аутентификаторов см. в Registry.

Чтобы добавить серверный аутентификатор к receiver в Collector, выполните следующие шаги:

1. Добавьте extension аутентификатора и его конфигурацию в .extensions.
2. Добавьте ссылку на аутентификатор в .services.extensions, чтобы Collector загрузил его.
3. Добавьте ссылку на аутентификатор в .receivers.<your-receiver>.<http-or-grpc-config>.auth.

В следующем примере на принимающей стороне используется аутентификатор OIDC, подходящий для удаленных Collector, принимающих данные через OpenTelemetry Collector в качестве proxy:

extensions:
  oidc:
    issuer_url: http://localhost:8080/auth/realms/opentelemetry
    audience: collector

receivers:
  otlp/auth:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
        auth:
          authenticator: oidc

processors:

exporters:
  # Note: Use `logging` instead of `debug` before v0.86.0.
  debug:

service:
  extensions:
    - oidc
  pipelines:
    traces:
      receivers:
        - otlp/auth
      processors: []
      exporters:
        - debug

На стороне proxy этот пример настраивает OTLP exporter на получение токенов OIDC и добавление их в каждый RPC, отправляемый удаленному Collector:

extensions:
  oauth2client:
    client_id: agent
    client_secret: some-secret
    token_url: http://localhost:8080/auth/realms/opentelemetry/protocol/openid-connect/token

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

processors:

exporters:
  otlp/auth:
    endpoint: remote-collector:4317
    auth:
      authenticator: oauth2client



service:
  extensions:
    - oauth2client
  pipelines:
    traces:
      receivers:
        - otlp
      processors: []
      exporters:
        - otlp/auth

#Настройка сертификатов

Для безопасной связи в production-средах используйте TLS-сертификаты или mTLS для взаимной аутентификации. Выполните следующие шаги, чтобы сгенерировать самоподписанный сертификат, или используйте текущего поставщика сертификатов для production-сертификатов.

Установите cfssl и создайте следующий файл csr.json:

{
  "hosts": ["localhost", "127.0.0.1"],
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "O": "OpenTelemetry Example"
    }
  ]
}

Затем выполните следующие команды:

cfssl genkey -initca csr.json | cfssljson -bare ca
cfssl gencert -ca ca.pem -ca-key ca-key.pem csr.json | cfssljson -bare cert

Это создаст два сертификата:

1. Certificate authority (CA) с именем "OpenTelemetry Example", хранящийся в ca.pem, с соответствующим ключом в ca-key.pem.
2. Клиентский сертификат, хранящийся в cert.pem, подписанный CA OpenTelemetry Example, с соответствующим ключом в cert-key.pem.

#Переопределение параметров

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

Следующий пример показывает, как переопределять параметры во вложенных разделах:

otelcol --set "exporters::debug::verbosity=detailed"
otelcol --set "receivers::otlp::protocols::grpc={endpoint:localhost:4317, compression: gzip}"

Важно: Опция --set не поддерживает задание ключей, содержащих точки (.) или знаки равенства (=).