|
|
| Author |
Message |
ariesgeek
Joined: 27 Nov 2006 Posts: 19
|
Posted: Wed Aug 29, 2007 9:38 am Post subject: [SOLVED] Allow |query_ifSpeed| for upper limit |
|
|
If |query_ifSpeed| is used as the upper limit on a graph, it is not replaced with the appropriate number, rather the following error is given:
| Code: | | CMDPHP: Poller[0] ERROR: SQL Exec Failed "update graph_templates_graph set Upper Limit='|query_ifSpeed|' where local_graph_id=5" |
|
|
| Back to top |
|
 |
rony Developer/Forum Admin
Joined: 17 Nov 2003 Posts: 5469 Location: Wisconsin, USA
|
Posted: Wed Aug 29, 2007 10:39 am Post subject: |
|
|
What happens if the upper limit changes when the device is re-quered?
It's not a simple answer, hence we haven't implemented it yet. |
|
| Back to top |
|
 |
ariesgeek
Joined: 27 Nov 2006 Posts: 19
|
Posted: Wed Aug 29, 2007 10:45 am Post subject: |
|
|
| Aha! I see your point. Thanks for explaining. I just assumed it was an oversight. |
|
| Back to top |
|
 |
rony Developer/Forum Admin
Joined: 17 Nov 2003 Posts: 5469 Location: Wisconsin, USA
|
Posted: Wed Aug 29, 2007 10:49 am Post subject: |
|
|
Btw, I must admit I like the idea...
Just hard to track it, and do you update the data source as well? If so, we need to update the rrdtool file, which currently does not happen. |
|
| Back to top |
|
 |
ariesgeek
Joined: 27 Nov 2006 Posts: 19
|
Posted: Wed Aug 29, 2007 11:21 am Post subject: |
|
|
| rony wrote: | Btw, I must admit I like the idea...
Just hard to track it, and do you update the data source as well? If so, we need to update the rrdtool file, which currently does not happen. |
Ok, since you're interested, let's think about this.
So, we allow |query_ifSpeed| as an upper limit. We add a second option, a checkbox, "Upper Limit Never Changes". If checked, that addresses all the above and we ignore a new upper limit if it changes. There are practical reasons for this.
If that box is unchecked, then we will have a few choices.
1) If the ifSpeed decreases, we may want to consider keeping upper limit where it is for historical graphing purposes. We can give the user this option somewhere in a configuration.
2) If the ifSpeed increases, we can increase the upper limit. Yeah, you'd have to change it in the RRD. It's been a while so I'm not sure if this can be done or not. If not, your workaround is to dump to XML, make changes to the XML file, then pull your XML file into a "new" RRD. I used to have an algorithm to accomplish the above, albeit in perl, but it's long-gone. It's simple enough to do though.
3) Maybe go a step further and note that if the ifSpeed changes X times in Y amount of time (3 changes in 2 months maybe), we just dump the upper limit altogether. Of course, make this user-configurable.
I dunno, I'm just thinking of things off the top of my head at this point. |
|
| Back to top |
|
 |
gandalf Developer
Joined: 02 Dec 2004 Posts: 12604 Location: Muenster, Germany
|
Posted: Mon Feb 04, 2008 10:46 am Post subject: |
|
|
Support for |query_*| variables for upper/lower limit is impleneted in SVN. Targeted release is 088. Awaiting code verification
Reinhard |
|
| Back to top |
|
 |
deu439356
Joined: 13 Aug 2008 Posts: 45
|
Posted: Mon Dec 22, 2008 9:43 am Post subject: |
|
|
gandalf,
| Quote: |
Support for |query_*| variables for upper/lower limit is impleneted in SVN. Targeted release is 088. |
I would like to be able to use the |query_ifSpeed| for my upper limit, do you know when 8.8 will be released? Or do you know of a way to do this in 8.7b?
Thanks! |
|
| Back to top |
|
 |
gandalf Developer
Joined: 02 Dec 2004 Posts: 12604 Location: Muenster, Germany
|
Posted: Fri Jan 02, 2009 7:43 am Post subject: |
|
|
expect 088 in the first half of this year (btw: Happy New Year to all of you!), at least as a beta. If I remember correctly, backporting would be time cinsuming. It is not planned for 087c
Reinhard |
|
| Back to top |
|
 |
|