And you would expect a user trying to see his usage/stat change on a per
second basis under load to keep doing this? This is pretty much what
we get asked by every customer. Observing change as workload varies is
important to people. I agree with not trying to over engineer but do
think in terms of usability. Listening to your non engineer users once
in a while is not such a bad thing :)
Cheers,
Sunay
Garrett D'Amore wrote:
> Architecturally, parsing the output from netstat is the wrong answer.
>
> But I'm not convinced that we need to go and provide some rich facility
> here. Again, the tendancy from certain engineering groups is to over
> design things. Please don't do that.
>
> A good example of a simple facility is to just offer a very simple
> delimited (or single value) output.
>
> Here's a good example:
>
> kstat -p rge:0:mac:opackets
>
> Now I can trivially take two values and diff them together, using either
> a calculator, spreadsheet, or a couple lines of shell:
>
> kstat -p rge:0::opackets | cut -f2 > /tmp/snapshot
>
> do some work for a bit...
>
> expr `kstat -p rge:0::opackets | cut -f2` - `cat /tmp/snapshot`
>
>
> That took only two lines. And frankly, except for the desire to
> demonstrate it, I'd probably have just used a calculator or expr on the
> command line instead of trying to automate it with parseable output and
> cut.
>
> We don't need to invent all kinds of different ways to analyze data in
> the tools. Let customers do that for themselves. Because once you
> start doing it, you'll have a never ending series of RFEs for different
> kinds of analysis. Just don't go there.
>
> (Or if you really want to go there, look at doing it from within
> something like the analytics tools that are part of fishworks... don't
> burden the command line tools with this penalty!)
>
> - Garrett
>
> Sunay Tripathi wrote:
>> Darren,
>>
>> I appreciate the fact that you wrote a script in 15 min. Do
>> you expect our end users each to write a script or a program
>> and be well versed in sheel/awk to get the basic information
>> they want i.e. cumulative stats and the rate of change? I
>> think we really need to make it easy for people to get that
>> info.
>>
>> I like Jim's suggestion of putting the functionality in a
>> library so other sub commands can use it as well. It
>> doesn't need to be a standalone library if all we have is
>> few things. But keep these separate (at least in source
>> files) so later if they need to be pulled into one library,
>> it will be easy.
>>
>> Cheers,
>> Sunay
>>
>>
>> Darren Reed wrote:
>>> James Carlson wrote:
>>>> Darren Reed writes:
>>>>> When I've had an Internet connection via an ISP that
>>>>> meters traffic (you have a 'quota' of x gb/month),
>>>>> I've run a cron job on the end-of-month day to dump
>>>>> out the output from ipfstat and clear the counters
>>>>> back to 0. Thus at any time during the month, using
>>>>> ipfstat gives me a reasonable approximation of the
>>>>> current quota use.
>>>>
>>>> I think it'd be nice if that cron job didn't have to run with
>>>> privileges sufficient to write to the kernel.
>>>>
>>>> I agree that the delta tool doesn't necessarily have to be part of
>>>> dlstat itself. Perhaps if it were made a common library (along with
>>>> the rest of the column-formatting stuff that Brussels cleaned up),
>>>> that would address most of the concerns.
>>>
>>> A C library?
>>>
>>> To me that seems like making a mountain out of a mole hill...
>>>
>>> 15 minutes and I came up with a perl script to print out what
>>> has changed between two dumps of netstat output - and that's
>>> just a very basic script.
>>>
>>> How long would it take to write in C? Substantially longer
>>> because you've got to go through all sorts of hoops to handle
>>> text input safely. For those that don't like perl, well, use
>>> python or your other favourite scripting langauge.
>>>
>>> Darren
>>>
>>> ./statdiff netstat st.1 st.2
>>> tcpInAckBytes 308
>>> ipInReceives 6
>>> ipOutRequests 5
>>> tcpOutDataSegs 5
>>> tcpOutDataBytes 308
>>> tcpOutSegs 5
>>> tcpRttUpdate 4
>>> tcpInInorderSegs 4
>>> ipInDelivers 6
>>> tcpInAckSegs 4
>>> tcpInSegs 6
>>> tcpInInorderBytes 208
>>>
>>>
>>> #!/bin/perl
>>>
>>> if ($#ARGV ne 2) {
>>> print STDERR "Usaage: <format> <file1> <file2>\n";
>>> exit(1);
>>> }
>>>
>>> if ($ARGV[0] == "netstat") {
>>> %fdata1 = ();
>>> open(F, "<$ARGV[1]");
>>> &netstatfile(\%fdata1);
>>> close(F);
>>> %fdata2 = ();
>>> open(F, "<$ARGV[2]");
>>> &netstatfile(\%fdata2);
>>> close(F);
>>>
>>> }
>>>
>>> foreach $k (keys %fdata1) {
>>> if ($fdata1{$k} ne $fdata2{$k}) {
>>> print "$k\t".int($fdata2{$k} - $fdata1{$k})."\n";
>>> }
>>> }
>>>
>>> exit(0);
>>>
>>> sub netstatfile {
>>> while (<F>) {
>>> chop;
>>> if (/^(\S+)/i) {
>>> s/^$1//;
>>> }
>>> if (/=/) {
>>> while (/\s+/) {
>>> s/\s+//;
>>> }
>>> if (/^([a-z]+)=(\d+)/i) {
>>> $_[0]{$1} = $2;
>>> s/$1=$2//;
>>> }
>>> if (/^([a-z]+)=(\d+)/i) {
>>> $_[0]{$1} = $2;
>>> s/$1=$2//;
>>> }
>>> }
>>> }
>>> }
>>>
>>> _______________________________________________
>>> crossbow-discuss mailing list
>>> crossbow-discuss at opensolaris.org
>>> http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss
>>
>>
--
Sunay Tripathi
Distinguished Engineer
Solaris Core Operating System
Sun MicroSystems Inc.
Solaris Networking: http://www.opensolaris.org/os/community/networking
Project Crossbow: http://www.opensolaris.org/os/project/crossbow
