On Mon, Dec 16, 2013 at 4:15 PM, Radu Gheorghe <[email protected]>wrote:
> 2013/12/16 Rainer Gerhards <[email protected]> > > > On Mon, Dec 16, 2013 at 1:09 PM, Radu Gheorghe <[email protected] > > >wrote: > > > > > One comment regarding the equivalent of the Spooling Directory > > > Source< > > > http://flume.apache.org/FlumeUserGuide.html#spooling-directory-source > >in > > > Flume: > > > > > > rsyslog has a state file where it monitors where it left off. So (in > > > theory, at least), if the output blocks and the queues fill up, the app > > can > > > continue to write to that file and rsyslog will be able to continue > where > > > it left off. > > > > > > Though I'm not sure what happens if the file also rotates during the > > > process - if it can keep track. I think it should keep track, just like > > it > > > can do that during "normal" operation. > > > > > > > > one rotation is fine, so file n and n+1 are ok, but if we process file n, > > n+1 is created and than n+2 (WIHTOUT n being finished yet), n+1 is lost. > > > > > > > I think it would be pretty paranoid to support that use-case unless it's > trivial to add. I'd say the current behavior is OK for pretty much > everyone. > yup, much more valuable is wildcards. When I finally find time, you'll be able to monitor e.g. appA*.log files. Rainer > > _______________________________________________ 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.
