Hi, David -
> [...]
> For another comparison, pmdapapi starts collecting perfctr data only
> after/while clients fetch those specific metrics.ï It continues
> collecting those as long as a clients keep polling (with a timeout),
> then releases the perfctr resources back to the kernel.
>
>
> If I was to use such a scheme for SMART, I assume I'd still need to read
> attributes once at startup, and also whenever a new disk appears, since I need
> to be able to correctly report all the available metrics?ï That sounds a bit
> more complex.
Not sure it's any more complex. In this scheme, we'd scan once (for
metadata) at startup, and scan periodically as activity requires. In
the other scheme, we'd scan once (for metadata) and scan periodically
whether or not activity requires. The difference need be nothing
other than a timer with an on/off switch.
> Also, wouldn't it be silly to install a PMDA you're never going to retrieve
> metrics from anyway?
Um, not really ... and "never" is going too far anyway. Erring on the
side of installing software for hypothetical / intermittent use is
easy & painless, as long as it does not incur run-time costs.
> Something like:
> smart.attr.by_number.99
> smart.attr.by_name.reallocated_sector_ct
> (ignoring how I'll deal with vendor-specific attributes for now)?
Yup.
> [...]
> I note that I just found that the 'smartctl --presets=showall' command gives a
> dump of this information which is a lot easier to parse
Even better.
> I take it that this solution, whilst not guaranteeing that metric
> numbers will be stable forever, is probably good enough?
Yes, especially considering we don't spell out the persistence
guarantees in the docs.
> [...] Thanks!ï I gather that sometimes people aren't happy about
> bugs filed against RHEL that have only been found in CentOS, but
> I'll give it a try.
(In the rare case problems can't be reproduced on RHEL/Fedora, they
might get NEEDINFO / CLOSED+CANTFIX'd.)
- FChE
|