[syslog-ng] Run 2 syslog-ng by defferent configurations

Evan Rempel erempel at uvic.ca
Tue Dec 25 07:50:00 CET 2007


We do this all of the time.
The only thing to ensure is that the "high availablity" instance does not
open /dev/log or /proc/kmsg. You will have to get the "system" instance that
is reading /dev/log and /proc/kmsg to send its logs through to the High Availablity
instance. We do this in different ways for different purposes. Choose only one.

1. Have the high availability read messages from localhost:someport
    where someport is NOT 514. Then have the system instance have a
    TCP destination of localhost:someport

2. Have the high availablity read message from a pipe that has been
    setup with mkfifo prior to starting the instance.
    Then have the system instance write to the pipe as one of its outputs.

That should take care of it.

Evan.

Takenaka Kazuhiro wrote:
> Hi all.
> 
> I would like to run 2 syslog-ng instances in the same server
> and tried it, but encounterd a problem. I have some questions,
> please advise me something you know about this.
> 
> Firstly, I run a syslog-ng 1.6.8 instance on Redhat EL4 update 5
> by a install default configuration file.
> 
> And then I run the other instance by the following configuration:
> ------------------------------------------------------------
> source s_udp_9000 { udp(port(9000)); };
> 
> filter f_host_XXX {
>         host ("[xX][xX][xX]11|172\.20\.100\.100"); };
> 
> destination d_udp_messages_XXX {
>         file("/dbf/heartbeat/XXX.log" create_dirs(yes) perm(0640)); };
> 
> log {
>         source(s_udp_9000);
>         filter(f_host_XXX);
>         destination(d_udp_messages_XXX); };
> ------------------------------------------------------------
> 
> The operations proceeded as the following.
> 
> # service syslog-ng start
> Starting system logger:   [ OK ]
> # syslog-ng -p /var/run/syslog-ng-vip.pid -f syslog-ng-vip.conf
> Warning: No source refers to internal messages, they'll go to /dev/null
> 
>   My first question is :
>     1. Does syslog-ng 1.6.8 always handle internal messages ?
>        I suspict it will cause odd behaviors on logging internal
>        messages when multiple syslog-ng instances run on a server.
>        Or are there some effective configurations to avoid this ?
> 
> Next, I updated the version of syslog-ng to 2.0.4 and played
> same operations. No warnings were shown on the terminal.
> 
>   My second question is :
>     2. Can syslog-ng 2.0.4 ignore internal messages if the
>        configurations specify that it shuld run so ?
>        I think it means run multiple instances can run on a
>        server safely.
>        Or do some problems hide behind the silence ?
> 
> ===========================================================
> I'd better to explain what makes me try such configurations
> I mentioned to help readers understand my demand.
> 
> I plan to sent my servers' logs to a central syslog-ng server.
> To make my syslog-ng server a high avalable one, I decided to
> use Heartbeat as a HA manager to make a ACT/SBY syslog-ng cluster.
> 
> I also decided to use shared disks so as to save external logs
> into them and make external log files be taken over on a failover
> by them.
> 
> On the other hand, I intend to save central server's own logs
> into server's internal disks.
> 
> I think it would be better to run 2 syslog-ng instances and
> assign one to handle internal logs and the other to handle
> external logs. The internal one shuld be managed by a rc script
> and the external should be managed by Heartbeat.
> 
> The reason I think this way, or the reason I avoid handling
> all messages by one instance, is the following.
> 
> Hearteat alway performs a stop operation on eash resources
> that Hearteat just attempt to failover. If Heartbeat manages
> the syslog-ng instance which handles all logs, and a failover
> is triggered by some reason except syslog-ng's own corruption,
> Heartbeat brings a stop to the syslog-ng instance.
> 
> This means internal logging must stop in the very time
> some troubles occurs. It obviously is unpreferable.
> ===========================================================
> 
> Sincerely.



More information about the syslog-ng mailing list