Re: [pcp] Floating point problem

[Martin Spier <mspier@xxxxxxxxxxx>]

My understanding was that the original metrics, kernel.all.cpu.user and kernel.all.cpu.sys suffered from the same problem. If that's not the case, I completely agree with option 2.

On Wed, Jul 30, 2014 at 3:59 PM, Ken McDonell <kenj@xxxxxxxxxxxxxxxx> wrote:

On 31/07/14 08:00, Brendan Gregg wrote:

..

I actually like 2. It's simple.

I'd like to not just fetch per-second metrics, but possibly other
intervals at the same time, including per-hour and per-day. And possibly
from multiple clients. And possibly ad-hoc queries. With 2, I simply
stash away whatever cumulative values and timestamp pairs, and use them
later when needed.

Excellent.

2. is more consistent with the PCP philosophy where rate conversion (which is but one form of aggregation) is preferably the domain of the clients consuming the performance data, rather than the producers of the data.

You'll need to stash the timestamps from the fetches also to do the rate conversion (or other temporal averaging) based on the consistent timestamps at the source of the data.

If you start to do serious aggregation, you'll also need the metadata to know if a metric is a counter or not and to allow correct scaling, e.g. to get the units of time for the CPU metrics, so you can scale as required before dividing by the delta in the timestamps.

This has all be done before (as Frank points out!), so lemme know if you need any assistance.