Cacti (home)ForumsDocumentation
Cacti: offical forums and support
It is currently Mon Jul 24, 2017 5:48 am

All times are UTC - 5 hours




Post new topic Reply to topic  [ 19 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: THold current values still a mystery
PostPosted: Tue Feb 03, 2009 6:45 am 
Offline

Joined: Tue Feb 03, 2009 6:11 am
Posts: 19
Hi,

I am trying to set a 900Mbps threshold on traffic in and traffic out graphs. I don't understand the threshold current numbers. They are in orders of magnitude higher than the data I am seeing.

For example on a graph with an inbound current value of 10.45Mbps I get a current value reported by threshold of 696753306271.18.

Even if this is in bits, it is still massively too large:
696753306271.18 / 1000 / 1000 = 696753Mbps??

If its in bytes then its way off:
696753306271.18 / 8 / 1000 / 1000 = 87094Mbps??

I am using 64-bit counters, does this cause a problem? What is the correct math for converting this current value into Mbps?

Cheers,
Ben


Top
 Profile  
 
 Post subject:
PostPosted: Tue Feb 03, 2009 5:33 pm 
Offline
Developer

Joined: Thu Apr 07, 2005 3:29 pm
Posts: 2587
Location: B/CS Texas
I will have to look into the 64 bit counters to see if they are causing the issues.

_________________
CactiEZ CD


Top
 Profile  
 
 Post subject: Same issue I have
PostPosted: Tue Feb 10, 2009 11:42 am 
Offline

Joined: Mon Jun 18, 2007 10:36 am
Posts: 1
I was hoping to see an answer here as I am seeing the same thing?


Top
 Profile  
 
 Post subject:
PostPosted: Wed Feb 11, 2009 4:16 pm 
Offline

Joined: Wed Oct 24, 2007 5:43 pm
Posts: 21
Me too, I don't understand thold's 'current value' for traffic at all.

I have a device with one datasource, monitoring traffic. When I first added it the number was huge, orders of magnitude higher than the current traffic. Then within one poll it refreshed itself to be within the order of magnitude, but no number that made sense given the current traffic value given on the graph.

Then one more refresh down, and it is an absurdly low number. I just don't understand it at all. I will add thresholds for a few more cable modems here and post their results on each poll, maybe that will be helpful.

I am not (as far as I know) using 64 bit counters.
The graphs are correct.


Top
 Profile  
 
 Post subject: Details
PostPosted: Wed Feb 11, 2009 4:51 pm 
Offline

Joined: Wed Oct 24, 2007 5:43 pm
Posts: 21
Ok, I have some details.

I have attached the traffic graph for the data I am about to give. I picked a cable modem that isn't really in use much right now so there is just a solid downstream of about 17-19 kilobits per second. The graph type is interface traffic bits/sec.

On the first poll the "Current value" is: 8888.7067
On the second poll the "Current value" is: 3.7267
On the third poll the "Current value" is: 63.9967

I am not sure why the first one is always so high, but maybe it needs 2 numbers to start taking a reading. By the second reading it is already far too low for any number I can try to reconcile with the 'current' number displayed on the graph. Or any other number on there. Then the third up again (with no changes really in the target graph). A very very minor bump perhaps. (You can see this on my attached graph)

Could it be indicating the change in bits/sec or bytes/sec since the last reading? This would almost make sense (tiny bump) but the thing is barely in use so the lines are fairly solid.

No CDEFs were applied to the threshold.

Any ideas anyone ?

EDIT: I'm seeing in the php some references to the current value and looking how it is calculated:

$currentval = $item[$t_item['name']] - $t_item['oldvalue']; Or other ways depending on the type. Could it be using the wrong calculation for a bandwidth type?


Attachments:
trafficgraph.png
trafficgraph.png [ 34.23 KiB | Viewed 13881 times ]
Top
 Profile  
 
 Post subject:
PostPosted: Thu Feb 12, 2009 2:11 pm 
Offline

Joined: Wed Oct 24, 2007 5:43 pm
Posts: 21
Like here, does this make sense to anyone ?
Image

Current_value and the graph are very clearly at odds. Almost 10mbit for the graph and 633128 for the current value. How could it get it so wrong?


Top
 Profile  
 
 Post subject:
PostPosted: Wed Mar 18, 2009 10:28 am 
Offline

Joined: Sat Jan 12, 2008 7:30 pm
Posts: 23
I suppose this won't help anyone as such, but can I say "me too". From what I've noticed it seems to be off by a factor of (about) 10. In a moment of madness I thought that the solution was just to set a CDEF to multiply by 1024, but then my brain flickered again (happens sometimes) and I realised I was clearly stupid!

This is on latest 4.1 thold with 0.8.7d Cacti; 32 bit counters on a "with 95th" graph template.


Top
 Profile  
 
 Post subject: Any resolution?
PostPosted: Wed Mar 18, 2009 7:23 pm 
Offline

Joined: Wed Mar 18, 2009 6:02 pm
Posts: 4
I've been seeing this issue as well (order of magnitude) and I've also noticed the large discrepancy in the first poll vs the next one.

Are there further discussions around this?

Using CactiEZ Version 0.8.7c

Thresholds
Directory: thold
Version: 0.4
Author: Jimmy Conner
Home Page: http://cactiusers.org
Status: Active

Thanks!


Top
 Profile  
 
 Post subject:
PostPosted: Wed Mar 18, 2009 7:38 pm 
Offline
Developer
User avatar

Joined: Tue May 14, 2002 5:08 pm
Posts: 14863
Location: MI, USA
Jimmy migrated to using the poller_output table instead of using the RRDfiles directly in a recent version. However, there are issues with that. First, there is no baseline on the first poll. That's ok, we can deal with that. Second, the counters can be increasing (heading for a positive overflow), or descending (heading for an underflow). We have to detect if they are increasing or decreasing and then based upon the poller interval, come up with a rate, etc.

This behavior chanbes if it's a COUNTER vs. a GUAGE, and I don't even want to think of how we would handle DERIVE, COMPUTE, etc. I guess, IMHO, some will not be well supported.

As I have not analyzed the code, I will copy Jimmy. It may be a simple bug...

TheWitness

_________________
True understanding begins only when we realize how little we truly understand...

Life is an adventure, let yours begin with Cacti!

Author of MacTrack, Boost, CLog, SpikeKill, Platform RTM, DSStats, maintainer of Spine, lot's of unpublished work and most of Cacti's bugs.
_________________
Official Cacti Documentation
Gandalfs Official Debugging Help
Central Plugin Repository
Central Templates Repository


Top
 Profile  
 
 Post subject:
PostPosted: Sun Mar 29, 2009 2:02 pm 
Offline
Cacti User

Joined: Tue May 02, 2006 3:00 pm
Posts: 59
Hi guys,

Any luck with this? I am having the same exact problem. It worked perfectly on our old 0.39 version of Thold, but now we get these out of whack numbers. I'll attach a zip that contains my bytes to mbps CDEF, the Thold Current numbers and the actual Mbps usage after the CDEF is applied in the Data source which is correct.


Attachments:
thold.zip [82.11 KiB]
Downloaded 403 times
Top
 Profile  
 
 Post subject: Re: THold current values still a mystery
PostPosted: Tue Apr 21, 2009 4:15 am 
Offline

Joined: Wed May 21, 2008 8:50 pm
Posts: 11
bl243 wrote:
Hi,

I am trying to set a 900Mbps threshold on traffic in and traffic out graphs. I don't understand the threshold current numbers. They are in orders of magnitude higher than the data I am seeing.

For example on a graph with an inbound current value of 10.45Mbps I get a current value reported by threshold of 696753306271.18.

Even if this is in bits, it is still massively too large:
696753306271.18 / 1000 / 1000 = 696753Mbps??

If its in bytes then its way off:
696753306271.18 / 8 / 1000 / 1000 = 87094Mbps??

I am using 64-bit counters, does this cause a problem? What is the correct math for converting this current value into Mbps?

Cheers,
Ben


I just installed Thold 0.4.1 (cacti 0.8.7d) and using 64bit counters for those graphs above 100M.
When creating the threshold.
1. Under 'Data Manipulation'
2. Set 'Data Type' to 'CDEF'
3. Set 'Threshold CDEF' to 'Turn Bytes to Bits'
4. Configure whatever else you want and save.

The initial polled value will be whacked high but the second one onwards will be normalised. I assume this is a calculation issue when calculating values from SNMP.

See below works fine.

Code:
450000000     50000000     5 Minutes         Every 15 Minutes     341581965.8933     no


Top
 Profile  
 
 Post subject: Re: THold current values still a mystery
PostPosted: Tue Feb 26, 2013 7:47 pm 
Offline

Joined: Tue Feb 26, 2013 7:08 pm
Posts: 7
Please, someone help me with the attached problem.

Thank you!


Attachments:
debug.png
debug.png [ 129.55 KiB | Viewed 8729 times ]
Top
 Profile  
 
 Post subject: Re: THold current values still a mystery
PostPosted: Fri Feb 07, 2014 11:04 am 
Offline

Joined: Fri Feb 07, 2014 10:38 am
Posts: 2
I know this is an old thread, but there is no answer that I could find, so here is my posting of a possible fix.

I was experiencing this same problem when trying to use cdef. The current reported "correctly" but the last was negative.

I'm no coder, but i did figure out that in the poller.php, line 101 calls for the calculation of current value, referencing "thold_get_currentval" in thold_functions.php, that result was a giant negative number which then gets passed into the switch below and messes up my cdef, resulting in the messed up "last" value.


The following is what I did to fix the problem when it relates to using cdef.

on line 101 in the /include/poller.php file,

Code:
Find:
      $currentval = thold_get_currentval($t_item, $rrd_reindexed, $rrd_time_reindexed, $item, $currenttime);

Code:
Replace with:
      $currentval = get_current_value($t_item['rra_id'], $t_item['data_id'], $cdef = 0);


This resulted in passing the correct "current value" into the cdef function which for me resulted in the proper Percentage of the link that i wanted.

Again, I'm no coder, but I was able to follow the trails which led me to use the same function that is referenced for the "current" display and then figured out which values to pass into it and it worked for me. I don't recommend just apply this to a production system without first testing in a lab of your own.

Here is a picture showing it working on a 10g interface.
Attachment:
cdef cacti fix proof.png
cdef cacti fix proof.png [ 14.08 KiB | Viewed 7264 times ]


Top
 Profile  
 
 Post subject: Re: THold current values still a mystery
PostPosted: Thu Sep 17, 2015 5:00 pm 
Offline

Joined: Wed Sep 09, 2015 10:47 am
Posts: 2
syscev wrote:
bl243 wrote:
Hi,

I am trying to set a 900Mbps threshold on traffic in and traffic out graphs. I don't understand the threshold current numbers. They are in orders of magnitude higher than the data I am seeing.

For example on a graph with an inbound current value of 10.45Mbps I get a current value reported by threshold of 696753306271.18.

Even if this is in bits, it is still massively too large:
696753306271.18 / 1000 / 1000 = 696753Mbps??

If its in bytes then its way off:
696753306271.18 / 8 / 1000 / 1000 = 87094Mbps??

I am using 64-bit counters, does this cause a problem? What is the correct math for converting this current value into Mbps?

Cheers,
Ben


I just installed Thold 0.4.1 (cacti 0.8.7d) and using 64bit counters for those graphs above 100M.
When creating the threshold.
1. Under 'Data Manipulation'
2. Set 'Data Type' to 'CDEF'
3. Set 'Threshold CDEF' to 'Turn Bytes to Bits'
4. Configure whatever else you want and save.

The initial polled value will be whacked high but the second one onwards will be normalised. I assume this is a calculation issue when calculating values from SNMP.

See below works fine.

Code:
450000000     50000000     5 Minutes         Every 15 Minutes     341581965.8933     no


I know this is an old post, but being new to cacti, it just saved my bacon! Thanks!!!!


Top
 Profile  
 
 Post subject: Re: THold current values still a mystery
PostPosted: Wed Sep 21, 2016 2:00 pm 
Offline

Joined: Wed Sep 21, 2016 1:46 pm
Posts: 1
SilverSquirrl wrote:

Code:
Find:
      $currentval = thold_get_currentval($t_item, $rrd_reindexed, $rrd_time_reindexed, $item, $currenttime);

Code:
Replace with:
      $currentval = get_current_value($t_item['rra_id'], $t_item['data_id'], $cdef = 0);




So this change in code works for (traffic in), but traffic out reports "current" correctly, however, it is utilizing the (traffic in) data,.. see screen shot:


Attachments:
cacti thold1.png
cacti thold1.png [ 11.57 KiB | Viewed 2643 times ]
Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 19 posts ]  Go to page 1, 2  Next

All times are UTC - 5 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  

Protected by Anti-Spam ACP Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group