[rsyslog-notify] Forum Thread: Re: Rsyslog queues and performance impacts - (Mode 'reply')

[noreply at adiscon.com]

User: dlang 
Forumlink: http://kb.monitorware.com/viewtopic.php?p=24888#p24888

Message: 
----------
If you don't set a working directory, rsyslog will not guess, so you don't
have the disk queue active (it's probably logging this at startup)

you really want to get on something newer than 4.x

on your other questions:

1. the data is considered sent when it's handed to the OS, but the OS has a
limited window of data that it will accept from a program for any one
connection, if it's sending data fast enough, you never see this. If it's
not, your program will block.

If the tcp connection is just stalled and recovers, data will get through
in bursts.

If the tcp connection gets terminated (times out, or received a close from
the far side or a firewall in the middle), all data handed to the OS will
be lost, the sending rsyslog think's it's been sent, the receiving rsyslog
never got it, and the OS that has it has no way to do anything with it.

It all depends on exactly what is happening on your network.

RELP was invented specifically to address this issue, but you don't want to
try and run RELP on 4.x

Does this clarify this situation?

2. they are all equal actions, but what you aren't realizing is that
rsyslog takes a log message (technically a batch of log messages, but for
discussion I'll say one) and it goes through all the actions to deliver the
message

If you have no queue (are operating in direct mode), a log message will get
written to the first two destinations, and then try to deliver it to
server1 and sit there, it will never get to the point of trying to deliver
it to server2

If you have an action queue defined, the message gets delivered to that
queue (assuming it's not full) and rsyslog continues on to the next action
(with a different thread reading from the queue)

Beyond that, you can configure a limited number of retries, so that rsyslog
will only try for a while to deliver a message before it gives up and moves
on to the next action.

So no, listing two servers like this will not get the messages through.
There are ways to set failure modes and say "if the last action failed, do
this action", but that's getting messy :-)

The best answer isn't to try and do the redundancy on the client side, but
instead do it on the server or network side.