On Aug 19, 2014, at 12:55 PM, Rainer Gerhards <[email protected]> wrote:
> On Tue, Aug 19, 2014 at 11:17 AM, Ivan Lezhnjov IV < > [email protected]> wrote: > >> Hello, >> >> On Aug 15, 2014, at 6:17 PM, Rainer Gerhards <[email protected]> >> wrote: >> >>> On Fri, Aug 15, 2014 at 5:13 PM, Mike Hoskins (michoski) < >> [email protected] >>>> wrote: >>> >>>> I thought %FROMHOST% caused a DNS lookup on rsyslog's side, while >>>> %HOSTNAME% just used the hostname sent in the message...others will >>>> correct if my memory is bad. >>> >>> >>> That's right, but I think we fall back to a dns lookup if there is no >>> detectable hostname in the message(not 100% sure, though). >>> >>> >>>> So if %HOSTNAME% is not right, it must be >>>> something on the client side. >>>> >>>> >>> can very well be, but sounded more like DNS resolution. >>> >>> >>>> I think you just use %rawmsg% to get the raw message. :-) >>>> >>>> http://www.rsyslog.com/doc/property_replacer.html >>>> >>>> >>> yup or use >>> >>> *.* /var/log/messagedebug;RSYSLOG_DebugFormat >>> >>> which will write out all properties. >> >> This is how a normal message looks like: >> >> Debug line with all properties: >> FROMHOST: '172.16.16.4', fromhost-ip: '172.16.16.4', HOSTNAME: >> 'xyz-DDDD-02', PRI: 86, >> syslogtag 'su[42661]:', programname: 'su', APP-NAME: 'su', PROCID: >> '42661', MSGID: '-', >> TIMESTAMP: 'Aug 19 02:11:58', STRUCTURED-DATA: '-', >> msg: ' pam_unix(su:session): session closed for user postgres' >> escaped msg: ' pam_unix(su:session): session closed for user postgres' >> inputname: imtcp rawmsg: '<86>Aug 19 02:11:58 xyz-DDDD-02 su[42661]: >> pam_unix(su:session): session closed for user postgres' >> >> Are we interested in this only, or also what debug message is going to >> look like when the suspected DNS resolution failure occurs again? >> > > Judging from this line, it must be a problem on the client side. As you can > see, the hostname "xyz-DDDD-02" is included in the raw message. If it is, > rsyslog doesn't bother to pick any other name. So it looks like when the > problem occurs, the rawmsg contains something along the lines of > "192.168.1.1" instead of the real name. This you can watch out for when the > problem occurs again. Alright, I'll keep the debug logging on and examine its contents as soon as another hiccup occurs. Just to make sure we are on the same page, when the DNS resolution failure happens it is essentially a problem with the client machine, not the remote rsyslog server? Ivan _______________________________________________ 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.
