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 і адмова бэкенда паказваюць на розныя ўліковыя запісы і этапы.

Падобныя артыкулы