pcp
[Top] [All Lists]

Re: pmfg vs pmi

To: Marko Myllynen <myllynen@xxxxxxxxxx>
Subject: Re: pmfg vs pmi
From: fche@xxxxxxxxxx (Frank Ch. Eigler)
Date: Mon, 20 Jun 2016 14:09:51 -0400
Cc: pcp developers <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <5767DA6F.9050104@xxxxxxxxxx> (Marko Myllynen's message of "Mon, 20 Jun 2016 14:58:39 +0300")
References: <5767DA6F.9050104@xxxxxxxxxx>
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)
myllynen wrote:

> [...]  With pmfg it's easy to report metrics but if one would want
> also to write archives, then it seems that pmfg and pmi do not dance
> together very well.  [...]

The pmi bindings are not too bad to use for data acquired by pmfg:
have pmfg convert values to strings via extendFetchGroup_indom;
iterate on the resulting rows.

The main complication is that pmi would like pmDesc-type metadata
supplied to pmi.Add*, which pmfg doesn't expose.  So one could grab
the pmfg's context and do pmLookupName's to fill in that stuff, or
perhaps pmfg could be extended with an option to return pmDesc data.

A prettier system might consist of inventing a pmimportgroup type API
that's a dual to pmfetchgroup, done with the intent of making it easy
to represent a data-source-to-archive processing pipeline.  It gets
interesting when one doesn't just want to copy verbatim, but applies
filters or semantic compression heuristics, or varies the set of
metrics in response to instructions or changing conditions.

- FChE

<Prev in Thread] Current Thread [Next in Thread>
  • pmfg vs pmi, Marko Myllynen
    • Re: pmfg vs pmi, Frank Ch. Eigler <=