Hi -
be.nicolas.michel wrote:
> We want to give a try to PCP with a centralized pmlogger, and web
> plotter like grafa or graphite. It should be great for visualizing
> the global performance metrics on our servers.
OK, might want to try the pcp 3.10.0 + the webapps code, which should
handle apprx. all that out-of-the-box.
> However, when analyzing performance issues, one also often need to
> go deeper and grab performance metrics at the process level (which
> process consume I/O or memory or CPU at a given time). [...]
That's a little trickier, for a few reasons.
First, pcp usually relays data in a relatively raw form from the
kernel. For the "proc.*" metrics, you can get some per-process status
and statistics, but finding the "top" (by whatever metric) would be left
to your application, and about actual I/O etc. trace type traffic, are
not routinely exposed by the kernel.
Second, the proc.* data is relatively large, so it is not normally
turned on for routine background logging. If you can narrow your
interest to a few metrics of the processes, or perhaps even to a few
particular process instances, then routinely logging them is probably
fine.
Third, if you need to change on-the-fly the logging configuration (so
as to add more proc.* stuff temporarily, or change sampling rates, for
example), there is currently simple no web frontend nor
multiple-pmlogger-affecting mechanism for this. The pmlc program can
adjust a single running pmlogger to some extent. Another way could be
to use a pmmgr instance to supervise a stable of pmloggers for the
remote boxes. pmmgr can recompute pmlogger configuration files from
fragments you modify (to add/subtract proc.* etc.) & restart all the
pmloggers on demand. pmwebd can present a glued-together view of the
various archive files to the graphical webapps across restarts.
- FChE
|