Соединение системного журнала с Logstash не сбрасывается

У нас есть установка с одним сервером Logstash (1.4.2, использующая встроенный Elasticsearch) для получения журналов от ряда других клиентов (через TCP и от их rsyslogd экземпляры). Одна проблема, которая теперь повторяется, состоит в том, что одно за другим сообщения от хостов больше не принимаются, однако нигде нет сообщений об ошибках.

По сути, похоже, что хост Logstash не может обработать количество входящих сообщений, а соединения остаются в странном состоянии; я сделал lsof/strace на клиенте rsyslogd экземпляры, а также захватили некоторый трафик как на клиентах, так и на сервере, и кажется, что в то время как клиенты все еще имеют открытое соединение:

rsyslogd 30088 syslog    1u  IPv4           14878202       0t0        TCP 10.129.X.X:47492->10.129.X.X:5544 (ESTABLISHED)

, то соединение в основном как сервер (порт) 5544) отправляет сообщения TCP Zero Window, которые, как мне рассказывает Wireshark, в основном не поддерживают Logstash (загрузка ЦП на хосте не всегда максимальная, но регулярно около 75% на всех четырех ядрах).

Мой вопрос таков: есть ли флаг / настройка / ..., чтобы получить rsyslogd демоны для отключения / переподключения в такой ситуации или для Logstash правильно закрыть соединения, если он не может идти в ногу? (Это известная проблема? Потому что я не смог найти ни одной релевантной ссылки.)

Изменить: тем временем мы изменили плагин ввода на tcp вместо syslog, который вместе с руководством grok Разбор, кажется, справиться с нагрузкой лучше. Я все еще хотел бы понять оригинальную проблему все же.

Источник

1 ответ

Вот параметры, которые вы ищете:

      Action.ResumeInterval="30"
Action.ResumeRetryCount="-1"

Здесь вы можете найти все доступные параметры.

Это пример общего rs:

      ruleset(name="myruleset_name"){
    action(
    type="omfwd"
    Target="destination_fqdn_ip"
    Port="destination_port"
    Protocol="tcp"
    Action.ResumeInterval="30"
    Action.ResumeRetryCount="-1"
    )
    stop
}

Обратите внимание, что на самом деле проблема связана с dst: сервер logstash не справляется с входящей нагрузкой (вывод rsyslog), поэтому вам следует внимательно посмотреть на dst-сервер. Повторяющееся нулевое окно TCP является огромной проблемой, поскольку оно потенциально приводит к потере данных (накладные расходы на буфер), пикам и спадам данных, данным не в режиме реального времени и т. д.

Надеюсь, это поможет.

Источник
Другие вопросы по тегам