Hi, David -
> I finally got a good bit of this working (I haven't implemented units
> support yet).
Thanks! I had a look through this; nice progress!
> I did make a few changes to the metadata format when it comes to arrays.
> [...]
> I changed things around a bit to make it easier to implement and perhaps
> be a bit more readable: [...]
Looks good!
A few notes & suggestions for next steps:
> "type": "integer"
> "type": "string"
It should not be too hard to expose all the scalar PM_TYPE_* types;
the pmda/python fetch_callback binding can handle them (apprx.) all.
Semantics, and scale/units (parse via pmParseUnitsStr) should also be
configurable.
Please give a rescan to the previous proposal re. configuring the pmda
with a search path of directories. Maybe choose a file name extension
for the metadata files that the pmda can glob for. The /proc/systemtap
path should not need to be hard-coded - and for that matter, no systemtap
specificity remains in the pmda, so it could be just renamed pmdajson or
somesuch.
The code needs to spell out a policy for refreshing the metadata/pmns.
Doing it for each incoming pcp fetch is very likely excessive (unless
perhaps there's clever fstat/mtime caching). Perhaps do it by timer,
or a .control.refresh metric set?
Similarly, it needs to spell out a policy for refreshing the payload
data. Doing it once per fetch-item (metric+instance tuple, i.e.,
__fetch_callback) is very likely excessive; once per incoming fetch
could be OK (once per set_fetch() pre-fetch-callback) ... except that
this call doesn't get supplied with all the pmids requested, so can't
limit itself to reading only the json files of interest. So maybe
have the __fetch_callback memoize payload files' contents, and have
the set_fetch callback clear that memoize table beforehand.) Making
sense?
- FChE
|