Hi -
We're investigating to what extent the PCP suite may be suitable for
more general low-level event tracing. Just from docs / source gazing
(so please excuse my terminology errors), a few challenges would seem
to be:
* poll-based data gathering
It seems as though PMDAs are used exclusively in 'polling' mode,
meaning that underlying system statistics are periodically queried
and summary results stored. In our context, it would be useful if
PMDAs could push event data into the stream as they occur - perhaps
hundreds of times a second.
* relatively static pmns
It would be desirable if PMNS metrics were parametrizable with
strings/numbers, so that a PMDA engine could use it to synthesize
metrics on demand from a large space. (Example: have a
"kernel-probe" PMNS namespace, parametrized by function name, which
returns statistics of that function's execution. There are too many
kernel functions, and they vary from host to host enough, so that
enumerating them as a static PMNS table would be impractical.)
* scalar payloads
It seems as though each metric value provided by PMDAs is
necessarily a scalar value, as opposed to some structured type. For
event tracing, it would be useful to have tuples. Front-ends could
choose the interesting fields to render. (Example: tracing NFS
calls, complete with decoded payloads.)
* filtering
It would be desirable for the apps fetching metric values to
communicate a filtering predicate associated with them, perhaps as
per pmie rules. This is to allow the data server daemon to reduce
the amount of data sent to the gui frontends. Perhaps also it could
use them to inform PMDAs as a form of subscription, and in turn they
could reduce the amount of data flow.
* no web-based frontends
In our usage, it would be desirable to have some mini pcp-gui that
is based on web technologies rather than QT.
To what extent could/should PCP be used/extended to cover this space?
- FChE
|