Hello, Den tis 22 sep. 2020 kl 10:59 skrev Rainer Gerhards <[email protected]>:
> I checked to be sure: currently there is no RELP channel driver. The > base idea was that liblogging-stdlog provides a route to > file/journal/unix socket and rsyslog picks up things from the unix > socket and then forwards it via RELP. This is superior to a channel > driver, because this makes operation async, which usually is what you > want. > > If you need some more info on the overall idea, let me know. I'd do a > small prep (maybe we can jump into a short conf call, looks like you > are in EU time zones which should make that fairly easy. If we take > that route, I'd like to record so others can benefit as well. Comments > appreciated. This sounds absolutely fantastic! I will reach you in a private mail. It would be really great to know more about reliable logging via rsyslogd. And I believe it will be very useful knowledge to many software developers. The fact that logging through syslog is not always reliable is not a well-known fact, I am afraid. Do I understand it right that if I do not want to ever experience a message loss if I log through rsyslogd (e.g., if I log financial transactions or implement smth like flight recorder) I have to design the system in the following way: 1. Apps log directly to rsyslog through unix socket 2. SysSock.FlowControl is enabled in imuxsock / rsyslogd 3. rsyslogd forwards the data to another rsyslog server through RELP protocol ? If I can keep logs in the same node where the app is running is it enough to implement just the first two steps and let rsyslog write logs using the omfile module? Or can it start to drop messages after a certain logging rate is reached? I tested with loggen utility from syslog-ng package the local configuration (app logs to rsyslogd through UNIX socket and rsyslogd writes to the files directly). In this configuration there was always a logging rate after which rsyslog started to drop messages. And this makes perfect sense for async operations, I believe. If there is no way to stop the log source, rsyslog has no other option than to drop logs. Disk writing speed is limited. But if I activate SysSock.FlowControl, will it save the party (for the cost of blocking log producing processes sometimes)? And I had an idea to test the 3rd setup: app sends log directly to rsyslog through RELP. But it looks like this use case is not what RELP author had in mind when designing RELP ? :-) -- WBR & WBW, Vitaly _______________________________________________ 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.
