ОБНОВЛЕНИЕ 2: я ответил на этот вопрос в своем новом вопросе по ссылке ниже. Основной причиной является поведение телеграфа, когда по умолчанию он отключает TCP-соединение через 5 секунд после последнего полученного сообщения. Это может быть задумано, однако у меня есть проблема с их документацией, из-за которой мне трудно определить это как потенциальное исправление.
Может быть, теперь этот вопрос можно удалить?
ОБНОВЛЕНИЕ 1: вместо того, чтобы широко редактировать этот вопрос, делая текущие ответы бессмысленными, я задал новый вопрос, основанный на новой информации, которую я получил в результате публикации этого вопроса.
syslog-ng / telegraf: EOF произошел при простое - несовместимо?
Я использую syslog-ng Open-Source Edition (OSE) v3.31.2 в стеке создания докеров.
У меня есть сообщения системного журнала, поступающие по сети с разных хостов через UDP (что я ограничен, потому что мои клиенты используют Boost::Log, и это не поддерживает системный журнал через TCP, только UDP), и у меня есть syslog-ng для пересылки их к другой службе ниже по течению. Это телеграф, использующий inputs.syslog модуль, но я пока не уверен, что это имеет значение.
Мой конфиг выглядит так:
@версия: 3.29
@include "scl.conf"
параметры {
флеш-линии (1);
};
источник s_network {
udp (ip (0.0.0.0) порт (514));
};
целевой d_file {
файл("/var/журнал/сообщения");
};
пункт назначения d_telegraf {
syslog («телеграф» порт (6514) транспорт (tcp));
};
журнал {
источник (s_network);
пункт назначения (d_telegraf);
пункт назначения (d_file);
};
Я явно установил глобальный линии смыва значение 1. Я думаю, что это значение по умолчанию, но я хочу быть уверенным. Я хочу, чтобы сообщения журнала пересылались сразу после их получения.
Чаще всего это работает — отдельные «строчки» логов поступают в syslog-ng по UDP 514, и тут же записываются в файл /var/журнал/сообщения, и почти во всех случаях тоже сразу пересылаются в телеграф на TCP-порт 6514.
Проблема, которую я вижу, заключается в том, что довольно часто syslog-ng сдерживает многие строки входящих журналов примерно на 30-60 секунд, а затем доставляет их в телеграф большим куском. Кажется, что в этом нет особой закономерности, но это происходит часто. Странно то, что /var/журнал/сообщения файл имеет отсутствующие записи журнала, записанные немедленно, просто задерживается доставка по сети. Я думал, что линии заподлицо(1) позволит избежать этой буферизации, но, похоже, это не так.
Я использовал Wireshark, чтобы определить, где находится задержка, и она находится в выводе пакетов из syslog-ng между syslog-ng и TCP-портом 6514 телеграфа.
Я действительно задавался вопросом, может ли это быть связано с алгоритмом TCP Nagle - если да, то есть ли способ включить параметр сокета TCP_NO_DELAY для драйвера назначения системного журнала syslog-ng?
В конечном счете, я ищу быструю службу системных журналов с малой задержкой, которая может собирать и передавать журналы как можно быстрее для последующего просмотра в реальном времени.
РЕДАКТИРОВАТЬ: я попытался переключиться на транспорт UDP между syslog-ng и телеметрией, и это кажется гораздо более отзывчивым, и длительные случайные задержки исчезли. Однако это затруднит безопасное соединение в будущем.
