This question comes up fairly often. 

You _cannot_ see exact values in RRD - it stores 'smoothed', interpolated 
values, not the raw data.  

This is ideal and correct when monitoring trends, especially for the reason you 
identify - the collection periods are never exactly 5 min. The smoothing is 
perfect for that purpose. 

CW

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pavleck, Jeremy 
D.
Sent: Monday, May 08, 2006 2:12 PM
To: [email protected]
Subject: [rrd-users] Re: Precise Value Graphing Help Needed

Greetings Kevin,
  Although I can't help you with this issue, we're also using Weblogic and 
would love to see the scripts you've written to automate WLShell. 

 Currently, we're polling those stats via SNMPd, but I'd love to have access to 
more information provided by WLSHell.

 Jeremy

Jeremy Pavleck
Network Engineer  - Systems Management
IT Networks and Infrastructure 
        
Direct Line: 612-977-5881
Toll Free: 1-888-CAPELLA ext. 5881
Fax: 612-977-5053
E-mail: [EMAIL PROTECTED]
        
Capella University
225 South 6th Street, 9th Floor
Minneapolis, MN 55402

www.capella.edu


 

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kevin Elliott
Sent: Monday, May 08, 2006 3:25 PM
To: [email protected]
Subject: [rrd-users] Precise Value Graphing Help Needed

Greetings fellow RRDTool users,

I am writing today in an attempt to diagnose why I am unable to properly 
visualize exact last data (using GAUGE) in my rrdtool based historic tracking 
instead of what appears to be averaging of some sort.

WebLogic JDBC and Thread Pool Counts are the nature of our data. We are 
retrieving this information from production WL servers using WLShell, a 
java-based "shell" to WebLogic. We are creating an instance of our custom 
wlshell script, and using a loop inside to generate data for 5 minute 
intervals. After data is retrieved, the wlshell script calls a perl script that 
uses RRDTool libraries to update the rrd. Since the connection to the 
production servers over our VPN seems to vary in latency all the time, the time 
it takes to retrieve the data we're requesting can change, so the 5 minute 
intervals are more than likely not exact.

My problem is that we're trying to see exact values at any given point in time 
(and atleast for the last 28 hours graph), rather than any sort of averaging. 
It is important to us that we know that around 11:05am, there was a spike of 10 
connections, versus some average that says 6.7. 
We are seeing all sorts of decimals, and not whole integers as expected.

Our perl script contains the code to create the RRD, and we're using something 
like:

if ( ! -f $rrdfilename ) {
        print "WARN: RRD file ($rrdfilename) not present, creating...\n";
        @rrdCreateArgs = ($rrdfilename, "-s", int($rrdInterval * 60));
        if (($rrdHeartBeat = int($rrdInterval * 60) *2) < 600) {
                $rrdHeartBeat = 600;
        }
        foreach $iterator (0 .. $#FIELDS) {
                push @rrdCreateArgs, "DS:" . $FIELDS[$iterator] . 
":$rrdDSType:300:-1:$rrdDSTypeMaxVal";
        }
        push @rrdCreateArgs, "RRA:LAST:0.5:1:800";
        push @rrdCreateArgs, "RRA:LAST:0.5:12:800";
        push @rrdCreateArgs, "RRA:LAST:0.5:264:800";

print "Creating RRDfile \"$rrdfilename\" with create string = |" . 
join('\n',@rrdCreateArgs) . "|\n";

        RRDs::create(@rrdCreateArgs);
        my $error = RRDs::error();
        if ($error) {
                die "ERROR: Cannot create RRDfile \"$rrdfilename\", error = 
$error\n";
        }
}


Our step size is 300. Instead of seeing values of 1 on the rrdgraph, we're 
seeing 0.2, and 0.6, etc. Some values do seem to have a plot of 2,

but only because they are consistently at the value of 2, and don't vary

as often. All datasources are type GAUGE.

Are there any recommendations for plotting unaveraged precise at-the-moment 
data? I just want to plot values at 5 minute intervals that go up and down per 
interval. We seem to have exhausted the documentation, and have search the web 
for similar strategies. I think we're still not grasping the proper way to do 
this.

Sincerest Regards,

Kevin

Kevin Elliott
DHAP Digital, Inc



--
Unsubscribe mailto:[EMAIL PROTECTED]
Help        mailto:[EMAIL PROTECTED]
Archive     http://lists.ee.ethz.ch/rrd-users
WebAdmin    http://lists.ee.ethz.ch/lsg2.cgi

--
Unsubscribe mailto:[EMAIL PROTECTED]
Help        mailto:[EMAIL PROTECTED]
Archive     http://lists.ee.ethz.ch/rrd-users
WebAdmin    http://lists.ee.ethz.ch/lsg2.cgi

--
Unsubscribe mailto:[EMAIL PROTECTED]
Help        mailto:[EMAIL PROTECTED]
Archive     http://lists.ee.ethz.ch/rrd-users
WebAdmin    http://lists.ee.ethz.ch/lsg2.cgi

Reply via email to