you _really_ don't want rsyslog to do a DNS lookup for every packet, it would crush your DNS server and everything would slow to a crawl.

look at rebind interval, that will have rsyslog redo the connection every X messages/batches to support load balancing.

David Lang

On Sun, 31 May 2020, Olivia Nelson via rsyslog wrote:

Date: Sun, 31 May 2020 08:42:30 +0800
From: Olivia Nelson via rsyslog <[email protected]>
To: rsyslog-users <[email protected]>
Cc: Olivia Nelson <[email protected]>
Subject: Re: [rsyslog] rsyslog does not forward logs to new IP address,
    when DNS A record is updated

David,

We have a large network, 700K hosts in total, 30+ facilities, and I
use UDP protocol in large networks.

If we restart all clients simultaneously it would create a massive DNS
lookup and crash the network.
So we would have to restart a few of them each time.

I just need rsyslog to contact the new server when necessary.

On Sun, May 31, 2020 at 2:05 AM David Lang via rsyslog
<[email protected]> wrote:

when you issue a HUP, rsyslog creates new connections. I think that will involve
doing a new DNS lookup.

While UDP is 'connectionless', sending UDP packets consists of two steps

1. setting where the data will go
2. sending the data

rsyslog only does step 1 when it has to, (when it's not already setup) so you
can keep sending data and it logically acts as if there is a connection.

David Lang

On Fri, 29 May 2020, John Chivian via rsyslog wrote:

Date: Fri, 29 May 2020 08:05:38 -0500
From: John Chivian via rsyslog <[email protected]>
To: [email protected]
Cc: John Chivian <[email protected]>
Subject: Re: [rsyslog] rsyslog does not forward logs to new IP address,
    when DNS A record is updated

The subject of load balancing a large population of clients, be it DNS
based or otherwise, is a bit beyond the scope of this list.

To be honest I do not know for certain how rsyslog handles the DNS case
with UDP, but thinking as a developer and knowing that one of the
primary stated goals of rsyslog is to be fast, I can tell you there is
no way every connectionless UDP packet generates a DNS request.
Therefore extending that thought, it makes total sense that for UDP
destinations the DNS call is made only once at startup.  The maintainers
will know for sure.

And while I do not wish to reopen any debates over protocol, it is my
view that UDP should only be used as an emergency last resort.  Log
traffic, especially security related log traffic should be transmitted
with the "guaranteed delivery" offered by TCP, not with the "best
effort" of UDP.

Regards,


On 5/28/20 9:45 PM, Olivia Nelson via rsyslog wrote:
Hi John

On Fri, May 29, 2020 at 3:09 AM John Chivian via rsyslog
<[email protected]> wrote:
rsyslog will leverage any DNS caching that the system does.   check for
instances of nscd, and be aware that the dig utility does not consider
any such cache.
We don't use nscd, in this case its /etc/hosts

it is also very important to understand that the DNS name is only used
once, when the connection to the remote system is established.  if the
log stream is steady enough so that the connection never goes away, then
DNS could change any number of times behind the scenes and the open
connection would neither know or care.

if the connection did time out and go away, then the next time a packet
came in and the connection to the remote host had to be re-established,
a DNS lookup would occur and the new value used.  this is obviously the
same thing that happens when you restart.
Does it apply for UDP sockets?

I have roughly 10K syslog clients and need to redirect half of them to
a new central syslog server. So the original one will keep running.
If I don't restart the syslog clients, it would still contact the original
one.


_______________________________________________
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.
_______________________________________________
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.
_______________________________________________
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.

_______________________________________________
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.

Reply via email to