Настройка сервиса Log-proxy

Общие данные

Log-proxy – сервис, который отвечает за быструю пересылку событий, пришедших от лог-коллектора в сервис Kafka.

Основные характеристики сервиса:

• используется только один порт для приема сообщений от всех лог-коллекторов (по умолчанию 1100);
• реализовано сжатие данных при передаче от лог-коллекторов.

Начиная с версии 3.7.2 Платформы Радар сервис Log-proxy используется в качестве замены сервиса Rsyslog.

При включенном сервисе все события от лог-коллектора будут заворачиваться в websocket, который работает по аналогии с компонентами отправки событий (секция output), но в один порт. События будут отправляться по указанному URL из включенных TCP/UDP компонентов отправки событий (секция senders). К нормализованным и разобранным событиям будет добавляться поле с соответствующим id, который задается в конфигурации сервиса Log-proxy через веб-интерфейс платформы (см. раздел Включение пересылки событий через сервис Log-proxy).

Включение пересылки событий через сервис Log-proxy

Если Платформа Радар работает в обычной инфраструктуре, то сервис Log-proxy включен по умолчанию и не требует дополнительных настроек.

Если Платформа радар работает в инфраструктуре мультитенант или мультиарендность, необходимо настроить пересылку событий из подчиненных инстансов.

Для включения пересылки событий через сервис Log-proxy выполните следующие действия:

1. В веб-интерфейсе платформы перейдите в раздел Администрирование → Кластер → вкладка Управление конфигурацией.

2. Проверьте настройки сервиса Log-proxy. Для этого в древовидном списке параметров сервисов выберите Logproxy (см. рисунок 1).

   

   Рисунок 1 – Управление конфигурацией сервиса Log-proxy

   При необходимости переопределите следующие параметры:

   • Порт приема сообщений – параметр определяет порт, который слушает сервис для приема сообщений от лог-коллектора. По умолчанию 1100;
   • Message ID приема событий верхнеуровневой корреляции – параметр определяет идентификатор (id) сообщения, которое отправляется в очередь нормализованных событий. По умолчанию 9999;
   • Message ID приема разобранных событий – параметр определяет идентификатор (id) сообщения, которое отправляется в очередь разобранных событий. По умолчанию 9998.

3. Включите пересылку событий. Для этого в древовидном списке параметров сервисов выберите FlowBalancer → Head и установите параметр Пересылать события в значение true (см. рисунок 2).

   

   Рисунок 2 – Управление конфигурацией сервиса FlowBalancer

   При необходимости переопределите следующие параметры:

   • Ip LogProxy – внешний IP-адрес сервиса Log-proxy;
   • Порт LogProxy – внешний порт сервиса Log-proxy;
   • ID события для нормализованных событий LogProxy – идентификатор (id) нормализованного события, пришедшего от сервиса (Logproxy.NormalizedMessageId);
   • ID события для разобранных событий LogProxy – идентификатор (id) разобранного события пришедшего от сервиса (Logproxy.ParsedMessageId).

4. После внесения изменений нажмите кнопку Записать конфигурацию.

5. Создайте фильтры для пересылки событий.

   Внимание! Необходимо настроить фильтры для максимальной фильтрации событий. Чем больше событий будет отфильтровано, тем меньше будет нагрузка на устройство и тем больший поток сможет пройти..

6. В конфигурационном файле config.yaml включите пересылку событий в сервис Log-proxy:

   log_proxy:
     # включить пересылку событий в LogProxy
     enable: true
     # Url-сервиса для приема
     url: "ws://<ip адрес Платформы Радар>:1100/"
     # Отключить проверку сертификата
     skip_verify: true
     write_buffer_size: 10000
     read_buffer_size: 10000
     ping_interval_sec: 30
     reconnect_interval_sec: 10    
   

   Где:

   • enable – опция, включающая пересылку событий в сервис Log-proxy. Возможные значения:

     • true – опция включена;
     • false – опция выключена.

   • url – URL сервиса Log-proxy;

   • skip_verify – опция, позволяющая пропустить шаг проверки сертификата. Возможные значения:

     • true – опция включена;
     • false – опция выключена.

   • write_buffer_size – размер буфера, который будет использоваться для записи событий;

   • read_buffer_size – размер буфера, который будет использоваться для чтения событий;
   • ping_interval_sec – интервал в секундах, через который будут отправляться пакеты для проверки соединения;
   • reconnect_interval_sec – интервал, который указывает, через сколько секунд после потери соединения сервис будет пытаться его восстановить.

Пример конфигурации

cluster:
  url: "https://172.30.254.79:9000/cm/api/agent/"
  api_key: "57dbc2b0-41e8-0f55-95d8-1c19c2e44347"
  skip_verify: true

controller:
  port: 48000
  log_level: "INFO"
  disk_space_check_sec: 60

metric_server:
  log_level: "DEBUG"
  port: 48005

log_proxy:
  enable: true
  url: "ws://172.30.254.79:8098"
  skip_verify: true

secret_file: "secret"
secret_storage: "secret.storage"

api_server:
  address: "10.30.253.22"
  port: 8085
  read_timeout: 60
  write_timeout: 60
  wait: 5
  cert_key_pass: ""
  require_client_cert: false
  ca_file: "certs/pgr.crt"
  log_level: "INFO"

journal:
  port: 48004
  log_level: "INFO"
  log_path: "journal.log"
  rotation_size: 30
  max_backups: 7
  max_age: 7

tcp_sender_1514: &tcp_sender_1514
  id: "tcp_sender_1514"
  target_host: "172.30.254.79"
  port: 1514
  batch_mode_enable: false
  batch_flush_interval: 5
  batch_flush_limit: 500
  ssl_compression: false
  require_cert: false
  ssl_enable: false
  cert_file: "certs/server.crt"
  key_file: "certs/server.key"
  cert_key_pass: ""
  ca_file: "certs/ca.crt"
  log_level: "INFO"

tcp_receiver: &tcp_receiver
  id: "tcp_receiver"
  host: "127.0.0.1"
  port: 1551
  log_level: "INFO"
  connections_limit: 10
  format: "json"

senders:
  port: 48002
  log_level: "INFO"
  tcp:
    - <<: *tcp_sender_1514

collectors:
  log_level: "INFO"
  tcp_receiver:
    - <<: *tcp_receiver

route_1: &route_1
  collector_id:
    - "tcp_receiver"
  sender_id:
    - "tcp_sender_1514"

routers:
  - <<: *route_1

Маршрутизация событий

Настройка выполняется в конфигурационном файле сервиса Log-proxy – config.json.

Расположение файла: opt/pangeoradar/configs/logproxy/config.json.

Необходимо переопределить параметры маршрутизации событий (секция router) следующим образом:

router: 
    {"log_collector_id": 
        {
        "name":"input_name",
        "template":"template_name", 
        "broker":"URL KAFKA", 
        "topic": "topic_name"
        }
    }

Где:

• log_collector_id – значение id от лог-коллектора;
• name – наименование источника событий;
• template – наименование шаблона для обработки сообщений;
• broker – IP-адрес и порт сервиса Kafka;
• topic – наименование топика, в который будет выполняться запись.

Для включения шаблона для обработки сообщений необходимо добавить секцию templates:

templates: 
    {"template_name": "output_template"},

Где:

• template_name – наименование шаблона для обработки сообщений, которое указывается в параметрах секции router;

• output_template – результирующая строка, в которую надо подставить значения от лог-коллетора с соответствующим преобразованием. В параметре используются следующие переменные:

  • %FROMHOST-IP% – IP-адрес лог-коллектора, отправившего запрос;
  • %timegenerated:::date-rfc3339% – дата приема сообщения в формате rfc3339;
  • %inputname% – имя источника из секции router.

Примечание: в настройках шаблона доступен для ввода только тип данных json и соответствующее преобразование: json-json.

Пример настройки:

router: 
    {"1519": 
        {
        "name": "1514-Microsoft-Windows-Eventlog",
        "template": "json-json", 
        "broker": "127.0.0.1:9092", 
        "topic": "1514-Microsoft-Windows-Eventlog"
        }
    }

templates: {
    "json-json":"{\"rs_relay_ip\":\"%FROMHOST-IP%\",\"rs_collector_ts\":\"%timegenerated:::date-rfc3339%\",\"__rs_module\":\"%inputname%\",%rawmsg:2:$:%",
    }

Настройка журналирования сервиса Log-proxy

Уровень детализации ведения журналов работы сервиса Log-proxy (pangeoradar-logproxy.service) настраивается параметром logLevel при запуске сервиса. Возможные значения:

• 0 – журналирование отключено;
• 1 – выводить только информационные сообщения;
• 2 – выводить только предупреждения;
• 3 – выводить только критические ошибки;
• 4 – выводить информационные сообщения и предупреждения;
• 5 – выводить информационные сообщения и критические ошибки;
• 6 – выводить предупреждения и критические ошибки;
• 7 – выводить все сообщения.

Значение по умолчанию: 3 – выводить только критические ошибки.

Примечание: аналогичные настройки журналирования используются в параметрах запуска сервиса Termite.