On Thu, 2007-03-22 at 19:27 +1100, Max Matveev wrote:
> >>>>> "nscott" == Nathan Scott <nscott@xxxxxxxxxx> writes:
>
> nscott> Hi (ghost of?) Max,
> Boo!
Eek!
> nscott> No, not sure that will help - PM_TYPE_NOSUPPORT is -1, which
> nscott> will trip the less-than-zero guard on the fetchCallback call
> nscott> in libpcp_pmda, and that will end up in the same fprintf.
> nscott> No?
>
> No. The idea here is to cut all calls to pmdaFetch for the metric you
> don't support.
Oh, I see - no that wont fly eitherm its a bit more dynamic
than that - the metric is supported for some instances, but
not others. Theres one indom shared across all metrics in
the agent, and some of the values are for some of the metrics
are sometimes not supported (depending on the "things" being
monitored, which are software "things", that can be upgraded/
stopped/started independently).
Separate indoms for each metric isn't really an option either.
> First of all, if a metric is "intermittent" then you
> have an option to return empty pmResult from the fetch - this is a
> valid response. But if you're sure that metric is not going to be
> available at all then either return error from pmLookupDesc to stop
> clients from calling you or give them a descriptor with NO_SUPPORT
> type and that should stop them too.
I see what you mean now, but in this case thats not going to fly
for me. I think I'll run with a variant on Daves patch for now.
> PS. I wonder what would it take to make pcp@xxxxxxxxxxx a
> subscriber-only list?
That sounds like a good idea (Chatz suggested same yesterday)...
guess we talk to Trev (or whoever the pcp list admin is - maybe
its Mark still)?
cheers.
--
Nathan
|