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

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

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

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

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

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

• Receivers
• Processors
• Exporters
• Connectors

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

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

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

Важное замечание: Хотя обычно конечные точки привязываются к localhost, когда все клиенты локальные, в нашем примере конфигурации для удобства используется "неуказанный" адрес 0.0.0.0. В настоящее время Collector по умолчанию использует localhost. Для подробной информации о значениях конфигурации конечных точек смотрите Меры безопасности для предотвращения атак типа отказ в обслуживании.

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 принимает данные в определённом формате, преобразует их во внутренний формат и передаёт далее процессорам и экспортерам, определённым в соответствующем конвейере.

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

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

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

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

#OTLP Receiver

OTLP receiver принимает трассы, метрики и логи с использованием 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 принимает трассы в формате 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 принимает трассы в форматах Zipkin v1 и v2.

Пример YAML

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

    service:
      pipelines:
        traces:
          receivers: [zipkin]

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

#Processors

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

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

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

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

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

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

#Batch Processor

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

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

Пример 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 и обычно используется для следующих задач:

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

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

Пример YAML

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

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

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

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

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

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

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

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

#Transform Processor

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

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

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

Операторы могут преобразовывать телеметрию более высокого контекста. Например, оператор, применённый к точке данных, может получить доступ к метрике и ресурсу этой точки. Доступ к более низким контекстам невозможен; например, оператор span не может преобразовывать отдельные события спана. Обычно операторы ассоциируются с контекстом, который нужно преобразовать.

Пример использования transform processor для установки статуса спана. Следующий пример устанавливает статус спана в 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 описывает, как процессор реагирует на ошибки при обработке операторов:

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

#Расширенные возможности

• Вы также можете использовать transform processor для изменения имён спанов на основе атрибутов спана или извлечения атрибутов из имени спана. Примеры см. в файле конфигурации transform processor.
• Transform processor также предлагает расширенные возможности трансформации атрибутов. Он позволяет конечным пользователям задавать преобразования для метрик, логов и трасс с помощью 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 отправляют данные в один или несколько бекендов или назначений. Exporters могут работать по принципу pull или push и могут поддерживать один или несколько источников данных.

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

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

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

Совет: Некоторые exporters требуют сертификаты x.509 для установления защищённого соединения, как описано в Настройке сертификатов. Для более подробных конфигураций exporters смотрите README exporters.

#OTLP Exporter

OTLP exporter отправляет метрики, трассы и логи в формате OTLP по gRPC. Поддерживаемые типы конвейеров включают спаны, метрики и логи. По умолчанию этот 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 экспортирует трассы и метрики с использованием 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 может экспортировать спаны, метрики и логи в несколько бекендов. Поддерживаемые типы конвейеров включают метрики, спаны и логи. Load Balancing Exporter может использовать политики маршрутизации для отправки телеметрии в несколько бекендов одновременно. Вы можете настроить routing_key для классификации телеметрии на группы и сопоставления этих групп с конкретными конечными точками.

С помощью Load Balancing Exporter можно также отправлять данные другим запущенным экземплярам OpenTelemetry Collector через конечные точки collector. Например, можно отправлять все трассы на один экземпляр collector, а все логи — на другой. Это позволяет обрабатывать или изменять данные в разных окружениях 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 экспортирует метрики в формате Prometheus или OpenMetrics, позволяя серверам Prometheus собирать эти данные. Ниже приведены детали настройки и использования Prometheus Exporter.

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

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

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

• const_labels: Пары ключ-значение, применяемые к каждой экспортируемой метрике, по умолчанию не заданы.
• namespace: Если задан, все экспортируемые метрики будут использовать этот namespace, значения по умолчанию нет.
• send_timestamps: Отправлять ли метки времени для образцов метрик в ответе, по умолчанию false.
• metric_expiration: Время, в течение которого метрики экспонируются без обновлений, по умолчанию 5m.
• resource_to_telemetry_conversion:
  • enabled: По умолчанию false. При включении атрибуты ресурса конвертируются в метки метрик.
• enable_open_metrics: По умолчанию false. При включении метрики экспортируются в формате 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 по адресу 0.0.0.0:8889/metrics и настраивает TLS-сертификаты и другие параметры.

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

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

#Connectors

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

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

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

Совет: Для более подробной настройки connector смотрите README connector.

#ASM Service Graph Connector

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

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

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

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

Пример YAML

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

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

#Extensions

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

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

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

Примечание: Настройка расширения не включает его. Extensions должны быть включены в service section. По умолчанию расширения не настроены.

Совет: Для более подробной настройки расширений смотрите README extension.

#Service Section

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

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

1. Extensions: Список необходимых расширений для включения. Например:

   service:
     extensions: [health_check, pprof, zpages]

2. Pipelines: Настройка конвейеров, которые могут иметь следующие типы:

   • traces: Сбор и обработка данных трассировки.
   • metrics: Сбор и обработка метрик.
   • logs: Сбор и обработка логов.

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

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

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

   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 используется для настройки наблюдаемости самого Collector. Он состоит из подразделов logs и metrics. Для информации о настройке этих сигналов смотрите Активация внутренней телеметрии в 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-прокси.
• HTTPS_PROXY: Адрес HTTPS-прокси.
• NO_PROXY: Адреса, которые должны обходить прокси.

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

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

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

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

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

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

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

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

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

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

На стороне прокси этот пример настраивает 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

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

Для защищённого взаимодействия в продуктивных средах используйте TLS-сертификаты или mTLS для взаимной аутентификации. Следуйте этим шагам для генерации самоподписанного сертификата или используйте текущего поставщика сертификатов для продуктивных сертификатов.

Установите 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. Центр сертификации (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 не поддерживает установку ключей, содержащих точки (.) или знаки равенства (=).