----- Original Message -----
>
> OK, let's confirm that it's low-cost, and that it actually works if
> e.g. the same host comes and goes several times during a day (so new
> archives need to be created for each pmlogger launch).
I have only anecdotal evidence to offer without spending deeper time on
it. From the years I spent at Aconex where they have been using this
mechanism for quite some time, at no time did I have reason to wonder if
it was either unreliable in starting new loggers, or if it caused any
noticeable resource consumption while running (and that on the much-
shortened 5 or 6 minute crontab, which would tax resources more heavily
than the 30 minute default). And there is quite alot of analysis of PCP
data done over there, it certainly would have been noticed.
Many were the times that puppet came up as a CPU-burning, memory-hogging
behemoth, just as an aside - but never these shell scripts.
> ...
> Given that pmlogger_daily is also a default-on cron job now (right?),
Yes, that's correct (on Linux only, wasn't sure re other platform support
for this concept, so I left them as-is).
> perhaps this -T flag should be a default to those instances invoked by
> pmlogger_check.
*nod* - also, would anyone have reservations about adding the -r option
by default too? (for easier estimation of expected log sizes)
[unless I hear otherwise, at this stage I'm planning to set an increased
timeout using Jeffs suggestion, an extra -T 24h10m and the -r option...]
> Another issue is cleanup of the archives left over by prior logger
> targets.
The compressing/culling of their old /var/log/pcp/pmlogger/*/* files?
IIRC, that is done using find and not the contents of the control files,
so I *think* that one's a non-issue - files from rogue loggers should be
dealt with there (if not, its at least fixable by using find).
cheers.
--
Nathan
|