#Настройка 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 не может трансформировать отдельные события 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 сертификаты для установления защищённого соединения, как описано в Настройке сертификатов. Для более подробных конфигураций смотрите 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 endpoints. Например, можно отправлять все трассы одному экземпляру 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 компонентом. Конкретные различия параметров описаны ниже.

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

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

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

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

Совет: Для более подробной настройки extension смотрите 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 не поддерживает установку ключей, содержащих точки (.) или знаки равенства (=).