MonitorWare Knowledge Base

Hi,

I'm having a problem with logs from rsyslog to syslog-ng can't detect facility so I can't separate applications, this is important, mostly because we have 2 instances of postrgres that need to be in separate logfiles.

Cheers,
Rob

Hmm maybe this helps, I really need to get this sorted, if anyone could help it would be great

rsyslog.conf

# PostgreSQL logging stuff
local0.* @loghost;RSYSLOG_TraditionalFileFormat
local1.* @loghost;RSYSLOG_TraditionalFileFormat


syslog-ng.conf
options
{
chain_hostnames(no);
create_dirs (yes);
dir_perm(0755);
keep_hostname(yes);
log_fifo_size(1024);
perm(0644);
sync(0);
time_reopen (10);
use_dns(yes);
use_fqdn(yes);
sync(0);
};


# Local logging and getting logs from remote via UDP
source net
{
udp();
tcp(port(5140) keep-alive(yes));
};

destination net_log { file("/var/log/hosts/${HOST}/${YEAR}/${MONTH}/${DAY}/syslog"); };
destination pgnet_log0 { file("/var/log/hosts/${HOST}/${YEAR}/${MONTH}/${DAY}/pgsql0"); };
destination pgnet_log1 { file("/var/log/hosts/${HOST}/${YEAR}/${MONTH}/${DAY}/pgsql1"); };

filter f_pgsql0 { facility(local0); };
filter f_pgsql1 { facility(local1); };

log { source(net); filter(f_pgsql0); destination(pgnet_log0); };
log { source(net); filter(f_pgsql1); destination(pgnet_log1); };

log { source(net); destination(net_log); };

Sorry, I had some trouble with the new forum and overlooked that post.

I have to admit I do not fully understand in which direction the problem is. The sender is rsyslog and the receiver is syslog-ng? If so, I would suggest you check with them why they do not understand the facility. I actually have no idea of how it work over there (I can even barely read the config...). Isn't it an option to simply replace syslog-ng by rsyslog?

Rainer

Thanks for the reply, my bosses want to keep syslog-ng running, at least in the short term as it works and the have confidence in it. Its mostly because these are live servers, and downtime MUST be kept to a minimum. Our hope is to eventually move these central logging servers from syslog-ng to rsyslog as the configuration files are MUCH easier to read.

btw the way I am sending the local0.* and local1.*, is this the best way to do it, or should i Just send everything from the database server to the central logging server, we don't need everything, but I'm thinking it MAY(although it will probably be the same) help the syslog-ng separate the facilities, what do you think?

I just noticed this:

# PostgreSQL logging stuff
local0.* @loghost;RSYSLOG_TraditionalFileFormat
local1.* @loghost;RSYSLOG_TraditionalFileFormat

RSYSLOG_TraditionalFileFormat is the log FILE format. Its not meant for forwarding. I guess that's the source of the problem. Replace it with RSYSLOG_TraditionalForwareFormat. Sorry I overlooked this on the initial post. The file format does not include the facility, so there is no way someone can detect it

Splitting via tow facilities is a good way to do it, and I'd always recommend to do so if you only need to differentiate between a couple of cases. I'd keep that.

A side-note: if you look at reliability, you should take into consideration that UDP syslog is very, very unreliable. I'd go at least for TCP based syslog, and suggest RELP when you finally can migrate to rsyslog. The reason is here:

http://rgerhards.blogspot.com/2008/04/o ... yslog.html

Please let me know if this works out.

Rainer

Just curious: Is the default now to forward messages with the new high-precision timestamp format? Or why is RSYSLOG_TraditionalForwardFormat required?

If this is actually the case, I'd say that for the sake of interoperability with other syslog servers, that the default should be RSYSLOG_TraditionalForwardFormat (be liberate what you accept and conservative what you send).

I overlooked this, you could simply have remove the template name. The default is traditional format, for the reasons you provided But please note that in your config you used file format!

Rainer

Oops, I just noticed that was not the original poster. Sorry, Michael. Answer is still true

Thank for that Rainer, I'll try it now! as for why we had the RSYSLOG_TraditionalFileFormat, we are using the stable rsyslog-3.14.2, and in that version it defaulted to the new high-precision timestamp format, which "shorted out" all our log tools.

Great it worked! thanks for all your help!

btw should we update to rsyslog 3.16.1 v3-stable? does it have some sweet fixes and cool features!

topnob wrote:Thank for that Rainer, I'll try it now! as for why we had the RSYSLOG_TraditionalFileFormat, we are using the stable rsyslog-3.14.2, and in that version it defaulted to the new high-precision timestamp format, which "shorted out" all our log tools.

Well, that's actually not true rsyslog defaults to the high precision format for local files, but it defaults to old-style legacy format when forwarding. So to have high precision timestamps when forwarding, you need to configure that. If you don't do anything, the old format (what you desire here) will be used.

Details in the compatibility doc:

http://www.rsyslog.com/doc-v3compatibility.html

Search for "Output File Format" and "Forwarding Format" sections - and notice the differences

Rainer

topnob wrote:Great it worked! thanks for all your help!

btw should we update to rsyslog 3.16.1 v3-stable? does it have some sweet fixes and cool features!

The primary new feature is RELP, which is great, but syslog-ng is not capable to utilize it. Read here why RELP is important:

http://rgerhards.blogspot.com/2008/04/o ... yslog.html

There are also quite a couple of bugfixes. The most important argument probably is that v3-stable versions prior to 3.16.x are supported under support contracts only. In short: it is highly suggested to update.

HTH
Rainer