Почему syslogd не сообщает сообщения на удаленном сервере во время и сразу после загрузки?

Я настроил rsyslog для отправки журналов на центральный сервер ведения журнала следующим образом:

 *.* @@192.168.1.20 $ActionExecOnlyWhenPreviousIsSuspended on & @@192.168.1.21 & /var/log/failover $ActionExecOnlyWhenPreviousIsSuspended off 

Он работает хорошо, за исключением случаев, когда машина загружается. Когда виртуальная машина запускается и примерно через двадцать секунд после запуска машины, никакие сообщения не отправляются на 192.168.1.20 или 192.168.1.21. Тем не менее, /var/log/failover содержит все эти «потерянные» сообщения.

В качестве теста я запустил машину и ввел ее вручную:

 $ logger 1 $ logger 2 $ logger 3 ... 

Первый центральный сервер протоколирования содержит только:

 Nov 28 13:57:40 demo arsene: 10 

Второй сервер протоколирования не содержит сообщений с demo машины.

Наконец, var/log/failover на demo машине содержит:

 Nov 28 13:57:10 demo rsyslogd: [origin software="rsyslogd" swVersion="7.4.4" x-pid="361" x-info="http://www.rsyslog.com"] start Nov 28 13:57:10 demo rsyslogd: rsyslogd's groupid changed to 104 Nov 28 13:57:10 demo rsyslogd: rsyslogd's userid changed to 101 ... # more than a hundred usual messages from the kernel Nov 28 13:57:20 demo kernel: [ 12.127981] random: nonblocking pool is initialized Nov 28 13:57:21 demo arsene: 1 Nov 28 13:57:22 demo arsene: 2 Nov 28 13:57:23 demo arsene: 3 Nov 28 13:57:25 demo arsene: 4 Nov 28 13:57:27 demo arsene: 5 Nov 28 13:57:28 demo arsene: 6 Nov 28 13:57:30 demo arsene: 7 Nov 28 13:57:32 demo arsene: 8 Nov 28 13:57:37 demo arsene: 9 

Я столкнулся с этой проблемой как для виртуальных машин Ubuntu, так и для Debian.

Дополнительные замечания:

  1. Сетевое подключение выглядит отлично. Если я попытаюсь ping 192.168.1.20 и curl google.com в течение периода, когда сообщения журнала не отправляются на сервер журнала, ping как ping и curl .

  2. Отключение брандмауэра сервера регистрации не влияет.

  3. Запуск tcpdump показывает, что ничто не отправляется на сервер журнала в течение 20 секунд.

  4. Другие компьютеры Ubuntu в сети (которые были развернуты с использованием совершенно другого подхода) сообщают о своих журналах на сервере регистрации, в том числе во время загрузки.

  5. Сравнив неисправные машины с правильными, я заметил несоответствие версии (7 против 8) для rsyslogd . Обновление rsyslogd на неисправных машинах до версии rsyslogd проблему, но теперь я вижу следующее сообщение после начала работы отчета журнала:

     Nov 29 02:18:39 demo rsyslogd-2359: action 'action 11' resumed (module 'builtin:omfwd') [v8.14.0 try http://www.rsyslog.com/e/2359 ] 
  6. diff показывает, что файлы /etc/rsyslog.conf и /etc/rsyslog.d/*.conf точно совпадают между новыми неисправными машинами и старыми рабочими.

  7. apt-get update , apt-get upgrade и даже apt-get dist-upgrade не устранили проблему.

Как сказал @ThomasDickey, создание сети может не быть полностью запущено при запуске программ пользовательской программы. Многие сетевые коммутаторы предприятия не принимают пакеты в течение нескольких секунд после появления интерфейса, поскольку они пытаются согласовать параметры spanning tree.

У rsyslog есть параметр actionresumeinterval, который по умолчанию равен 30 секундам. Если вы установите его на меньшее значение перед любыми директивами, использующими TCP-соединения, это увеличит скорость повтора, и соединения должны завершиться быстрее.

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

 $ActionResumeInterval 5 $ActionQueueType disk $WorkDirectory /var/spool/rsyslog $ActionQueueFilename actionRq $ActionQueueMaxDiskSpace 1m $ActionQueueSize 4000 $ActionQueueTimeoutEnqueue 0 $ActionResumeRetryCount -1 

Вероятно, сеть не полностью началась за эти 20 секунд. Пока это не произойдет, rsyslog не с кем поговорить, поэтому он написан локально.