On Fri, 27 Jun 2014, Radu Gheorghe wrote:
I seem to write and test lots of rsyslog configurations lately, and I think
I have to change a lot of properties. This is complicated and confusing for
a new user, but it's also quite error prone.
I would argue that rsyslog would get better adoption if you'd need to work
less to get your config working. Of course, this means that we'll have to
try harder to come up with sensible defaults. I think I can help with
patches for most of the stuff I mention below, but first I'd like to know
what you guys think so I don't send the patches and then find out it's a
bad idea :)
Here are some defaults I'd like to change:
imfile: PollInterval is 10 seconds -> 1 would be more appropriate for more
people, I think. Unless you have a slow machine *and* monitor tons of files
this should be pretty light, no?
This is quite a question, checking lots of files frequently can cause grief on
busy machines (even powerful ones). I lean towards keeping it at 10 seconds by
default on the theory that logging is not as important as whatever the box is
serving, so by default it's better to play it safe
imfile: a tag is required. Would it work to fill in the file name by
default?
I'm not sure, there are limits on the size and characters that are valid in
a tag. Is it better to force an admin to provide something that makes sense to
them? or is it better to auto-generate something that may be confusing (take the
filename, strip illegal characters and truncate)
imfile: StateFile is required. Maybe a hash on the file name would work? or
something along those lines?
a hash is a bad idea, there's no good way for a user to tie it to the file that
it's related to. $filename.statefile.$instance (to handle multiple files with
the same name in different directories) could work though
imfile: ReadMode is 0 by default. If we set it to 2, it should get most
stacktraces by default, and still get line by line if you tail a file with
only single line logs. There might be a performance penalty, but I bet it
will be insignificant for 99% of users.
the problem with readmode of 2 is that it won't process the last line of the log
until a new line is written, so on logs that get updated infrequently, the logs
will be delayed significantly.
omelasticsearch: If I remember correctly, it requires me to specify (and
define) a template. Can we default to that JSON variable that contains all
properties known to rsyslog?
probably a good idea
omelasticsearch: bulkmode is off by default. I'd set it to "on" and set the
action.dequeuebatchsize to something like 100 or even 1000. I'm not aware
of any usecase where people want to send logs one by one.
probably a good idea
omelasticsearch: resumeretrycount should be "-1" by default, because most
people would want rsyslog to buffer stuff if ES is unavailable.
These are more like nitpicking, but still about omelasticsearch:
- worker threads could be something like 3, because action threads have to
wait for HTTP requests to be completed. Is it even possible to set
different defaults based on the action?
it's not setting defaults, but as part of the action() definition you should be
able to set this.
- it would be great if searchIndex could point by default to something like
YYYY-MM-DD defined in a template. I think most people using omelasticsearch
will want daily indices
omelasticsearch is a contributed module, the core rsyslog folks are going to be
a little leery of changing the defaults.
David Lang
_______________________________________________
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.
