OpenTelemetry Collector: настройка прокси для экспортёра OTLP HTTP
Используйте параметр proxy_url экспортёра OTLP HTTP и подключите этот экспортёр к конвейеру, который действительно отправляет телеметрию.
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 и отказ бэкенда указывают на разные учётные записи и этапы.