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 указва посредника. За нетретиран като чувствителен тестов бекенд, който е публичен и допуска маршрут през публичен прокси, адрес от списъка с HTTP прокси може да запълни този URL; потвърдете достъпа до действителните host и port на бекенда.

Текущата upstream документация нарича този компонент otlp_http и описва otlphttp като остарял псевдоним. По-старите дистрибуции могат да използват старото име на компонента; поддържайте както дефиницията на експортера, така и референцията в конвейера съответни на инсталираната дистрибуция.

Това е конфигурация на HTTP клиент. OTLP gRPC експортерът има друг транспорт, а собствената прокси среда на приложението не влиза автоматично в контейнера или процеса на услугата Collector. По същия начин конфигурирането на получателя адресира входящия трафик, а не тази връзка към бекенда.

Запазете TLS проверката на бекенда и изискваната автентикация на услугата. Отговор 407 от прокси и отхвърляне от бекенда сочат различни акаунти и етапи.

Подобни статии