Hi -
A couple of hours of work, porting cockpit (cockpit-project.org) from
its /proc-scraping C code to pcp PMAPI, have resulted in some code
that I can't in good conscience recommend. This is mainly due to
shortcomings in our code:
- The API is really wordy for basic tasks such as extracting and
scaling some metrics. It takes several setup steps, several arrays
of data, several error-prone array/pointer arithmetic, with
error-handling at each step. It adds up to way too much code - it's
>100 lines, and not done yet. We need a higher level API that
combines the lookup/indom/fetch/extract/scale steps (doing internal
caching/lookups as necessary), with the goal of making it easy to
interface with an enclosing application.
- The linux-proc PMDA is not as efficient as it could be; see the bug
filed last night. This is only a quality-of-impllementation matter,
but as we trumpet light-weightness of the pmcd/agent system, we need
to do better.
- Multithreaded support has had long-known bugs that preclude their
heavy-duty use in a real application (pmwebd / graphite), even for
just archives. It turns out that for light-duty use, there is not
enough support either. For the cockpit application, we might like
to use PM_CONTEXT_LOCAL, but that is precluded for multithreaded
apps. PM_CONTEXT_HOST to local: is fine in theory, but due to the
single-threadedness of pmcd, it snuffs out any possible advantage
anyway. We should at least permit multithreaded PM_CONTEXT_LOCAL,
and do internal serialization, say on a per-PMDA-SO basis. (PMCD
could probably do the same.)
- A small nit, it would be helpful if libpcp came with a pkgconfig
file, so that non-system copies of libpcp could be found by
applications.
Assuming no objections, I'll start assembling some more concrete
proposals for these shortly.
- FChE
|