Collector принимает телеметрию от приложений, а затем устанавливает отдельное исходящее соединение с настроенным бэкендом. Прокси задаётся на этом исходящем HTTP-экспортёре:

exporters:
  otlp_http/proxied:
    endpoint: https://telemetry.example:4318
    proxy_url: http://proxy.example:8080

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlp_http/proxied]

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

endpoint остаётся базовым URL бэкенда телеметрии. Экспортёр OTLP HTTP добавляет путь сигнала, например /v1/traces, если его не переопределяет endpoint, специфичный для сигнала. proxy_url указывает посредника. Для нечувствительного публичного тестового бэкенда, допускающего маршрут через публичный прокси, этот URL можно заполнить адресом из списка HTTP-прокси; убедитесь в доступе к фактическим host и port бэкенда.

Текущая документация upstream называет этот компонент otlp_http, а otlphttp описывает как устаревший псевдоним. Более старые дистрибутивы могут использовать прежнее имя компонента; держите и определение экспортёра, и ссылку в конвейере согласованными с установленным дистрибутивом.

Это конфигурация HTTP-клиента. У экспортёра OTLP gRPC другой транспорт, а собственное прокси-окружение приложения не попадает автоматически в контейнер или процесс службы Collector. Точно так же настройка приёмника относится к входящему трафику, а не к этому соединению с бэкендом.

Сохраняйте проверку TLS бэкенда и требуемую аутентификацию службы. Ответ прокси 407 и отказ бэкенда указывают на разные учётные записи и этапы.

Похожие статьи