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

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

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

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

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

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

• Приёмники
• Процессоры
• Экспортеры
• Коннекторы

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

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

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

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

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]

Обратите внимание, что приёмники, процессоры, экспортеры и 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]

#Приёмники

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

Как правило, приёмник получает данные в заданном формате, преобразует их во внутренний формат, а затем передает процессорам и экспортерам, определенным в соответствующем pipeline.

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

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

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

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

#Приёмник OTLP

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

Пример YAML

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

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

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

#Приёмник Jaeger

Приёмник Jaeger получает traces в формате Jaeger.

Пример YAML

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

    service:
      pipelines:
        traces:
          receivers: [jaeger]

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

#Приёмник Zipkin

Приёмник Zipkin получает traces в форматах Zipkin v1 и v2.

Пример YAML

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

    service:
      pipelines:
        traces:
          receivers: [zipkin]

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

#Процессоры

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

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

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

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

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

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

#Batch Processor

Batch Processor группирует и сжимает spans, metrics или logs по размеру или времени. Пакетирование может помочь уменьшить количество запросов на отправку, выполняемых экспортерами, а также регулировать поток телеметрии от одного или нескольких приёмников в pipeline.

Пример YAML

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

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

#Memory Limiter Processor

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

Пример YAML

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

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

#Filter Processor

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

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

Пример YAML

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

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

#Metrics Transform Processor

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

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

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

Пример YAML

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

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

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

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

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

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

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

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

#Transform Processor

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

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

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

Statements могут преобразовывать телеметрические данные более высоких контекстов. Например, statement, примененный к точке данных, может обращаться к metric и resource этой точки данных. Более низкие контексты недоступны; например, нельзя использовать statement span для преобразования отдельных событий span. Обычно statements связываются с тем контекстом, который вы хотите преобразовать.

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

Пример YAML

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

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

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

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

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

#Экспортеры

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

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

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

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

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

#Экспортер OTLP

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

Пример 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

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

Пример YAML

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

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

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

#Экспортер Debug

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

Пример YAML

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

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

#Экспортер Load Balancing

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

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

Пример YAML

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

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

#Экспортер Prometheus

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

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

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

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

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

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

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

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

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

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

#Коннекторы

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

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

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

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

#ASM Service Graph Connector

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

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

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

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

Пример YAML

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

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

#Расширения

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

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

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

Примечание: Настройка расширения не включает его автоматически. Расширения необходимо включить в разделе service. По умолчанию ни одно расширение не настроено.

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

#Раздел Service

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

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

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

   service:
     extensions: [health_check, pprof, zpages]

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

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

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

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

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

   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. Информацию о том, как настроить эти signals, см. в разделе Активация внутренней телеметрии в Collector.

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

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

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

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

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

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

#Поддержка proxy

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

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

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

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

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

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

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

Список известных authenticators см. в реестре.

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

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

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

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

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

processors:

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

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

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

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

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

processors:

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



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

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

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

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

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

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

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

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

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

#Переопределение настроек

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

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

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

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