On Mon, 1 Aug 2011, [email protected] wrote:
I guess the main question is, do I need a newer version of rsyslog (server
and/or client side) to do non-facility based remote (central) logging, ie,
via
property based filters?
NO!
Ok, just to get this clear in my head, then. When we no longer use facilities,
we
are no longer really using "syslog", right? So taking apache, for example. You
just revert back to the standard apache logging configuration like this:
ErrorLog logs/error_log
CustomLog logs/access_log combined
I assume then that apache logs these files locally like it always did, ie, in
/var/log/httpd/
That would be fine, we can rotate those out quickly. Now we also want to keep
monthly logs from ALL (dozens) apache servers on a central logging server, with
one massive log for each service (ie, error_log, access_log) for all servers,
rotated monthly, then compressed and kept for a year via logrotate.
The same goes for many other services. What would be a simple filter recipe to
have rsyslog (3.22) simply put the entire logs on the log server?
http://www.rsyslog.com/doc/rsyslog_conf_filter.html
Shows conditions based on facilities and/or error strings, but what if you just
want to have the entire logs of each server replicated and consolidated on the
central logging server?
when you send the logs from one machine to another, they will be sent in
the syslog format. If they are not sent to rsyslog in that format, it will
attempt to 'do the right thing' in converting them to that format, but
it's better to get it to rsyslog in a good format to start with.
you aren't changing the format, you are just ignoring the facility and
making your decisions on where to log things based on other things in the
log.
But there is also a hugh performance difference, if that matters. Also, I'd
Using facilities and a few services on a few dozen servers has shown negligible
load (somewhat to my surprise). I imagine filter-based might be quite
different?
it's all filter based logging, it's just different types of filters
(filtering on strings vs filtering on severity numbers)
yes, other filters are more expensive than facility based ones, but if you
don't have a large amount of traffic this may not matter to you. Just keep
this in mind in case your log server boggs down.
suggest to check the ChangeLogs if there exists any bugs in v3 that could
harm you. Generally, there shouldn't. It's just that you won't get much help
and no fixes if you run into issues -- but *then* you can think about
changing in any case. BTW: there is no problem running different versions on
different machines.
Say we were to uninstall the old (yum) version 3.22 from both the log server and
all clients and re-install via source...do you recommend 4.6.7 or 5.8.3
(stable),
or even 6.3.3 (devel)? Bear in mind that constantly upgrading them is something
we'd like to avoid.
that's a judgement call you will have to make.
personally I would not go with 4.x when there is a 5.x stable out there
(you are closer to loosing support with 4.x)
David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
