the parameters you listed are all viable.
But listing them in global() would have no effect. You need to specify them
in an action(), ruleset() or main-queue() so they are used there.
Disk queues always use the disk and do not buffer anything in memory, which
means they are ultra-reliable, but slow.
For the best result you should put the queue in front of a reliable
transport action such as relp.
we are using RELP.
according to some comments in
https://github.com/rsyslog/rsyslog-doc/pull/281, seems rulesets should
have a queue to avoid "creating a temporary queue"
as we are looking for 0% loss...
1. imrelp -> ruleset+main_queue(disk) is there any chance a message
being lost between RELP reception and queueing?
2. ruleset+main_queue(disk) -> mmjsonparse -> mmnormalize -> omfile is
there any chance a message being lost anywhere?
3. imfile -> omelasticsearch is there any change a message being lost?
PS: using RELP, when there are connection issues we noticed some
problems, bottlenecks and so. hence, we decided to use a file between
RELP and elastic
_______________________________________________
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.
