[Pacemaker] [PATCH 0/2] rsyslog/logrotate configuration snippets

[Florian Haas]

On Mon, Jan 16, 2012 at 10:59 AM, Andrew Beekhof <andrew at beekhof.net> wrote:

> By "Nuclear", I meant nothing at all from Pacemaker.

Which is not what it does.

> 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.

>> (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?

> 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?

>> 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