Dear rsyslog mailing list,
First time coming out of the shadow here for a particular behavior that
I've not well understood in our stack here.
So, we are monitoring our network using syslog using rsyslog as a proxy
to be certain of the version format used, as the equipements are very
diverse and some respects some rfc, some others, and some
implementations are buggous. Last time we had an issue were we had an
alert on a log volume on a equipement hostname that is not anymore in
our network. The IP of the equipement was reused somewhere else.
It seemed that instead of keeping the hostname "as is" the rsyslog proxy
was using it's own name resolution and replaced the hostname first
present in the packet by the one in it cache, resulting in the wrong
hostname beeing transmeted to the promtail/loki infrastructure behind.
Here is what we have as a remote.conf: We have made that for a buggous
implementation where APPNAME is seen as NULL (not empty string)
resulting in failure of rsyslog. I don't think this behavious is
especialy linked to the %HOSTNAME% but I want to be sure with you.
```
$ModLoad omfwd
:app-name, !isequal, "" {
action(type="omfwd" protocol="tcp" target= "localhost" port="1515"
Template="RSYSLOG_SyslogProtocol23Format" TCP_Framing="octet-counted"
KeepAlive="on")
}
template(name="missingAppName" type="string" string="<%PRI%>1
%TIMESTAMP:::date-rfc3339% %HOSTNAME% NOAPPNAME %PROCID% %MSGID%
%STRUCTURED-DATA% %msg% \n")
:app-name, isequal, "" {
action(type="omfwd" protocol="tcp" target= "localhost" port="1515"
Template="missingAppName" TCP_Framing="octet-counted" KeepAlive="on")
}
```
Could you please clarify how rsyslog interact with the system name
resolution cache as we thought it wouldn't be touching the value of
hostname before retransmiting it. It has been fixed by removing the
cache entry. The server is a Debian bullseye with a 8.2102.0-2+deb11u1
(version might be incorrect as I've had the issue couple month ago and
haven't noted here. I will try to find it back if needed).
Best regards.
_______________________________________________
rsyslog mailing list
https://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.
First time coming out of the shadow here for a particular behavior that
I've not well understood in our stack here.
So, we are monitoring our network using syslog using rsyslog as a proxy
to be certain of the version format used, as the equipements are very
diverse and some respects some rfc, some others, and some
implementations are buggous. Last time we had an issue were we had an
alert on a log volume on a equipement hostname that is not anymore in
our network. The IP of the equipement was reused somewhere else.
It seemed that instead of keeping the hostname "as is" the rsyslog proxy
was using it's own name resolution and replaced the hostname first
present in the packet by the one in it cache, resulting in the wrong
hostname beeing transmeted to the promtail/loki infrastructure behind.
Here is what we have as a remote.conf: We have made that for a buggous
implementation where APPNAME is seen as NULL (not empty string)
resulting in failure of rsyslog. I don't think this behavious is
especialy linked to the %HOSTNAME% but I want to be sure with you.
```
$ModLoad omfwd
:app-name, !isequal, "" {
action(type="omfwd" protocol="tcp" target= "localhost" port="1515"
Template="RSYSLOG_SyslogProtocol23Format" TCP_Framing="octet-counted"
KeepAlive="on")
}
template(name="missingAppName" type="string" string="<%PRI%>1
%TIMESTAMP:::date-rfc3339% %HOSTNAME% NOAPPNAME %PROCID% %MSGID%
%STRUCTURED-DATA% %msg% \n")
:app-name, isequal, "" {
action(type="omfwd" protocol="tcp" target= "localhost" port="1515"
Template="missingAppName" TCP_Framing="octet-counted" KeepAlive="on")
}
```
Could you please clarify how rsyslog interact with the system name
resolution cache as we thought it wouldn't be touching the value of
hostname before retransmiting it. It has been fixed by removing the
cache entry. The server is a Debian bullseye with a 8.2102.0-2+deb11u1
(version might be incorrect as I've had the issue couple month ago and
haven't noted here. I will try to find it back if needed).
Best regards.
_______________________________________________
rsyslog mailing list
https://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.