Sysctl as a Service, or: making sysctl(3) more friendly for monitoring systems

[Jonathan Anderson]

On 11 Dec 2016, at 16:25, Allan Jude wrote:

> On 2016-12-11 14:35, Ed Schouten wrote:
>>
>> The other day I was thinking: in a certain way, the node exporter is 
>> a
>> bit of a redundant tool on the BSDs. Instead of needing to write
>> custom collectors for every kernel subsystem, we could write a 
>> generic
>> exporter for converting the entire sysctl(3) tree to Prometheus
>> metrics [...]
>>
>> A final remark I want to make: a concern might be that changes like
>> these would not be generic, but only apply to Prometheus. I tend to
>> disagree. First of all, an advantage of Prometheus is that the
>> coupling is very loose: it's just a GET request with key-value pairs.
>> Anyone is free to add his/her own implementation.
>
> I would find this very useful. I've wanted to have something like 
> this,
> and expose more data (especially re: disks) via sysctl for a long 
> time.
>
> The nonsense we do to deal with monitoring dev.cpu.[0-n].temperature 
> and
> deal with it are rather annoying.
>
> I like the sound of everything you propose. Especially flagging 
> sysctls
> so it is possible to programmatically get 'type' information.

I, for one, agree, and at the risk of being slightly provocative, I 
think it could be taken even further. :) I'd love to be able to retrieve 
a sysctl entry or subtree as an nvlist_t. Rather than doing lots of 
system calls to enumerate clearly-related sysctl values, it would be 
very cool to do one system call and then inspect the resulting data 
structure in memory. We already use libnv in a number of places, and it 
seems like it could be a natural mapping from the sysctl hierarchy.


Jon
--
Jonathan Anderson
jonathan at FreeBSD.org