hash components out of order

vortmax has asked for the wisdom of the Perl Monks concerning the following question:

I wrote a script that is a simplified version of cacti. You give it an IP, an interval, time limit and options to monitor and it generates an rrd archive.

full script is here:

#!/usr/bin/perl
use strict;
use warnings;
use Proc::Daemon;
use Proc::PID::File;
use Cwd;
use Getopt::Std;

sub usage()
{
        print STDERR << "EOF";

        This program monitors an IP at set interval for a specified du
+ration of time.

        usage: [UDsrtmLRAch] [-i interval] [-d duration] [-C string] [
+-n name] ip

        -i seconds  :  The interval in seconds on which to send a ping
+ (default = 10)
        -d seconds  :  The total number of seconds to run the test (de
+fault = 86400 or 1 day)
        -n name     :  Name for the RRD archive (default = current tim
+e stamp)
        -C string   :  SNMP community string (default = community)
        -U          :  Upstream bits
        -D          :  Downstream bits
        -s          :  SNR
        -r          :  RX power
        -t          :  tx power
        -m          :  micro-reflections
        -L          :  Lost Downstream Syncs
        -R          :  Resets
        -A          :  Aborted Ranging attempts
        -c          :  Channel ID
        -h          :  Display this dialog

EOF
        exit;
}



my %opt;
getopts("n:i:d:C:UDsrtmLRAch", \%opt);
usage() if $opt{h};

my $interval = $opt{i} || 60;
my $duration = $opt{d} || 86400;
my $name     = $opt{n} || $ARGV[0];
my $string   = $opt{C} || 'community';
my $ip       = $ARGV[0] or usage();

my $pwd = getcwd();

my ($DS, $start, $finish, $elap, $ping_time);


my $now = time();
my $stop = $now + $duration;
my $int_end = $interval*2;
my $points = $duration/$interval;

$DS .= " DS:Upstream:COUNTER:$int_end:0:U" if $opt{U};
$DS .= " DS:Downstream:COUNTER:$int_end:0:U" if $opt{D};
$DS .= " DS:SNR:GAUGE:$int_end:0:U" if $opt{s};
$DS .= " DS:RX:GAUGE:$int_end:0:U" if $opt{r};
$DS .= " DS:TX:GAUGE:$int_end:0:U" if $opt{t};
$DS .= " DS:micro:GAUGE:$int_end:0:U" if $opt{m};
$DS .= " DS:LostSync:COUNTER:$int_end:0:U" if $opt{L};
$DS .= " DS:Reset:COUNTER:$int_end:0:U" if $opt{R};
$DS .= " DS:Aborts:COUNTER:$int_end:0:U" if $opt{A};
$DS .= " DS:ChannelID:GAUGE:$int_end:0:U" if $opt{c};


`rrdtool create $pwd/$name.rrd  --step $interval $DS RRA:LAST:.5:1:$po
+ints`;



#Proc::Daemon::Init();

my %data;
my $key;
while(time() < $stop){
        $start = time();

        my $update_string = "N";

        chomp($data{'out'} = `snmpget -v1 -c $string $ip 1.3.6.1.2.1.2
+.2.1.16.1`) if $opt{U};
        chomp($data{'in'} = `snmpget -v1 -c $string  $ip 1.3.6.1.2.1.2
+.2.1.10.1`) if $opt{D};
        chomp($data{'snr'} = `snmpget -v1 -c $string $ip  1.3.6.1.2.1.
+10.127.1.1.4.1.5.3`) if $opt{s};
        chomp($data{'rx'} = `snmpget -v1 -c $string  $ip  1.3.6.1.2.1.
+10.127.1.1.1.1.6.3`) if $opt{r};
        chomp($data{'tx'} = `snmpget -v1 -c $string  $ip 1.3.6.1.2.1.1
+0.127.1.2.2.1.3.2`) if $opt{t};
        chomp($data{'micro'} = `snmpget -v1 -c $string $ip  1.3.6.1.2.
+1.10.127.1.1.4.1.6.3`) if $opt{m};
        chomp($data{'lost'} = `snmpget -v1 -c $string $ip  1.3.6.1.2.1
+.10.127.1.2.2.1.5.2`) if $opt{L};
        chomp($data{'resets'} = `snmpget -v1 -c $string $ip  1.3.6.1.2
+.1.10.127.1.2.2.1.4.2`) if $opt{R};
        chomp($data{'aborts'} = `snmpget -v1 -c $string $ip  1.3.6.1.2
+.1.10.127.1.2.2.1.14.2`) if $opt{A};
        chomp($data{'channel'} = `snmpget -v1 -c $string $ip  1.3.6.1.
+2.1.10.127.1.1.2.1.1.4`) if $opt{c};

        foreach $key (keys (%data)){
                $data{$key} =~  m/: (\d+)/;
                $update_string .= ":$1";
        }
        print $update_string;
        print "\n";
        `rrdtool update $pwd/$name.rrd $update_string`;

        $finish = time();
        $elap = $finish - $start;
        sleep($interval-$elap);
}
[download]

When it polls the device with snmp, it write the result to a hash, then marches through the hash to create the rrdtool update string. It relies on the items in the has being accessed in the same order they were filled. So if I run :

monitor -i 10 -d 60 -n 172.16.16.250 -sUD 172.16.16.250 it should write an update string like:

rrdtool update archive.rrd N:out:in:snr

instead its writing:

rrdtool update archive.rrd N:out:snr:in

what is changing the order and is there a either a way to prevent it from changing or a better approach?

Comment on hash components out of order Download Code

Replies are listed 'Best First'.
Re: hash components out of order by Fletch (Bishop) on Aug 22, 2008 at 20:56 UTC
Hashes are by definition unordered. If you need the insertion order to be preserved you'll have to resort to something like Tie::IxHash. The cake is a lie. The cake is a lie. The cake is a lie.	[reply]
Re: hash components out of order by Tanktalus (Canon) on Aug 22, 2008 at 21:04 UTC
That's the nature of hashes - in order to give you constant-time access to any element in the hash, regardless of size, the tradeoff is that perl gets to control the ordering of keys. And that order should be somewhat random to provide this ability (look up what "hashing" is in computing science). What you want is a list. Say an order of operations: `my @datums = ( { field => 'out', snmptag => '1.3.6.1.2.1.2.2.1.16.1', opt => 'U' }, { field => 'in', snmptag => '1.3.6.1.2.1.2.2.1.10.1', opt => 'D' }, # ... # read 'em in (probably don't care about order, but what the heck) for my $datum (@datums) { chomp($data{$datum->{field}} = qx/snmpget -v1 -c $string $ip $datum- +>{snmptag}/) if $opt{$datum->{opt}}; } $update_string = join ':', 'N', map { /: (\d+)/; $1 } @data{ map { $_- +>{field} } @datums };` [download] (untested) I don't really understand what you're doing, so I could have easily misinterpreted some of your code. Note that we probably could get rid of the %data hash, too, and instead just populate a list directly in your order. `my @fields = map { qx/snmpget -v1 -c $string $ip $_->{snmptag}/ =~ /: (\d+)/; $1 } grep { $opt{$_->{opt}} } @datums; $update_string = join ':', 'N', @fields;` [download] Probably a bit easier to read. (and just as tested)	[reply] [d/l] [select]
Re: hash components out of order by mr_mischief (Monsignor) on Aug 22, 2008 at 21:02 UTC
If you'd rather not mess with tied hashes and all the magic surrounding them, you could allow them to remain stored out of order and just process them in order. Replace: `foreach $key (keys (%data)){` [download] With: `foreach $key (sort keys (%data)){` [download] ... for example.	[reply] [d/l] [select]
Re: hash components out of order by toolic (Bishop) on Aug 22, 2008 at 20:57 UTC
By their nature, hashes are unordered. You could try to use the CPAN module,Tie::IxHash, which "implements Perl hashes that preserve the order in which the hash elements were added."	[reply]
Re^2: hash components out of order by vortmax (Acolyte) on Aug 22, 2008 at 21:00 UTC
okay thanks	[reply]
Re: hash components out of order by NetWallah (Canon) on Aug 23, 2008 at 05:42 UTC
Just wanted to ensure that you are aware of the existence of RRD::Simple and RRDTool:OO, which can make your code easier to write and read, since you appear to be re-inventing MRTG. Have you been high today? I see the nuns are gay! My brother yelled to me...I love you inside Ed - Benny Lava, by Buffalax	[reply]