Configure failover for rsyslog

[Kenneth Holter]

We're running rsyslog 2.0.6 downloaded from RHN, and are about to set up
reliability/failover. I've found two setup tutorials for this:


   1. http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html
   2. http://wiki.rsyslog.com/index.php/FailoverSyslogServer

It seems like both setups configure reliable transfer, but using a
completely different syntax. Is it so that the former one is the syntax for
newer versions of rsyslog?




Regards,
Kenneth


On 1/26/09, Kenneth Holter <kenneho.ndu at gmail.com> wrote:
>
> Hello list.
>
>
> I'm planning on setting up rsyslog servers (i.e. loghosts) to store syslog
> messages from the various RHEL clients in the network. So far I have one
> "master" server, and one relay server who forwards syslog messages to the
> master server. The clients log either directly to the master, or to the
> relay server. In other words, this:
> Syslog clients ==> Relay rsyslog server ==> Master rsyslog server <==
Syslog
> clients
>
> It's possible to define failover behavior on the client side, either:
>
> Try one rsyslog server before spooling the messages
> Try two or more rsyslog servers before spooling the messages
> In the latter scenario one will need multiple failover rsyslog servers.
But
> since the clients are able to spool the messages, and forward them as soon
> as the rsyslog server comes back up, I'm thinking that one rsyslog server
> (one relay server and one master server, that is) will suffice. As long as
> the messages are just temporarily stored locally, no messages should be
> lost.
>
> Has anyone set up rsyslog (or other syslog-implementations) with failover
> functionality, and would like to comment on these alternatives?
>
> Furhtermore, our RHEL clients are currently running sysklogd, so if there
is
> some way of setting up failover syslog server without having to upgrade to
> rsyslog I'd appreciate a howto on this. I'm don't think this is a likely
> approach, since TCP (as is supported in the rsyslog implementation) seems
> like the best alternative when setting up failover.
>
> Regards,
> Kenneth Holter
>