LINUX.ORG.RU
ФорумAdmin

rsyslog failover

 ,


0

1

Уважаемые форумчане, #как настроить failover с использованием rsyslog?

Пусть:

  • 10.0.0.1 - основной сервер логирования.

  • 10.0.0.2 - резервный сервер логирования.

  • 10.0.0.11 - клиент 1

  • 10.0.0.12 - клиент 2

На серверах примитивная конфигурация:

(вырезал пустые строки и комментарии)

$ModLoad imudp
$UDPServerRun 514
$ModLoad imtcp
$InputTCPServerRun 514
$WorkDirectory /var/lib/rsyslog
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
$IncludeConfig /etc/rsyslog.d/*.conf
$OmitLocalLogging on
$IMJournalStateFile imjournal.state

$template RemoteLogs,"/var/log/hosts/%HOSTNAME%/%PROGRAMNAME%/%$now%.log"
*.* ?RemoteLogs
& ~

*.info;mail.none;authpriv.none;cron.none /var/log/messages
authpriv.* /var/log/secure
mail.* -/var/log/maillog
cron.* /var/log/cron
*.emerg :omusrmsg:*
uucp,news.crit /var/log/spooler
local7.* /var/log/boot.log
$FileCreateMode 0640

На клиентах пробую:

  1. отправить сообщение с помощью logger

logger -n 10.0.0.1 -d -P 514 test1

logger -n 10.0.0.2 -d -P 514 test2

сообщения успешно попадают в логи серверов.

Переходим к тестированию failover

  1. конфигурации:

в конфигурацию 10.0.0.11

добавлено:

ruleset(name="sendToLogServer") {
    action(type="omfwd" Target="10.0.0.1" Port="514" )
    action(type="omfwd" Target="10.0.0.2" Port="514" 
            action.execOnlyWhenPreviousIsSuspended="on" queue.dequeuebatchsize="1")
}
call sendToLogServer

на 10.0.0.1 прилетают логи, раскладываются и всё замечательно.

в конфигурацию 10.0.0.12 добавлено:

(legacy)

*.* @@10.0.0.1:514 $ActionExecOnlyWhenPreviousIsSuspended on 
& @@10.0.0.2:514 $ActionExecOnlyWhenPreviousIsSuspended off

на 10.0.0.1 прилетают логи, раскладываются и всё тоже замечательно.

теперь опускаем на 10.0.0.1 rsyslog. и в логах 10.0.0.2 нет ничего.

Те не работает, не зависимо от типа используемого конфига. Я что-то не доделал. Куда копать?

rsyslogd -v
rsyslogd 8.24.0-41.el7_7.2, compiled with:
    PLATFORM:                               x86_64-redhat-linux-gnu
    PLATFORM (lsb_release -d):
    FEATURE_REGEXP:                         Yes
    GSSAPI Kerberos 5 support:              Yes
    FEATURE_DEBUG (debug build, slow code): No
    32bit Atomic operations supported:      Yes
    64bit Atomic operations supported:      Yes
    memory allocator:                       system default
    Runtime Instrumentation (slow code):    No
    uuid support:                           Yes
    Number of Bits in RainerScript integers: 64

чувак, а кто за тебя будет настраивать очередь ( с дропом при переполнении ) ? макском ?

router ★★★★★ ()
Ответ на: комментарий от router

точнее, не очередь ( main queue ), а очереди ( queue with a ruleset )

внимательно прочитай https://www.rsyslog.com/doc/v8-stable/whitepapers/queues_analogy.html - сразу поймёшь, почему остановка первого сервера приводила к тому, что второй ничего не получал

потом уже подробности по настройке https://www.rsyslog.com/doc/v8-stable/concepts/queues.html

router ★★★★★ ()
Ответ на: комментарий от DonkeyHot

Поддерживаю. Отправляй сразу в оба, а вот на коллекторах уже делай логику откуда куда потоки переводить.

stave ★★★★★ ()
Ответ на: комментарий от DonkeyHot

Предложение здравое, но в данном случае это не поможет.
Например, при таком конфиге, если ляжет loghost1, то на loghost2 ничего не пойдет.

*.*  @@loghost1
*.*  @@loghost2

Тут действительно надо разбираться с очередями.

bigbit ★★★★★ ()
Ответ на: комментарий от router

Благодарю!

Понимания прибавилось, но ясности не наступило, я так и не понял:

  • как определить, что очередь зависла?
  • и как с этим связаны drop’ы?

А это я не разгадал «макском» :(

Переделал серверную часть:

template(name=«tRemoteLogs» type=«list») { 
    constant(value=«/var/log/hosts/») property(name=«hostname») 
    constant(value=«/») property(name=«programname») 
    constant(value=«/») property(name=«$now») 
    constant(value=«.log») }

ruleset(name="RemoteLogs"
   queue.type="LinkedList"
   queue.size="200000"
   queue.dequeueBatchSize="4096"
   queue.workerThreads="4"
   queue.workerThreadMinimumMessages="50000"
   ) {
   action(type="omfile" dynaFile="tRemoteLogs"
        ioBufferSize="64k" flushOnTXEnd="off"
        asyncWriting="on")
   }

Но проблема была не в ней, а в клиентской части, тут я до конца не разобрался. Теперь так:

ruleset(name="sendToLogServer") {
action(
  Name="Primary"
  Type="omfwd"
  Target="10.0.0.1"
  Port="514"
  Queue.workerThreads="2"
  Queue.type="LinkedList"
  Queue.FileName="primary-buffer"
  Queue.SaveOnShutdown="on"
  Queue.dequeuebatchsize="1"
  Action.ResumeInterval="10"
  Action.ResumeRetryCount="-1" )
action(
  Name="failover"
  Type="omfwd"
  Target="10.0.0.2"
  Port="514"
  Queue.workerThreads="2"
  Queue.type="LinkedList"
  Queue.FileName="failover-buffer"
  Queue.dequeuebatchsize="1"
  Queue.SaveOnShutdown="on"
  Action.execOnlyWhenPreviousIsSuspended="on"
  Action.ResumeInterval="10"
  Action.ResumeRetryCount="-1")
}

call sendToLogServer
alikhotin ()

Забыл написать для истории. Нашёл в документации выдержку:

… Important: Failover will not work when you define queues on the actions. This is because a queue explicitely tells rsyslog that the action shall be processed asynchronously. With asynchronous processing you do not have any feedback capability. As such, the action will never fail.

Она несколько ставит под сомнение полезность сделанных комментариев, но всё равно спасибо! Работает отлично! PS. ещё в SSL обернул, замечательная штука rsyslog.

alikhotin ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.