On 06/05/14 04:42, Michele Baldessari wrote:
...
And if Frank's general suggestion below /var/log/pcp does not already catch
these, I'd suggest adding /var/log/pcp/pmie/<hostname> and
/var/log/pcp/pmproxy.
If the files in there end up with *config or *log, we are covered.
> ...
Also /var/log/pcp/pmwebd and /var/log/pcp/pmmgr may contain relevant info,
but I'll defer to Frank who's the expert on these ones.
Same here, if the files end with .log or .config.
Hmm, not quite
Can we add .log.prev to the suffixes list? Sometimes the bad thing
you're looking for was _before_ the last reboot or pmcd restart, and the
.prev files may be helpful here.
The pmmgr subdirectory also contains config.* files (not *.config), and
a bunch of PCP archives in pmmgr/<hostname> similar to pmlogger/<hostname>
Now the archives are a bit tricky ... it looks (I've never checked this
before) like pmmgr _and_ pmlogger_control/pmlogger_daily may be both
running collecting archives with the very similar, but not identical
pmlogger configuration files. This is the case on my workstation, but
that could be decades away fro a default install.
I would expect that depending on local enable/disable actions by a
sysadmin, you may have neither, one or the other, or both sets of archives.
When both are available, it is further complicated by the fact that the
actual configuration file for the two pmloggers may have been modified
by local sysadmin action.
I don't have a good heuristic to choose one if you want to avoid
capturing both, but ..
One of my goals with this sosreport exercise, is to create a script like
sarstats[1] that I can simply point at an uncompressed sosreport and
quickly get a decent overview of the main PCP stats collected on the
machine.
OK, one possible heuristic is
1. start with metrics you need for a sarstat-like tool ... as a starter,
check the calls to put() and putinst() in sar2pcp from the pcp rpms
2. process the most recent archive from each of
/var/log/pcp/{pmlogger,pmmgr}/<hostname> and use pminfo -a
<archive>.meta to get the metrics in that archive, cull those not in the
list from 1.
3. choose the archive with the longest matching list of metrics from 2.
This sort of assumes the last archive in each directory is easily found
(lexical sorting will work, pick the .meta files as these must be there
and are unique) and that this archive is currently active (pminfo -f
pmcd.pmlogger.archive will help ... in fact that avoids any lexical
sorting completely and only lists the active ones).
And it assumes the logging intervals for the metrics are similar (true
by default I think).
Hope this helps rather than confuses the issue.
|