[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