On Tuesday, November 16, 2010, Lars Ellenberg wrote:
> 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.
Sorry, yes I meant overkill.
> >
> > > 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?
Yes. In my humble opinion, heartbeat logs and even less pacemaker logs are
everything, but are definitely not user friendly. As user I'm interested
mostly in output the resource agents, but in between 1000 lines of debug
logs of pacemaker (tagged as 'info'), that gets easily lost.
> 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.
Where are your resource agents? Each and every resource agent gets its own
entity...
Nov 12 20:48:06 vm2 lustre_server[4808]: [4854]: INFO: Running stop for
/dev/ddn/ost_janlus_13 on /lustre/janlus/ost_13
Nov 12 20:48:06 vm2 lustre_server[4808]: [4867]: INFO: Trying to unmount
/lustre/janlus/ost_13
Nov 12 20:48:06 vm2 lustre_server[4808]: [4874]: INFO: Running umount
/lustre/janlus/ost_13
Nov 12 20:48:06 vm2 lustre_server[4807]: [4884]: INFO: Running stop for
/dev/ddn/ost_janlus_11 on /lustre/janlus/ost_11
Nov 12 20:48:06 vm2 lustre_server[4807]: [4890]: INFO: Trying to unmount
/lustre/janlus/ost_11
Nov 12 20:48:06 vm2 lustre_server[4807]: [4892]: INFO: Running umount
/lustre/janlus/ost_11
Nov 12 20:48:09 vm2 lustre_server[4808]: [4907]: INFO: unmounted
/lustre/janlus/ost_13 successfully
Nov 12 20:48:14 vm2 lustre_server[4807]: [4930]: INFO: unmounted
/lustre/janlus/ost_11 successfully
>
> 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 ;-)
Well, if can't agree on it soon, I will pass it to my successor, but
somehow I doubt it will be done then at all.
Depending on how FhGFS will envolve I will bring this up in few months/years
then or not all ;)
>
> 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.
I really don't mind if hard coded or not, but can we please agree on it soon?
If you really don't want to change the entity entry, we will can add it before
the real message or even append it to the message. I'm fine with everything,
as long as you can write a *simple* filter on it.
Thanks,
Bernd
_______________________________________________________
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/
