[mrtg] Re: unknown values recorded as '0' when using multi target syntax

[Irwin Tillman]

To answer my own question:

The code where the value of a complex target is located in getcurrent().
My fix is to examine each variable term of the complex expression
to see if it evaluates to -1 (the unknown value).  If so, I set the
result to -1; else I evaluate the complex expr as before.  There's
a performance hit due to the additional eval()'s.

I.e. in getcurrent(), I replaced:

    $inlast = eval("my \$mode='_IN_';$$rcfg{target}{$rou}");
    if (defined $inlast and $inlast != $inlast * 1 or $@) {
    die "ERROR: Target[$rou] eval warning: $@\n" if $@;
        $inlast = undef;
    warn "WARNING: Target[$rou]: $$rcfg{targorig}{$rou} did not evaluate to an integer";
    };
    $outlast = eval("my \$mode='_OUT_';$$rcfg{target}{$rou}");
    if (defined $outlast and $outlast != $outlast * 1 or $@) {
    die "ERROR: Target[$rou] eval warning: $@\n" if $@;
        $outlast = undef;
    warn "WARNING: Target[$rou]: $$rcfg{targorig}{$rou} did not evaluate to an integer";
    };


with:

    if (grep $_ == -1, map eval("my \$mode='_IN_'; $_"), grep(/\$/, split(' ', $$rcfg{target}{$rou}))) {
        # At least one term was -1, so claim that the entire complex expr is -1 (unknown).
        $inlast = -1;
    } else {
        # All the terms are known values, go ahead and compute the complex expr normally.
        $inlast = eval("my \$mode='_IN_';$$rcfg{target}{$rou}");
        if (defined $inlast and $inlast != $inlast * 1 or $@) {
            die "ERROR: Target[$rou] eval warning: $@\n" if $@;
            $inlast = undef;
            warn "WARNING: Target[$rou]: $$rcfg{targorig}{$rou} did not evaluate to an integer";
        };
    }
    if (grep $_ == -1, map eval("my \$mode='_OUT_'; $_"), grep(/\$/, split(' ', $$rcfg{target}{$rou}))) {
        # At least one term was -1, so claim that the entire complex expr is -1 (unknown).
        $outlast = -1;
    } else {
        # All the terms are known values, go ahead and compute the complex expr normally.
        $outlast = eval("my \$mode='_OUT_';$$rcfg{target}{$rou}");
        if (defined $outlast and $outlast != $outlast * 1 or $@) {
            die "ERROR: Target[$rou] eval warning: $@\n" if $@;
            $outlast = undef;
            warn "WARNING: Target[$rou]: $$rcfg{targorig}{$rou} did not evaluate to an integer";
        };
    }


Of course, for this to work you must also have also patched mrtg so that when it
goes to record '-1' in an rrd database, it stores 'U', not -1.    That's a patch
that's been posted previously on a mailing list, and solves the problem for 
simple targets.

I.e. in writegraphics(), replace this:

        # update the rrd
        $inlast = 'U' unless defined $inlast;
        $outlast = 'U' unless defined $outlast;
        RRDs::update("$rrd", "$time:$inlast:$outlast");

with this:

        # update the rrd
        $inlast = 'U' unless defined $inlast;
        $outlast = 'U' unless defined $outlast;
        $inlast = 'U' if int($inlast) == -1;
        $outlast = 'U' if int($outlast) == -1;
        RRDs::update("$rrd", "$time:$inlast:$outlast");



Irwin Tillman
OIT Network Systems, Princeton University




On 04 Feb 2002, I wrote:

>Platform: mrtg 2.9.17 with rrdtool 1.0.33
>
>For targets that use the Multi Targets syntax, e.g. 
>
>   Target[test.pps]: ifInUcastPkts.1&ifOutUcastPkts.1:public at router + ifInNUcastPkts.1&ifOutNUcastPkts.1:public at router
>
>if one (or more) of the SNMP GETs fails (e.g. device is offline), instead of recording UNKNOWN for 
>the resulting value in the RRD database, zero is recorded for the value.   (I've *not* specified 
>the 'unknaszero' option.)
>
>I didn't find anything about this in the mailing list archive.
>I've looked through the code, trying to locate where the values comprising a multi target 
>are combined, but I've not been able to locate that piece of code.  (I expected to find that 
>I'd simply need to add a special case, to say that if any of these component values is UNKNOWN, 
>then the resulting value should also be UNKNOWN.)  Can anyone point me to where in the code
>this is handled?  (Or provide a fix.)
>
>This behavior causes a problem, of course, because for a COUNTER it makes it look like
>a counter wrap has occurred.  (It produces a  spike in the AVERAGE values when we lose
>communication with the device, and again when we recover communication.)



--
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
Archive     http://www.ee.ethz.ch/~slist/mrtg
FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi