#Настройка 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 смотрите receiver README.

#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. Для более подробных конфигураций процессоров смотрите processor README.

#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 смотрите exporter README.

#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 смотрите connector README.

#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 смотрите extension README.

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