On Mon, Jan 16, 2012 at 2:42 PM, Florian Haas <flor...@hastexo.com> wrote: > On Mon, Jan 16, 2012 at 10:59 AM, Andrew Beekhof <and...@beekhof.net> wrote: > >> By "Nuclear", I meant nothing at all from Pacemaker. > > Which is not what it does.
The daemons. The RAs are not "from Pacemaker". This is why I wrote in my first reply: "/some/ information not coming directly from the RAs is still appropriate for syslog (such as "I'm going to move A from B to C" or "I'm about to turn of node D")" Where in https://github.com/fghaas/pacemaker/blob/9e9bafd44971a8f4c3cd1de62fb2278fab28489e/extra/rsyslog/pacemaker.conf.in does it allow any log from any daemon through? > >> If thats what you want, there's a far easier way to achieve this and >> keep usable logs around for debugging, set facility to none and add a >> logfile. > > No, I don't want that. So one file per pacemaker daemon is central to your proposal? >>> (Stuff that the RAs simply barf out to stdout/err would go to the lrmd >>> log.) I maintain that this is the stuff that is also most useful to >>> people. And with just that information in the syslog, you usually get >>> a pretty clear idea of what the heck the cluster is doing on a node, >>> and in what order, in about 20 lines of logs close together -- rather >>> than intermingled with potentially hundreds of lines of other >>> cluster-related log output. >> >> Did I not just finish agreeing that "hundreds of lines of other >> cluster-related log[s]" was a problem? > > What in my statement above indicates that I assumed otherwise? The part just above my reply where you're implying that the only alternative to your idea of removing all daemon logging from syslog was: resource logs "intermingled hundreds of lines of other cluster-related log output". > >> I just don't think your knee-jerk "everything must go" approach is the >> answer. > > That is not my approach. > >>> And disabling the "nuclear option" is a simple means of adding a "#" >>> before "& ~" in the config file. You can ship it that way by default >>> if you think that's more appropriate. That way, people would get the >>> split-out logs _plus_ everything in one file, which IMHO is sometimes >>> very useful for pengine or lrmd troubleshooting/debugging. I, >>> personally, just don't want Pacemaker to flood my /var/log/messages, >> >> Did you see me arguing against that? > > No. What makes you think I did? Because you keep trying to tell me the current approach is wrong. I know that, I said that, I just don't happen to think your idea is the solution. > >>> so I'd definitely leave the "& ~" in there, but that may be personal >>> preference. I wonder what others think. >>> >>>> In addition to the above distractions, I've been coming up to speed on >>>> libqb's logging which is opening up a lot of new doors and should >>>> hopefully help solve the underlying log issues. >>>> For starters it lets syslog/stderr/logfile all log at different levels >>>> of verbosity (and formats), it also supports blackboxes of which a >>>> dump can be triggered in response to an error condition or manually by >>>> the admin. >>>> >>>> The plan is something along the lines of: syslog gets NOTICE and >>>> above, anything else (depending on debug level and trace options) goes >>>> to /var/log/(cluster/?)pacemaker or whatever was configured in >>>> corosync. >>>> However, before I can enact that there will need to be an audit of the >>>> messages currently going to INFO (674 entries) and NOTICE(160 entries) >>>> with some getting bumped up, others down (possibly even to debug). >>>> I'd certainly be interested in feedback as to which logs should and >>>> should not make it. >>> >>> Yes, even so, I (again, this is personal preference) would definitely >>> not want pengine logging (which even if half its INFO messages get >>> demoted to DEBUG, would still be pretty verbose) in my default >>> messages file. >> >> Sigh, please take time out from preaching to actually read the >> replies. You might learn something. > > This is getting frustrating. Not this logging discussion, but pretty > much any discussion the two of us have been having lately. (And no, > this is not an assignment of guilt or responsibility -- it takes two > to tango.) Let's try and sort this out in person on Thursday. > > Florian > > _______________________________________________ > Pacemaker mailing list: Pacemaker@oss.clusterlabs.org > http://oss.clusterlabs.org/mailman/listinfo/pacemaker > > Project Home: http://www.clusterlabs.org > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org _______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org