Hi -
> [...]
Please see the rebased fche/fetchgroup branch for a v3.
The remaining work, AIUI:
- blurbage in books ... pcp-programmers-guide; planning to
replace/update discussion of pmclient.c
- think about how to expose events to pmfg; irc thinking-out-loud
transcript follows. I'd appreciate a thought-review before I go
and try to hack it up.
<myllynen> fche, btw, it's obvious that event support in pmfg is not trivial
but what's your current gut feeling about it, is it even worth the shot or will
it be too messy?
<fche> I think it's only practical to address restricted cases of it
<fche> ie not the whole vector-of-trees
<fche> but maybe something like vector-of-single-node-in-tree
<lberk> haha
<fche> i.e., kind of half way between a metric and an indom: ask pmfg to
retrieve a metric + a given event-field-pmid somewhere beneath the event record
tree into a vector of (timestamp,value) tuples
<fche> so taking the pmdasystemd data source as an example
<fche> pmfg_extend_event
("systemd.journal.records:systemd.journal.field.string", &vec)
<fche> where vec would be a (preallocated) array of (struct timeval,
pmAtomValue) tuples
<fche> which we'd fill, walking all the event records and all their matching
fields
<fche> so if an app wanted a different record field out of the events, they'd
have to have a second pmfg_extend_event call identifying that field
<fche> and it would have to match up corresponding records by matching
timestamps
<fche> that's about the best I can think of .......
<fche> so for trivialish event-pmda sources, this should work ok; systemd is
relatively sophisticated; for pmdapipe it seems to emit only individual
pipe.line fields
<fche> so is reltaively trivial
commit a09ce18bab614da812a22547991726cf4f72742f
Author: Frank Ch. Eigler <fche@xxxxxxxxxx>
Date: Tue Dec 15 15:16:26 2015 -0500
pcp fetchgroup v3: with a more private context
As per review comments:
- a fetchgroup now owns a private pmapi context it creates via
pmNewContext, so pmDupContext is no longer relevant
- ... which it is willing to expose, with appropriate documentation
cautions
- which moots pmFetchGroupSetMode, so it's gone
- tests extended to cover interleaving,
- rate conversion failure due to missing history is PM_ERR_AGAIN'd
- a little bit more initialization is promised by a few few functions
pmstat, pmclient, pmmgr, python-bindings, test cases updated. pmmgr
more fully converted to pmfg (the container enumeration was previously
overlooked).
|