Hi,
On 2016-06-20 21:09, Frank Ch. Eigler wrote:
> 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.
Ok, so the in case of pmrep this sounds like an additional item for
future cleanups to get rid of some internal data structures, I don't
mind if it takes two extra lines to get the needed data from pmfg's
context if that allows getting rid some of the still carried along data
storage. Of course on Python level extra helpers are always welcome :)
> 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.
This sounds interesting indeed; so pmrep would just let pmfg know what
metrics to record and then according to the interval ask pmfg to record
the next set of values to the archive, other clients might have some
much more clever heuristics than just the basic interval? If the "basic"
mode would be to record metrics set X, how a client would then ask
another set Y to be recorded? Would there be different groups or should
metrics be added/removed on the fly or how do you envision this to happen?
Thanks,
--
Marko Myllynen
|