syslog-ng: Как уменьшить высокую задержку при пересылке журналов потребителю syslog tcp?

ОБНОВЛЕНИЕ 2: Я ответил на этот вопрос через свой новый вопрос по ссылке ниже. Основная причина — поведение Telegraf, при котором по умолчанию он разрывает TCP-соединение через 5 секунд после последнего полученного сообщения. Это может быть намеренно, однако у меня есть проблема с их документацией, из-за которой мне трудно найти потенциальное решение.

Возможно, теперь этот вопрос можно удалить?

ОБНОВЛЕНИЕ 1: вместо того, чтобы широко редактировать этот вопрос, делая текущие ответы бессмысленными, я задал новый вопрос, основанный на новой информации, которую я получил в результате публикации этого вопроса.

syslog-ng / telegraf: EOF произошел во время простоя – несовместимо?

Я использую syslog-ng Open-Source Edition (OSE) v3.31.2 в стеке docker-compose.

У меня есть сообщения системного журнала, поступающие по сети с разных хостов через UDP (чем я ограничен, потому что мои клиенты используют Boost::Log, и он не поддерживает системный журнал через TCP, только UDP), и у меня настроен syslog-ng на пересылку их в другую нижестоящую службу. Это телеграф, использующийinputs.syslog mod , но я пока не уверен, что это имеет значение.

Моя конфигурация выглядит так:

      @version: 3.29
@include "scl.conf"

options {
    flush-lines(1);
};
    
source s_network {
    udp(ip(0.0.0.0) port(514));
};

destination d_file {
    file("/var/log/messages");
};
    
destination d_telegraf {
    syslog("telegraf" port(6514) transport(tcp));
};
    
log {
    source(s_network);
    destination(d_telegraf);
    destination(d_file);
};

Я явно установил глобальноеflush-linesзначение равно 1. Я думаю, что это значение по умолчанию, но я хочу быть уверенным. Я хочу, чтобы сообщения журнала пересылались сразу после их получения.

Большую часть времени это работает — отдельные «строки» логов поступают в syslog-ng по UDP 514, и тут же записываются в файл, а также почти во всех случаях они также сразу пересылаются в телеграф на TCP-порт 6514.

Проблема, которую я вижу, заключается в том, что довольно часто syslog-ng задерживает многие строки входящих журналов примерно на 30-60 секунд, а затем доставляет их в телеграф большим куском. Кажется, что в этом нет особой закономерности, но такое случается часто. Странно то, что/var/log/messagesв файле немедленно записываются недостающие записи журнала, задерживается только доставка по сети. Я думал, чтоflush-lines(1)хотел бы избежать этой буферизации, но, похоже, это не так.

Я использовал Wireshark, чтобы определить, где находится задержка: она связана с выводом пакетов из syslog-ng между syslog-ng и TCP-портом 6514 телеграфа.

Мне действительно интересно, может ли это быть связано с алгоритмом TCP Nagle - если да, то есть ли способ включить опцию сокета TCP_NO_DELAY для драйвера назначения системного журнала syslog-ng?

В конечном счете, я ищу быстрый сервис системного журнала с малой задержкой, который может собирать и ретранслировать журналы как можно быстрее для последующего просмотра в реальном времени.

РЕДАКТИРОВАТЬ: я попробовал переключиться на UDP-транспорт между системным журналом ng и телеметрией, и это кажется гораздо более отзывчивым, а длинные случайные задержки исчезли. Однако это затруднит обеспечение безопасности соединения в будущем.