Работа агента через прокси-сервер

На этой странице:

• Способы подключения
• Корпоративный HTTP(S)-прокси
  • Параметры
  • Какой прокси выбирается для запроса
  • Исключения: no_proxy
  • Linux и Windows
  • Docker
  • Kubernetes
  • Какие данные идут через прокси
• Промежуточный сервер-ретранслятор
• Проверка работы

Способы подключения

Агент сам устанавливает соединения с ProtoOBP Backend: отправляет метрики, трейсы, логи и служебные данные. Если прямого сетевого доступа от хоста с агентом до бэкенда нет, используйте один из двух способов:

Соединения от трейсеров приложений к агенту (порт 8126, DogStatsD 8125, OTLP 4317/4318) остаются локальными и через прокси не проходят.

Корпоративный HTTP(S)-прокси

Параметры

Прокси задаётся в секции proxy основного файла конфигурации protoobp.yaml (расположение файла — в разделе Файлы конфигурации агента):

proxy:
  http: http://<ЛОГИН>:<ПАРОЛЬ>@<АДРЕС_ПРОКСИ>:<ПОРТ>
  https: http://<ЛОГИН>:<ПАРОЛЬ>@<АДРЕС_ПРОКСИ>:<ПОРТ>
  no_proxy:
    - <ХОСТ_1>
    - <ХОСТ_2>

Если параметры не заданы ни в файле, ни через POBP_PROXY_*, агент использует стандартные переменные окружения HTTP_PROXY, HTTPS_PROXY и NO_PROXY. Переменные POBP_PROXY_* имеют приоритет над стандартными, а переменные окружения в целом — над значениями из protoobp.yaml.

Логин и пароль указываются в адресе прокси. Специальные символы в них (@, :, /, #, %) кодируются в URL-формате, например p@ss записывается как p%40ss. Чтобы не хранить пароль в открытом виде, задайте его через управление секретами: https: ENC[proxy_url].

В журнале агента учётные данные прокси маскируются (*****:*****@).

Какой прокси выбирается для запроса

Агент выбирает прокси по схеме адреса назначения, а не по схеме адреса прокси:

• адрес бэкенда http://protoobp-backend → используется proxy.http;
• адрес бэкенда https://protoobp-backend → используется proxy.https.

Сам прокси-сервер обычно указывается со схемой http:// в обоих параметрах: для HTTPS-запросов агент открывает через него туннель методом CONNECT.

Исключения: no_proxy

По умолчанию элемент no_proxy сравнивается с хостом назначения точно, включая порт, если он указан в адресе. Например, для pobp_url: http://backend.local:8080 подойдёт элемент backend.local:8080, а backend.local — нет.

Включите no_proxy_nonexact_match: true, чтобы использовать привычные правила NO_PROXY:

no_proxy_nonexact_match: true
proxy:
  http: http://proxy.corp.local:3128
  https: http://proxy.corp.local:3128
  no_proxy:
    - .corp.local        # домен и все его поддомены
    - 10.0.0.0/8         # подсеть
    - localhost

Linux и Windows

1. Добавьте секцию proxy в protoobp.yaml:

   • Linux: /etc/protoobp-agent/protoobp.yaml;
   • Windows: %ProgramData%\Protoobp\protoobp.yaml.

   api_key: <ВАШ_API_KEY>
   pobp_url: http://protoobp-backend
   apm_config:
     apm_non_local_traffic: true
     apm_pobp_url: http://protoobp-backend
   proxy:
     http: http://proxy.corp.local:3128
     https: http://proxy.corp.local:3128
   

2. Перезапустите агента: на Linux — systemctl restart protoobp-agent, на Windows — через ProtoOBP Agent Manager или командой agent.exe restart-service (см. Windows агент – управление).

Вместо секции в файле на Linux можно задать переменные POBP_PROXY_HTTP, POBP_PROXY_HTTPS и POBP_PROXY_NO_PROXY через drop-in файл systemd — см. Переменные окружения агента.

Docker

Передайте параметры переменными окружения контейнера агента:

docker run -d --name protoobp-agent \
  -e POBP_API_KEY=<ВАШ_API_KEY> \
  -e POBP_URL=http://protoobp-backend \
  -e POBP_PROXY_HTTP=http://proxy.corp.local:3128 \
  -e POBP_PROXY_HTTPS=http://proxy.corp.local:3128 \
  -e POBP_PROXY_NO_PROXY="localhost 127.0.0.1" \
  ...

В docker-compose.yaml те же переменные указываются в секции environment сервиса агента.

Kubernetes

Добавьте переменные в values.yaml Helm-чарта агента. Cluster Agent получает переменные отдельно от агента на нодах, поэтому их нужно продублировать в clusterAgent.env:

protoobp:
  env:
    - name: POBP_PROXY_HTTP
      value: http://proxy.corp.local:3128
    - name: POBP_PROXY_HTTPS
      value: http://proxy.corp.local:3128
    - name: POBP_PROXY_NO_PROXY
      value: "localhost 127.0.0.1 .svc .cluster.local"
    - name: POBP_NO_PROXY_NONEXACT_MATCH
      value: "true"
clusterAgent:
  env:
    - name: POBP_PROXY_HTTP
      value: http://proxy.corp.local:3128
    - name: POBP_PROXY_HTTPS
      value: http://proxy.corp.local:3128
    - name: POBP_PROXY_NO_PROXY
      value: "localhost 127.0.0.1 .svc .cluster.local"
    - name: POBP_NO_PROXY_NONEXACT_MATCH
      value: "true"

Внесите в no_proxy внутрикластерные адреса (.svc, .cluster.local), чтобы обращения агента к kubelet, API Kubernetes и Cluster Agent не уходили на прокси. Примените изменения командой из раздела Изменение параметров Kubernetes агента.

Какие данные идут через прокси

Секция proxy действует для всех исходящих HTTP(S)-соединений агента:

Логи, которые агент отправляет по TCP (параметр logs_config.force_use_tcp: true), через HTTP-прокси не проходят. Чтобы логи гарантированно шли через прокси, задайте logs_config.force_use_http: true.

Промежуточный сервер-ретранслятор

В этом варианте агент не знает о прокси: в его конфигурации вместо адреса бэкенда указывается адрес промежуточного сервера, который пересылает соединения на ProtoOBP Backend. В примере ниже ретранслятором служит Nginx с модулем stream: он принимает соединения агента по HTTP на порту 80 и открывает TLS-соединение к бэкенду на порту 443.

1. Настройте прокси-сервер. Минимальная конфигурация Nginx:

   user www-data;
   worker_processes auto;
   error_log /var/log/nginx/error.log;
   pid /run/nginx.pid;
   load_module /usr/lib/nginx/modules/ngx_stream_module.so;
   
   events {
       worker_connections 1024;
   }
   
   stream {
   
       server {
           listen 80;
           proxy_ssl_verify off;
           proxy_ssl on;
           proxy_pass proto-backend:443;
       }
   }
   

   Где proto-backend – адрес вашего бэкенд сервера.

2. Настройте агента. В используемых адресах вместо адресов бэкенда укажите адрес прокси-сервера:

   api_key: your-api-key
   pobp_url: http://nginx-proxy
   skip_ssl_validation: true
   apm_config:
     apm_non_local_traffic: true
     apm_pobp_url: http://nginx-proxy
     telemetry:
       enabled: false
   database_monitoring:
     metrics:
       pobp_url: nginx-proxy
     activity:
       pobp_url: nginx-proxy
     samples:
       pobp_url: nginx-proxy
   

   Где nginx-proxy – адрес вашего прокси-сервера.

   Если агент собирает логи, укажите адрес ретранслятора и для них: logs_config.logs_pobp_url: http://nginx-proxy. Адрес со схемой http:// или https:// переводит отправку логов в режим HTTP.

3. Примените изменения, перезапустив агента.

Проверка работы

1. Выполните protoobp-agent status (команды для других платформ — в разделе Проверка работы агента). В блоке Forwarder не должно быть ошибок отправки, в блоке APM Agent — ошибок записи трейсов, в блоке Logs Agent — ошибок подключения.
2. Если данные не поступают, включите подробный журнал (log_level: debug в protoobp.yaml) и найдите в журнале агента строки Using proxy: в них видно, какой прокси выбран для каждого адреса назначения. Если таких строк нет, для схемы адреса бэкенда прокси не задан — см. Какой прокси выбирается для запроса.
3. Ответ прокси 407 Proxy Authentication Required означает неверный логин или пароль либо незакодированные специальные символы в них.
4. После проверки верните прежний log_level.