>> 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? > 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? > 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. TIA (again!) _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
