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

Takenaka Kazuhiro takenaka.kazuhiro at oss.ntt.co.jp
Wed Dec 26 00:11:46 CET 2007


Hi Evan, Thanks for your advises.

I will give a try on them later.

> 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.
> 
> _______________________________________________
> syslog-ng maillist  -  syslog-ng at lists.balabit.hu
> https://lists.balabit.hu/mailman/listinfo/syslog-ng
> Frequently asked questions at http://www.campin.net/syslog-ng/f
-- 
Takenaka Kazuhiro <takenaka.kazuhiro at oss.ntt.co.jp>
NTT OSS Center


More information about the syslog-ng mailing list