From: "Frank Ch. Eigler" <fche@redhat.com>
To: pcp@oss.sgi.com
Cc: systemtap@sources.redhat.com
Subject: suitability of PCP for event tracing
Date: Fri, 27 Aug 2010 15:39:00 -0000 [thread overview]
Message-ID: <20100827153906.GD3185@redhat.com> (raw)
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
next reply other threads:[~2010-08-27 15:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-27 15:39 Frank Ch. Eigler [this message]
2010-08-29 15:55 ` [pcp] " Ken McDonell
2010-09-01 15:05 ` David Smith
2010-09-06 16:39 ` Ken McDonell
[not found] ` <4C7A7DFE.2040606@internode.on.net>
2010-08-31 3:29 ` Greg Banks
2010-08-31 19:49 ` Frank Ch. Eigler
2010-09-01 6:25 ` Mark Goodwin
2010-09-02 2:05 ` Greg Banks
2010-09-02 19:40 ` Frank Ch. Eigler
2010-09-12 16:43 ` Ken McDonell
2010-09-13 2:21 ` Greg Banks
2010-09-13 13:29 ` Max Matveev
2010-09-13 20:53 ` Ken McDonell
2010-09-13 20:39 ` Frank Ch. Eigler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100827153906.GD3185@redhat.com \
--to=fche@redhat.com \
--cc=pcp@oss.sgi.com \
--cc=systemtap@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).