[rsyslog] omfile redesign / $OutChannel will go away!

Sergei Zhirikov sfzhi at yahoo.com
Tue Jun 30 15:24:53 CEST 2009


> From the feedback I received so far, there seem to be two use cases:
> 
> a) circular logs
> b) stop logging when file hits max size (was that really what this post
> described?)
> 
> If I look at the b) case, I suspect that this is not even the intent of the
> original poster. I think he would be much better served with a circular log
> that records as many log records as fit into a finite, operator-specified log
> file size. Or am I wrong here? (If nobody tells me I am wrong, I'll probably
> remove the b) use case in the long term!).
> 
> Rainer
> 

In the case of log flood neither of the two options is perfect. The 
difference is only in what you lose, the oldest or the newest log 
entries. What I really like about the current rsyslog functionality is 
the possibility to call an external process to deal with the oversized 
logs. Stopping logging I consider only a safeguard in case that external 
process fails to do its job for whatever reason.

Having an external process makes the whole setup a lot more flexible, 
because it gives almost unlimited opportunities, for example:

   * gzip the older logs rather than delete them. In case of log flood 
gzipping is usually very efficient, because the same message is repeated 
in the log multiple times, so there is no need to delete anything.
   * filter the older logs based on conditions that involve analyzing 
more than one log entry at the same time. This can be useful, for 
example, do detect break-in attempts if desired.
   * measure the average speed of logging and send an email or generate 
another kind of alert when the logs are growing unusually fast.
   * make a decision whether to gzip the older logs, to move them to 
another location (e.g. a network storage, if available), or to delete 
them based on conditions outside of control of rsyslog (e.g. available 
system resources, availability of alternative storage, etc.)

The list can go on infinitely. I believe the possibility to call an 
external process to handle log rotation gives the flexibility that can 
not be provided within rsyslog itself, because there are so many 
different things one might want to do. And I would very much like to see 
this functionality stay in one or another form. Hope I'm not the only 
one who thinks that way.

Kind regards,
Sergei.




More information about the rsyslog mailing list