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 і відмова бекенду вказують на різні облікові записи та етапи.

Схожі статті