Hi -
> > The architected way would be to have your pcp client restrict the
> > instance domain for the proc. metrics via pmAddProfile etc. if in the
> > PMAPI, or via appropriate command line options if using CLI tools.
>
> Following your advice I tried to specify on the client (here
> pmlogger spawned by pmmgr) side the perimeter of interest. However
> I did not find any way to explicitly define a subset of process
> based on rules in the pmlogger conf. If there is, don't hesitate to
> let me know.
The pmlogger configuration file language allows listing of instances
(by name or number); as per the pmlogger man page, note the [ ] bits:
log mandatory on every 10 minutes {
disk.all.write
disk.all.read
network.interface.in.packets [ "et0" ]
network.interface.out.packets [ "et0" ]
nfs.server.reqs [ "lookup" "getattr" "read" "write" ]
}
But proc.* metrics are identified by pid#, which are not a priori
fixed. So, a more sophisticated approach is needed, e.g., whereby the
instances of interest are identified by algorithm, synthesizing a
pmlogger configuration file. (Such a file could sit in a place where
a pmmgr-managed pmlogger instance could find it.) If the set of
target processes does not vary much, this could work well.
> I also tried the blunt approach (-U) which I did not manage to
> properly use, I suppose, since I always saw all the processes,
> regardless of whether or not I was supplying the -A argument to
> pmdaproc. [...]
(Listings, yes, but not quite full access to their info. OTOH
linux /proc publishes a lot of per-process info to unprivileged
users.)
- FChE
|