Date: Wed, 3 Apr 2013 10:45:12 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Alfred Perlstein <alfred@ixsystems.com> Cc: arch@freebsd.org, Gleb Smirnoff <glebius@freebsd.org> Subject: Re: [CFR][CFT] counter(9): new API for faster and raceless counters Message-ID: <CAJ-VmokM=BUO=i2roCivjHc5RW8azhaFqsXM%2B9G_jU7sbkHGTg@mail.gmail.com> In-Reply-To: <515C68B5.2010006@ixsystems.com> References: <20130401115128.GZ76816@FreeBSD.org> <20130402232606.GC1810@garage.freebsd.pl> <20130403002846.GB15334@onelab2.iet.unipi.it> <20130403100401.GA1349@garage.freebsd.pl> <515C68B5.2010006@ixsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3 April 2013 10:36, Alfred Perlstein <alfred@ixsystems.com> wrote: > Hey folks, sorry for the top post here, but I just came into this thread. > > Here at iXsystems we've just developed a set of scripts to scrape the > various FreeBSD user land utilities (sysctl, netstat, nfsstat, vmstat, etc, > etc) and put them into graphs based on time. Cool! > The goal is to be able to line up all these metrics with whatever benchmark > we are currently running and be able to see what may be causing issues. > > Potentially you should be able to scroll through the graphs and see things > like "ran out of mbufs @time", "vm system began paging at @time", "buffer > deaemon went nuts @time" > > Then we can take the information back and leverage it to make tuning > decisions, or potentially change kernel algorithms. > > The only problem we have is that every user land tool has its own format, so > along with my team we have written some shell to coerce the output from the > various programs into pseudo-CSV (key/value pair) which can then be post > processed by tools to convert to CSV which can then be put into something > like open office, or put through an R program to graph it. > > I'm hoping to have something shortly. > > What I was hoping to do over the next few days was discuss with people how > we can (or should we even) fix the user land statistics tools to output > machine readable output that can be easily parsed. > > Example: netstat -m (hard to parse) versus 'vmstat -z | grep mbuf' easy to > parse. > > The idea of outputting xml is good, CSV is OK, however CSV is problematic as > in the case of sysctl, if new nodes appear, then we can't begin to emit > them, we must either ignore them, or abort, or log them to auxiliary files. > Anything that makes life easier is good. > > I should be able to share our scripts within the next couple of days. that's quite shiny. It'd be really nice if we could come up with a consistent statistics display, summary and export library. That way we could write tools that used a given data fetch/display API and then we could have optional "things" that implement various export methods. For example, I'm packing up Sam Leffler's "libstatfoo" for inclusion into -HEAD, primarily so the tools that use it (wlanstats, mwlstats, athstats and all the other ath stats programs I'm using) can use it. But once I've converted the stats tool over to that, I can do a few cute things: * the library has a generic way to list all of the supported statistics fields - you register the statistic names with the library, then you can create arbitrary format strings with the information; * the library handles "now" versus "time series" data display itself - you just need to populate the statistic structure with the relevant stats and then call the right function to display things; * I plan on extending it to spit out CSV output as a generic feature, so I can start doing things like importing the output of those tools direct into rrdtool/etc without any intermediary parsing scripts; * .. and if I then add new stats fields, the (requested) output of the script won't change, so tools won't break. adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokM=BUO=i2roCivjHc5RW8azhaFqsXM%2B9G_jU7sbkHGTg>