Possible xymon bug - use of RRDPARAM in custom graphs
Hi everyone,
I think I may have identified a possible bug in xymon. I am currently running 4.3.12.
I am attempting to define a custom graph using the RRDPARAM variable to define the graph. The data that is "supplying" the graph is being generated by a custom check and it stores this data over several rrd files with a single value in each file.
They key line in my graph definition is:
DEF:p at RRDIDX@=@RRDFN@:@RRDPARAM@:AVERAGE
What appears to be happening is that the different variables names that represent the different parameters for the graph are different lengths. It seems that what ends up being supplied to rdd on this line in the graph definition contains extra white space added into the @RRDPARAM@ part of the definition line and that these extra whitespaces correspond to the largest variable name length. It seems to me that the internal data structure is getting sized to the largest string length and then not reduced for subsequent smaller strings and it just pads the rest with whitespace. RRD then gets confused as it is looking for a variable named "variable1 ", while the rrd file actually contains a variable called "variable1".
I would love to get the bug fixed as it is preventing some of my graphs working. Happy to also be told there is a better way to do this. I hope this makes sense. Happy to provide more info if required.
Alex
Hello,
I think I may have identified a possible bug in xymon. I am currently running 4.3.12.
I am attempting to define a custom graph using the RRDPARAM variable to define the graph. The data that is "supplying" the graph is being generated by a custom check and it stores this data over several rrd files with a single value in each file.
They key line in my graph definition is:
DEF:p at RRDIDX@=@RRDFN@:@RRDPARAM@:AVERAGE
What appears to be happening is that the different variables names that represent the different parameters for the graph are different lengths. It seems that what ends up being supplied to rdd on this line in the graph definition contains extra white space added into the @RRDPARAM@ part of the definition line and that these extra whitespaces correspond to the largest variable name length. It seems to me that the internal data structure is getting sized to the largest string length and then not reduced for subsequent smaller strings and it just pads the rest with whitespace. RRD then gets confused as it is looking for a variable named "variable1 ", while the rrd file actually contains a variable called "variable1".
I would love to get the bug fixed as it is preventing some of my graphs working. Happy to also be told there is a better way to do this. I hope this makes sense. Happy to provide more info if required.
This is not a bug, it is a feature. When making multi-graphs, and when using @RRDPARAM@ in de GPRINT-statement, the columns will neatly line up.
The graph definition shows that you have a set RRD's, each containing a single DS with the same name as the file. Is it possible to give the DS a fixed name, for instance 'lambda'? If so, you can remove @RRDPARAM@ form the DEF-line.
Regards, Wim Nelis.
The NLR disclaimer is valid for NLR e-mail messages.
This message is only meant for providing information. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of the sender. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. Sender accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.
Hi,
Thanks for that information, it doesn't appear in the documentation anywhere.
It will be a little difficult for me to hardcore it like that as I run the same custom check on different servers and the check sets different variable names based on slightly different configurations on each server. Is there an alternative way of achieving this, could an extra parameter without the whitespace padding be made available?
Alex
On Wednesday, January 8, 2014, W.J.M. Nelis wrote:
Hello,
I think I may have identified a possible bug in xymon. I am currently running 4.3.12.
I am attempting to define a custom graph using the RRDPARAM variable to define the graph. The data that is "supplying" the graph is being generated by a custom check and it stores this data over several rrd files with a single value in each file.
They key line in my graph definition is:
DEF:p at RRDIDX@=@RRDFN@:@RRDPARAM@:AVERAGE
What appears to be happening is that the different variables names that represent the different parameters for the graph are different lengths. It seems that what ends up being supplied to rdd on this line in the graph definition contains extra white space added into the @RRDPARAM@ part of the definition line and that these extra whitespaces correspond to the largest variable name length. It seems to me that the internal data structure is getting sized to the largest string length and then not reduced for subsequent smaller strings and it just pads the rest with whitespace. RRD then gets confused as it is looking for a variable named "variable1 ", while the rrd file actually contains a variable called "variable1".
I would love to get the bug fixed as it is preventing some of my graphs working. Happy to also be told there is a better way to do this. I hope this makes sense. Happy to provide more info if required.
This is not a bug, it is a feature. When making multi-graphs, and when using @RRDPARAM@ in de GPRINT-statement, the columns will neatly line up.
The graph definition shows that you have a set RRD's, each containing a single DS with the same name as the file. Is it possible to give the DS a fixed name, for instance 'lambda'? If so, you can remove @RRDPARAM@ form the DEF-line.
Regards, Wim Nelis.
- The NLR disclaimer is valid for NLR e-mail messages.*
This message is only meant for providing information. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of the sender.
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. Sender accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.
participants (2)
-
ozkrumpet@gmail.com
-
Wim.Nelis@nlr.nl