pcp
[Top] [All Lists]

Re: [pcp] [question] PCP UI FrontEnd

To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Subject: Re: [pcp] [question] PCP UI FrontEnd
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Tue, 28 Jul 2015 03:40:49 -0400 (EDT)
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <55B70B48.7060704@xxxxxxxxxxxxxxxx>
References: <f8fde1169e264460bc2e250d2c9d7df0@xxxxxxxxxxxxxxxxxxxxxxxxx> <y0m1tft2sqt.fsf@xxxxxxxx> <55B6B46E.2050306@xxxxxxxxxxxxxxxx> <y0m4mkpyu9j.fsf@xxxxxxxx> <55B70B48.7060704@xxxxxxxxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: KwbETqQcr4vRIloz0vCPIwnx0Me9NQ==
Thread-topic: PCP UI FrontEnd

----- Original Message -----
> [...]
> pmlogger is complicated enough as is, I don't see much chance of loading
> more functionality in there once it is running, other than the existing
> pmlc channel.

+1   ... the discussion from way-back-when about pmlc "groups" seems like
a more appropriate approach for the use cases I've come across.

The separation between pmlogger and pmlogconf is a very good thing IMO -
its a clean, easily understood separation of concerns.

I'd also like to teach pmlogconf to produce alternate formats over time;
like the one Marko suggested recently for exporter-tools in the class of
pcp2graphite, so that it can be used to configure those metric sinks.  I
have seen two separate needs for similar tools just this week that would
be able to use that immediately.

Almost noone uses the existing dynamic configuration capabilities that
pmlogger has (nor even asks about them), I'd not advocate spending a ton
of time in there.

cheers.

--
Nathan

<Prev in Thread] Current Thread [Next in Thread>