2017-08-08 6:36 GMT+02:00 deoren
<rsyslog-users-lists.adiscon....@whyaskwhy.org>:
> On 8/5/17 11:42 PM, deoren wrote:
>>
>> On 8/5/17 10:59 PM, deoren wrote:
>>>
>>> I've recently converted all of our nodes from forwarding messages from
>>> the default forwarding format to using the 'RSYSLOG_SyslogProtocol23Format'
>>> format.
>>>
>>> I only did light research beforehand (so I can only blame myself), but
>>> when our relay nodes log in either 'RSYSLOG_TraditionalFileFormat' or
>>> 'RSYSLOG_FileFormat' the process name is recorded in the log file(s). When
>>> we forward messages using the default forwarding format, that information
>>> seems to come across as expected. When our client nodes forward using the
>>> 'RSYSLOG_SyslogProtocol23Format' format the process name information is
>>> "lost" and not recorded within the local log files on our receiver.
>>>
>>> DETAILS
>>>
>>> sender:
>>>
>>> * rsyslog 8.28.0
>>> * Ubuntu 16.04
>>> * using official PPA
>>> * Postfix mail relay node
>>> * sending in 'RSYSLOG_SyslogProtocol23Format' format via RELP
>>> * recording locally in 'RSYSLOG_FileFormat' format
>>> * local messages appear to retain 'postfix/smtpd[9999]' format (which is
>>> desired)
>>>
>>> receiver:
>>>
>>> * rsyslog 8.28.0
>>> * Ubuntu 16.04
>>> * using official PPA
>>> * receiving via RELP
>>> * recording locally in 'RSYSLOG_FileFormat' format
>>> * messages saved appear to no longer retain the process name (e.g.,
>>> 'postfix[9999]')
>>>
>>>
>>> Turning to Google, I found this[1] bug report which explained the problem
>>> much better than I ever could. I later found another thread[2] where the
>>> problem was discussed, but no resolution reached. The final post to that
>>> thread[4] illustrated that the syslogtag value is coming across with the
>>> values needed in the syslogtag field, but both programname and app-name
>>> properties were missing the Postfix component/process name information.
>>>
>>> Is there a way to subsclass or inherit the RSYSLOG_FileFormat template
>>> and override the value it uses for app-name? I don't know what I am doing in
>>> that regarding, but I'm willing to learn. I'd really like to preserve the
>>> Postfix process name in the log messages saved on our receiver node.
>>>
>>> In absence of the understanding necessary to override the existing
>>> template, one workaround I'm considering is having our client nodes check
>>> the facility before forwarding messages on to the central receiver. If the
>>> facility is 'mail', send using traditional forwarding format, otherwise send
>>> everything else using the newer forwarding format. I'd rather have precision
>>> timestamps on both, but having the process name available in the mail logs
>>> is more important in our use case.
>>>
>>> Thank you in advance for your help!
>>>
>>>
>>> References:
>>>
>>> [1] https://github.com/rsyslog/rsyslog/issues/168
>>>
>>> [2] http://kb.monitorware.com/app-name-programname-t12945.html
>>>
>>> [3] http://kb.monitorware.com/post27055.html#p27055
>>>
>>> [4] http://kb.monitorware.com/post27061.html#p27061
>>>
>>> [5] http://www.rsyslog.com/doc/v8-stable/configuration/templates.html
>>
>>
>> After hitting Send, I found the 'parser.permitSlashInProgramName' option
>> listed on the properties page which seems to do what I'm looking for. I
>> enable it on the client nodes and the receiver seems to pick it up without
>> requiring that I also enable it there (but of course I will for
>> consistency).
>>
>> I submitted a bug report against the rsyslog-doc repo to include the
>> global option on the global documentation page.
>>
>> https://github.com/rsyslog/rsyslog-doc/issues/359
>>
>> According to the notes for that option, it appears it was added in a
>> fairly recent release. Many thanks to the devs for including it!
>
>
> Does the 'RSYSLOG_SyslogProtocol23Format' format intentionally drop colons
> from the 'syslogtag' property?

Well, this format is RFC5424, and RFC5424 does not have syslogtag as
you know it. See RFC5424 Sect A.1 for the relationship. This is the
relevant quote for your question:

-----------------------------

  The MSG part of the message is described as TAG and CONTENT in RFC
   3164.  In this document, MSG is what was called CONTENT in RFC 3164.
   The TAG is now part of the header, but not as a single field.  The
   TAG has been split into APP-NAME, PROCID, and MSGID.  This does not
   totally resemble the usage of TAG, but provides the same
   functionality for most of the cases.

-----------------------------

I have not actually checked the code, but I think we drop the colon as
part of this transformation process.

>
> On the original system I use the RSYSLOG_DebugFormat template and I see that
> 'syslogtag' contains a value like this (note the colon):
>
> 'postfix/qmgr[1144]:'
>
> but when forwarded, the RSYSLOG_DebugFormat template shows the syslogtag as
> containing (note the lack of a colon):
>
> 'postfix/qmgr[1144]'

Check what APP-NAME, PROCID and MSGID contain, which are derived from the tag.

RFC5424 tells you where these parts are to be placed in the header.

>
> It appears that this lack of a colon is confusing pflogsumm when the daily
> cron job calls this script to generate a daily report of the mail activity
> recorded on our central rsyslog instance.

that would indicated that pflogsumm does not properly handle RFC5424 message.

HTH
Rainer
>
> Thank you for your help.
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
> What's up with rsyslog? Follow https://twitter.com/rgerhards
> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
> sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T
> LIKE THAT.
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of 
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE 
THAT.

Reply via email to