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@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@oss.ntt.co.jp> NTT OSS Center