pcp
[Top] [All Lists]

Re: pmwebd oddity?

To: Michele Baldessari <michele@xxxxxxxxxx>
Subject: Re: pmwebd oddity?
From: fche@xxxxxxxxxx (Frank Ch. Eigler)
Date: Mon, 13 Oct 2014 15:02:14 -0400
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <20141013184310.GE19405@xxxxxxxxxxxxxxx> (Michele Baldessari's message of "Mon, 13 Oct 2014 20:43:10 +0200")
References: <20141013184310.GE19405@xxxxxxxxxxxxxxx>
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)
Hi, Michele -

> it's likely something silly I am doing, but at the moment I am just not
> seeing it. I am printing out my ADSL bandwith using pmwebd/json and an
> Arduino [1].

Yup, saw it, cute!


> [...]
> Now, leaving aside for a second how fragile and broken by design the whole 
> thing is,
> everything works via pminfo but not via pmwebapi:
> - pminfo -f -m -M shping.error
> shping.error PMID: 19.0.10 = 79691786 = 0x4c0000a
>     inst [0 or "8.8.8.8"] value 52

Right, note that pminfo defaults to "-h local:".

> - pmwebd returns empty values :

> GET /pmapi/747499891/_fetch?pmids=79691786 HTTP/1.1
> [...]
> { "timestamp": { "s":1413224370, "us":801625 },
> "values": [
> ] }

How was that context 747499891 created?  /pmapi/context?local=ANYTHING
is not the same thing; use /pmapi/context?hostname=local: instead.
Perhaps pmwebd should default to -h local: (and support an unparametrized
/pmapi/context?) the same way pm* clients do.  Opinions? 

If that's not the problem - if you're using -h local: context via
pmwebd also, then it could be time for libpcp debugging type work, namely
invoking "pmwebd -Dall ..." and gaze at the trace data.


- FChE

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