MonitorWare Knowledge Base

Hello Folks,

I have tried a number of options, but I want to start with by leaving the question open.

1) I WinSyslog 7.2 listening as a server on port 514. Standard. Nothing new here. It listens for events coming in from about 300 Unix Servers.
2) In my Default Rule Set, I created a Syslog Forwarder that forwards these events to another Syslog Server (Y)
3) I want the messages to be received by Y in the expected RFC 3164 format. This is defined as:

Code: Select all

<PRI>DATE HOSTNAME TAG CONTENT
or
<PRI>DATE IPADDRESS TAG CONTENT

Note that the <> brackets surrounding PRI above are part of the content.

When I configured my Syslog Forwarder, I selected "Process message while relaying" and initially configured my message format to be:

Code: Select all

<%syslogpriority%>%timegenerated% %source% %syslogtag% %msg%

In the hopes that it would match the RFC standard listed above. By the way, a silly question, but where can I get a complete list of the valid macros I can specify in my message format?

On server Y, I took a look at the forwarded messages from the WinSysLog and here is what I saw:

Dec 11 08:45:01 [10.1.108.42] <6>2007-12-11 13:45:01 10.1.108.42 crond[3230]: (root) CMD (/usr/local/scripts/fs_check_space.sh > /dev/null 2>&1)
Dec 11 08:45:01 [10.1.108.42] <6>2007-12-11 13:45:01 10.1.108.42 crond(pam_unix)[3228]: session closed for user root
Dec 11 08:45:02 [10.1.108.42] <6>2007-12-11 13:45:01 10.1.108.42 crond(pam_unix)[3226]: session closed for user root

Note that the first two fields are NOT generated by WinSysLog. That is server Y's code doing that, so please ignore it.

The date format is wrong. It needs to be in RFC 3164 format, which means:

Code: Select all

Month 1-31 HH:MM:SS where:

Month = Jan, Feb, mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, or Dec

How do I massage the message format time into that format?

Thanks,
-Pat

I changed my Message format to be blank (i.e. no properties are defined in it) and restarted WinSysLog, and here is what I see @ server Y:

Dec 11 09:39:51 [10.3.41.43] Dec 11 09:39:51 10.3.41.43 snmpd[22859]: Connection from - 127.0.0.1
Dec 11 09:39:51 [10.3.41.43] Dec 11 09:39:51 10.3.41.43 snmpd[22859]: transport socket = 15
Dec 11 09:39:53 [10.3.41.43] Dec 11 09:39:53 10.3.41.43 snmpd[22859]: Connection from - 127.0.0.1
Dec 11 09:39:53 [10.3.41.43] Dec 11 09:39:53 10.3.41.43 snmpd[22859]: transport socket = 15

If it is blank, is this the default (again, ignore the first two fields)?

Hi Propellerhead,

by default the Forward Syslog Action will create a RFC 3164 valid syslog header, so there is no need to do this manually.

The problem with your custom format is, that the "<PRI>" is actually not only Priority but also Facility (bit masked). So the value contains 3 bytes of priority and 5 bytes of facility.

So I recommend you use default settings and message format of the Forward Syslog Action. Just uncheck the option "Add Syslog Source when forwarding to other Syslog Servers", so the original messages is not altered.

I hope this helps - best regards,
Andre Lorbach

Thanks Alorbach

I did resolve my issue here, but let me walk you through a different but related scenario. Note that I had my Interactive Winsyslog Server running so I could see the real time events.


1) Looked at the local syslog /var/adm/syslog file to follow a message:

Dec 19 12:04:40 rcirs014 user:info syslog: /usr/sbin/ifconfig lo0

3) The previous message was forwarded to my WinSyslog Server. I looked at the previous syslog event as recorded by the Interactive Client:

Dec 19 12:04:40 rcirs014.rogers.com forwardedRealSource:"hp099.domain.com" forwarded from rs014: syslog: /usr/sbin/ifconfig lo0

Here are my questions:

1) Why do I see this phrase:

RealSource:"hp099.domain.com"

When I explicitly instructed the client not to show that in "File --> Options --> Unchecked "Resolve RealSource from Syslog message if available" prior to clicking the "Start Logging" button?

2) Why do I see the "forwarded" string prefixed before the "forwardedRealSource:"hp099.domain.com":

Dec 19 12:04:40 rcirs014.rogers.com forwardedRealSource:"hp099.domain.com" forwarded from rs014: syslog: /usr/sbin/ifconfig lo0

3) Ultimately the message that is being received from Winsyslog looks like this:

forwardedforwarded from rcirs014: syslog: /usr/sbin/ifconfig lo0

Please help me understand what the issue is.

Thanks
-Patrick

In the Forward Syslog Action, which forwards the syslog message to trhe interactive display, uncheck the option "Add Syslog Source when forwarding to other Syslog servers". Then you won't see the "RealSource" in the forwarded message.

Do the same @every other WinSyslog installations where you forward syslog messages.

best regards,
Andre Lorbach

Hi Andre,

In the Forward Syslog Action, which forwards the syslog message to trhe interactive display, uncheck the option "Add Syslog Source when forwarding to other Syslog servers". Then you won't see the "RealSource" in the forwarded message.

That fixed it. I was looking in the wrong place. But there is still an issue: I am seeing duplicate strings in the forwarded WinSyslog messages received by my syslog server. Let me walk you through it:

1) I set up my "Forward via Syslog 4" action as follows:

- Checked "Process message while relaying"
- In my "Message Format" box, I simply have the macro "%msg%" defined (without the quotes of course)
- Output Encoding is "System Default"
- Everything else is unchecked

2) I logged into one of my servers and issued the following command:

$ logger -p auth.warn "Patrick was here"

3) I checked the local syslog on this AIX server:

Dec 21 07:29:08 rcirs013 auth|security:warn|warning cronsec: Patrick was here

All looks well.

4) I captured this event via the Interactive Syslog Server:

Dec 21 07:29:08 rcirs013.domain.com PatrickPatrick was here

What is causing this duplicate string?

5) I checked my central syslog server to ensure it was also receiving the mangled message, and indeed it was:

8 2007/12/21 07:29:08.602 EST 10.1.27.44 PatrickPatrick was here

What gives?

Very odd. Seems like the first word of your testmessage has been turned into the SyslogTag or something like that.

I will need to verify and test this to say more.

regards,
Andre