pcp
[Top] [All Lists]

Re: [pcp] systemtap/pcp integration

To: pcp@xxxxxxxxxxx
Subject: Re: [pcp] systemtap/pcp integration
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Fri, 25 Jul 2014 08:38:23 +1000
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <53CED142.1040109@xxxxxxxxxx>
References: <53C83CB9.3020808@xxxxxxxxxx> <y0miomuk6qa.fsf@xxxxxxxx> <53C94A6F.4080808@xxxxxxxxxx> <20140718182751.GE20905@xxxxxxxxxx> <53CE743E.9030807@xxxxxxxxxx> <20140722152127.GC20079@xxxxxxxxxx> <53CED142.1040109@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
On 23/07/14 07:01, David Smith wrote:
On 07/22/2014 10:21 AM, Frank Ch. Eigler wrote:
Hi, David -


[...]
I think a JSON fetcher/parser is a good idea.

Good enough to redirect from MMV?

I think MMV and a JSON fetcher/parser aren't mutually exclusive. I'd say
they are complementary.


Joining a bit late here ... 8^)>

Please, if there is any choice, let's not add binary->ascii and ascii->binary format conversions on the code path between the producer and consumer of high volume and/or low latency performance data. I hope the reasons are self-evident to this audience.

Pushing data from PCP via some JSON plumbing seems to be addressing a different, but important use case. Pushing data into PCP via JSON may be required if the producer of the data provides no more efficient API, and is again a different use case.

The mmv model has worked well in the past. If it is not adequate in some respect (e.g. for event records), then I'd advocate making a variant of the mmv model that is refined to address the inadequacies (or even extend the existing mmv model). There is a lot of pain that has been invested in maturing the operational and semantic robustness of the mmv model, so don't discount the effort that would be required to get a completely new model up to the same production standard.

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