On Tue, Nov 16, 2010 at 02:27:04PM +0100, Dejan Muhamedagic wrote:
> Hi,
> 
> On Mon, Nov 15, 2010 at 06:18:29PM +0100, Bernd Schubert wrote:
> > On Monday, November 15, 2010, Dejan Muhamedagic wrote:
> > > > > This may truncate entity, and of course breaks existing filtering
> > > > > setups that trigger on it.
> > > 
> > > Right. So, this needs to be optional.
> > 
> > Ok, any favourite option keyword in logd.cf? If it comes to me, the present 
> > logd.cf *suggests* that not adding the commong log entity is a bug:
> > 
> > <quote>
> > #       Entity to be shown at beginning of a message
> > #       for logging daemon
> > #       Default: "logd"
> >  entity logd
> > </quote>
> > 
> > Was that option only for its own messages?
> 
> Yes, and the default in case the client didn't supply its entity.
> 
> > Isn't that a bit over-due?
> 
> I guess you meant overkill? Perhaps.
> 
> > So maybe 
> > "entity none" should suppress it in the future?
> 
> We can't change the semantic. So, we need a new option name.
> extra_entity? common_entity?

May I take a step backwards, and ask why we do this again?
Just to have a single filter line in syslog-ng?
Instead of, maybe, 7?
I mean: how many different entities are in use by a pacemaker cluster?

grepping through the logs of one pacemaker+heartbeat cluster for the last few
month says, order by number of occurences:
    192 ccm:
    262 crm_resource:
    370 cibadmin:
   7520 heartbeat:
   8459 attrd:
  10222 cib:
  20285 lrmd:
  24146 crmd:
 175687 pengine:

Is this complete? I don't think so.
dopd, ipfail, pingd are missing, mgmtd, tengine,
maybe "ResourceManager" for haresources mode.

On a pacemaker+corosync cluster, ccm and heartbeat are missing,
and probably no other are added, as corosync won't use logd?

So what we are actually talking about is adding a common tag to all
cl_log log messages if they are handed to syslog,
just to reduce
        filter ... { program("^(complete|list|of|the|above)") }
to
        filter ... { program("cl_log-common-tag") }

Hmm.
Maybe we should just try to get the list complete,
and not change the logging format.
Obviously that would miss any new users of cl_log,
but I doubt that are that many.

Sorry for taking the speed out of it ;-)

My questions:
Do we really want to change the syslog format and add a common tag?
If so, hardcode it, make it configurable?
If hardcoded, which one?
Default to not use it but have a toggle to switch it on?
If configurable, default to not use it?
Should we reuse the "cluster name"?
(you did know that you can assign a cluster name to heartbeat clusters,
it defaults to linux-ha...)
ha.cf:
  cluster lha-iscsiXX-buildingY-campusZ
;-)

So you can have all your clusters log to a central log server,
reliably identify them from the other message flood by some chosen prefix,
and seperate them by their full name?

No, well, I realize that it has to be a logd.cf setting,
we cannot reuse ha.cf settings really.

-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

Reply via email to