pcp
[Top] [All Lists]

Re: RFC: fetchgroup api

To: Marko Myllynen <myllynen@xxxxxxxxxx>
Subject: Re: RFC: fetchgroup api
From: "Frank Ch. Eigler" <fche@xxxxxxxxxx>
Date: Sun, 29 Nov 2015 12:51:05 -0500
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <565B3839.1090505@xxxxxxxxxx>
References: <20151125064821.GA27272@xxxxxxxxxx> <5656970C.10103@xxxxxxxxxx> <56583F8C.3010705@xxxxxxxxxx> <y0mzixzmsrx.fsf@xxxxxxxx> <565B3839.1090505@xxxxxxxxxx>
User-agent: Mutt/1.4.2.2i
Hi, Marko -

> >> - how would you use the API with non-leaf PMNS nodes?
> [...]
> Do you think something like below would be achievable or how would you
> deal with N pmExtendFetchGroup_item calls in Python?
> [...]
>   atoms = []
>   metrics = []
>   def add_metric(metric):
>     metrics.append(metric)
>     pmExtendFetchGroup_item(pmfg, metric, None, None, atoms, PM_TYPE_STRING)
>   def test():
>     pmfg = pmCreateFetchGroup()
>     pmTraversePMNS("disk.dev", add_metric)
> [...]

Yeah, that sort of thing should work (from python or C).  In the
Python case, I'm hoping to abstract a little more.


> [...]  By the way, one of the items in pmrep todo-list is handling
> counter wrapping. According to PCPIntro(1) it's disabled by default
> nowadays (not sure why it was changed), do you plan to handle that
> with fetch groups?

It'd be nice to do it consistently with other rate-conversion code in
pcp; there are probably three or four different places now.  We've
also encountered situations where rates are of interest, but for
metrics that aren't monotonically-increasing counters.  So
wrapping-awareness code would have to be semantic-aware.  Dunno.


- FChE

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