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

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

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

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

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

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

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

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

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

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

Важное примечание: Хотя обычно конечные точки привязываются к 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]

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

#Пакетный процессор

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

Пример YAML

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

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

#Процессор ограничения памяти

Процессор ограничения памяти периодически проверяет использование памяти Collector и приостанавливает обработку данных при достижении мягкого лимита памяти, предотвращая ситуации нехватки памяти. Этот процессор поддерживает spans, metrics и logs. Обычно он является первым компонентом после приемников, ожидая повторных попыток отправить те же данные и, возможно, создавая обратное давление на входящие данные. Когда использование памяти превышает жесткий лимит, процессор ограничения памяти принудительно запускает сборку мусора.

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

#Процессор фильтрации

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

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

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

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

Пример YAML

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

Процессор преобразования metrics также поддерживает использование регулярных выражений, что позволяет применять правила преобразования одновременно к нескольким именам metrics или меткам 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

#Отладочный экспортер

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

Пример YAML

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

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

#Экспортер балансировки нагрузки

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

С помощью экспорта балансировки нагрузки вы также можете отправлять данные другим работающим экземплярам OpenTelemetry Collector через конечные точки 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: Метки в виде пар ключ-значение, применяемые к каждому экспортируемому metric; по умолчанию не задано.
• namespace: Если задано, все экспортируемые metrics будут использовать это пространство имен; значения по умолчанию нет.
• send_timestamps: Нужно ли отправлять временные метки для образцов metrics в ответе; по умолчанию false.
• metric_expiration: Определяет, как долго metrics публикуются без обновлений; по умолчанию 5m.
• resource_to_telemetry_conversion:
  • enabled: По умолчанию false. При включении атрибуты ресурса преобразуются в labels metrics.
• enable_open_metrics: По умолчанию false. При включении metrics экспортируются в формате OpenMetrics.
• add_metric_suffixes: По умолчанию true. Определяет, добавлять ли суффиксы типа и единиц измерения.

Настройка TLS

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

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

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

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

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

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

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

#Коннекторы

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

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

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

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

#ASM Service Graph Connector

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

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

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

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

Пример YAML

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

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

#Extensions

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

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

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

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

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

#Раздел Service

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

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

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

   service:
     extensions: [health_check, pprof, zpages]

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

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

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

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

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

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

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

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

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

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

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

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

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