Hi, "Delon Lee Di Lun" <lee.delon2005@gmail.com> írta 2018-05-09 12:21-kor:
I understand that this is a syslog-ng mailling list but however, in my setup I am testing. I have to use rsyslog for the client.
Has anybody tried a client as rsyslog and the server as syslog-ng does the flow-control still kick in? Assume transportation protocol is TCP.
I want to see if anybody tried it before, or let me know its impossible before i commit my time into testing the setup.
Well, I don't have first hands experience with this setup. But based on my current knowledge: it should work. So if you set up proper flow control on the syslog-ng side for the tcp source, and you also setup a disk buffer on the sender rsyslog side, it should fulfill your expectations, and should not loose any log events. I didn't analyzed exceptional cases here, eg. when you have some kind of transparent "loadbalancer" between your rsyslog and syslog-ng, and if your rsyslog get the ack but syslog-ng didn't really received the data. It's just playing with thoughts. So I could imagine situations when all your intention aiming failsafe log transportation will let you down. But it needs a really f..d up network configuration! In this case, if you can not trust your network setup, I suggest using an extra ssl layer for mutualy check parties via certificates. syslog-ng can handle that natively: https://syslog-ng.com/documents/html/syslog-ng-ose-latest-guides/en/syslog-n... The last time I check this part of rsyslog, they suggested using an stunnel for that scenario. If it's still the case, then stunnel can be a weak point: when rsyslog thinks it handed over the data to stunnel, but if that "crashes" or restarts, then it will loose its own buffer. Honestly, I don't know if rsyslog has any improvment on that side. Cheers, Gyu