From owner-freebsd-hackers@freebsd.org Sun Dec 11 20:12:37 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4365C722B5 for ; Sun, 11 Dec 2016 20:12:37 +0000 (UTC) (envelope-from jonathan@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C57EC6E8; Sun, 11 Dec 2016 20:12:37 +0000 (UTC) (envelope-from jonathan@FreeBSD.org) Received: from [192.168.42.150] (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) by freefall.freebsd.org (Postfix) with ESMTP id CB4F1744F; Sun, 11 Dec 2016 20:12:36 +0000 (UTC) (envelope-from jonathan@FreeBSD.org) From: "Jonathan Anderson" To: "Allan Jude" Cc: freebsd-hackers@freebsd.org Subject: Re: Sysctl as a Service, or: making sysctl(3) more friendly for monitoring systems Date: Sun, 11 Dec 2016 16:42:38 -0330 Message-ID: <200A5D70-24CE-4843-B99D-E10A2AF4F68F@FreeBSD.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5310) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2016 20:12:38 -0000 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@FreeBSD.org