Broken custom graphs on trends page
Did you ever get any response on this broken graph issue? I'm seeing the same thing now.
I have a system with 11 file systems. Multi-graph shows them in sets of 3, except for the last 2, which don't show at all. When I view the page source, I can see that the link says first=10&count=3. I figure that must be breaking the graph generator because there are only 2 more graphs to show.
This is stock 4.3.7, btw. I'll dig into the code later and see if I can see why the math miscounts.
Ralph Mitchell On Mar 15, 2012 11:14 PM, "Jeremy Laidman" <jlaidman at rebel-it.com.au> wrote:
Xymonsters
I'm looking for a way forward on the "broken multiple graphs" problem that I'm experiencing. Excuse the long post; it's part brainstorming, and part context-setting.
For a while there have been some discussion on the list about how custom graphs can get displayed incorrectly as if they're multi-graph when they're not. (I think I'm using the correct term "multi-graph" here.) Xymon works out that there are enough RRD files to fill more than one graph, and shows several graphs, each with a different "first" parameter. For me, in many cases all of the lines fit on one graph, and so the other graphs show as a broken image icon.
A work-around seems to be to explicitly show "<!-- linecount=N>" to define how many lines should be expected on a set of graphs. I've done this in my devmon templates to prevent the broken graphs.
However, this work-around is only available for custom graphs that create their own status webpage using HTML (in which the "<!-- linecount=N>" tag can be included) and send them to Xymon using a "status" message.
I have some collectors that send their data to Xymon using "data" messages, because I don't want to grow my Xymon display too wide, with a bunch of dots that can only ever be green. So my graphs show up in the trends column, which is exactly where I want them. But because I can't add a "linecount" anywhere, I get broken graphs.
I really don't think I'm doing anything out of the ordinary here, and certainly not deviating from the documentation. I've scoured doco, mailing list, and even code to find out what can be done to work around this problem. Finally, I've come to the conclusion that the Xymon code is simply unable to work out how many graphs to show in all situations, and its heuristics are not working sometimes. This is the only bit of my Xymon installation that is tarnishing its reputation here, meaning that it doesn't compare favourably with other products, so I'd really like to get this fixed somehow. But I'm not sure what to do about it. If I'm simply doing something wrong, then please let me know, and ignore the rest of this post.
So, what am I asking for? There might be a way to get Xymon to work out the graph linecount more universally, perhaps at the expense of more code complexity, compatibility, CPU cycles or disk I/O (I think the some code comments describe an intent to avoid scanning the directory). But even so, I think what I'd like to have is a way of overriding the heuristics other than the "linecount" hack. But what's the best way to do this? I'm willing to cut code to get this fixed, but my effort should be inline with the future of Xymon, as well as having maximal usefulness to others. It also needs to not break the existing heuristics used for the standard graphs (disk, inode, if_load, etc).
One idea is that I could add a "LINECOUNT" keyword into the graphs.cfg file, something like this:
[bindstats] TITLE DNS Queries and Responses YAXIS per second LINECOUNT 6 ...
This would help with both data and status messages that are falling victim to this problem.
It also occurs to me that the multi-graph code doesn't seem (to me) to make sense for graph definitions that don't have @RRDIDX@ type indexed filename lookups. So perhaps the simplest thing would be to assume linecount is zero if FNPATTERN is not specified in the corresponding graph definition.
Other ideas?
Cheers Jeremy
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Here's a twist - I just tried it at home on a Gentoo system and xymon-4.3.7 is happily doing all the graphs for 11 filesystems, distributed as 3 + 3 + 3 + 2. When I mouse-over the 2 disk graph, the url shows "start=10&count=3", so maybe it's a problem with rrdtool? I know there are other things in between that url and actually getting the graph, but if rrdtool is told to graph 3 data sources and is only given 2, it could just be choking.
I don't know what version I have in SLES11 at work, but at home it's rrdtool-1.4.5-r1. Maybe this version handles it more gracefully if there's a data source missing.
Ralph Mitchell
On Thu, Apr 26, 2012 at 7:46 PM, Ralph Mitchell <ralphmitchell at gmail.com> wrote:
Did you ever get any response on this broken graph issue? I'm seeing the same thing now.
I have a system with 11 file systems. Multi-graph shows them in sets of 3, except for the last 2, which don't show at all. When I view the page source, I can see that the link says first=10&count=3. I figure that must be breaking the graph generator because there are only 2 more graphs to show.
This is stock 4.3.7, btw. I'll dig into the code later and see if I can see why the math miscounts.
Ralph Mitchell
On Mar 15, 2012 11:14 PM, "Jeremy Laidman" <jlaidman at rebel-it.com.au> wrote:
Xymonsters
I'm looking for a way forward on the "broken multiple graphs" problem that I'm experiencing. Excuse the long post; it's part brainstorming, and part context-setting.
For a while there have been some discussion on the list about how custom graphs can get displayed incorrectly as if they're multi-graph when they're not. (I think I'm using the correct term "multi-graph" here.) Xymon works out that there are enough RRD files to fill more than one graph, and shows several graphs, each with a different "first" parameter. For me, in many cases all of the lines fit on one graph, and so the other graphs show as a broken image icon.
A work-around seems to be to explicitly show "<!-- linecount=N>" to define how many lines should be expected on a set of graphs. I've done this in my devmon templates to prevent the broken graphs.
However, this work-around is only available for custom graphs that create their own status webpage using HTML (in which the "<!-- linecount=N>" tag can be included) and send them to Xymon using a "status" message.
I have some collectors that send their data to Xymon using "data" messages, because I don't want to grow my Xymon display too wide, with a bunch of dots that can only ever be green. So my graphs show up in the trends column, which is exactly where I want them. But because I can't add a "linecount" anywhere, I get broken graphs.
I really don't think I'm doing anything out of the ordinary here, and certainly not deviating from the documentation. I've scoured doco, mailing list, and even code to find out what can be done to work around this problem. Finally, I've come to the conclusion that the Xymon code is simply unable to work out how many graphs to show in all situations, and its heuristics are not working sometimes. This is the only bit of my Xymon installation that is tarnishing its reputation here, meaning that it doesn't compare favourably with other products, so I'd really like to get this fixed somehow. But I'm not sure what to do about it. If I'm simply doing something wrong, then please let me know, and ignore the rest of this post.
So, what am I asking for? There might be a way to get Xymon to work out the graph linecount more universally, perhaps at the expense of more code complexity, compatibility, CPU cycles or disk I/O (I think the some code comments describe an intent to avoid scanning the directory). But even so, I think what I'd like to have is a way of overriding the heuristics other than the "linecount" hack. But what's the best way to do this? I'm willing to cut code to get this fixed, but my effort should be inline with the future of Xymon, as well as having maximal usefulness to others. It also needs to not break the existing heuristics used for the standard graphs (disk, inode, if_load, etc).
One idea is that I could add a "LINECOUNT" keyword into the graphs.cfg file, something like this:
[bindstats] TITLE DNS Queries and Responses YAXIS per second LINECOUNT 6 ...
This would help with both data and status messages that are falling victim to this problem.
It also occurs to me that the multi-graph code doesn't seem (to me) to make sense for graph definitions that don't have @RRDIDX@ type indexed filename lookups. So perhaps the simplest thing would be to assume linecount is zero if FNPATTERN is not specified in the corresponding graph definition.
Other ideas?
Cheers Jeremy
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
I had no response on this. What you've reported is Interesting. I run RRDtool v1.2.12. I might be able to upgrade RRDtool on a test server to see if it makes a difference, but not for a few days at least.
I'm a little skeptical of the theory that rrdtool could be the difference, but only because I believe Xymon is generating the URL with the "start" and "count" parameters, and doesn't seem to consult rrdtool for any start/count values or similar. Furthermore, there doesn't seem to be a way to query rrdtool for these values. But this is conjecture, as it's been a while since I reviewed the code.
J
On Sun, Apr 29, 2012 at 4:02 AM, Ralph Mitchell <ralphmitchell at gmail.com>wrote:
Here's a twist - I just tried it at home on a Gentoo system and xymon-4.3.7 is happily doing all the graphs for 11 filesystems, distributed as 3 + 3 + 3 + 2. When I mouse-over the 2 disk graph, the url shows "start=10&count=3", so maybe it's a problem with rrdtool? I know there are other things in between that url and actually getting the graph, but if rrdtool is told to graph 3 data sources and is only given 2, it could just be choking.
I don't know what version I have in SLES11 at work, but at home it's rrdtool-1.4.5-r1. Maybe this version handles it more gracefully if there's a data source missing.
Ralph Mitchell
On Thu, Apr 26, 2012 at 7:46 PM, Ralph Mitchell <ralphmitchell at gmail.com> wrote:
Did you ever get any response on this broken graph issue? I'm seeing the same thing now.
I have a system with 11 file systems. Multi-graph shows them in sets of 3, except for the last 2, which don't show at all. When I view the page source, I can see that the link says first=10&count=3. I figure that must be breaking the graph generator because there are only 2 more graphs to show.
This is stock 4.3.7, btw. I'll dig into the code later and see if I can see why the math miscounts.
Ralph Mitchell
On Mar 15, 2012 11:14 PM, "Jeremy Laidman" <jlaidman at rebel-it.com.au> wrote:
Xymonsters
I'm looking for a way forward on the "broken multiple graphs" problem that I'm experiencing. Excuse the long post; it's part brainstorming, and part context-setting.
For a while there have been some discussion on the list about how custom graphs can get displayed incorrectly as if they're multi-graph when they're not. (I think I'm using the correct term "multi-graph" here.) Xymon works out that there are enough RRD files to fill more than one graph, and shows several graphs, each with a different "first" parameter. For me, in many cases all of the lines fit on one graph, and so the other graphs show as a broken image icon.
A work-around seems to be to explicitly show "<!-- linecount=N>" to define how many lines should be expected on a set of graphs. I've done this in my devmon templates to prevent the broken graphs.
However, this work-around is only available for custom graphs that create their own status webpage using HTML (in which the "<!-- linecount=N>" tag can be included) and send them to Xymon using a "status" message.
I have some collectors that send their data to Xymon using "data" messages, because I don't want to grow my Xymon display too wide, with a bunch of dots that can only ever be green. So my graphs show up in the trends column, which is exactly where I want them. But because I can't add a "linecount" anywhere, I get broken graphs.
I really don't think I'm doing anything out of the ordinary here, and certainly not deviating from the documentation. I've scoured doco, mailing list, and even code to find out what can be done to work around this problem. Finally, I've come to the conclusion that the Xymon code is simply unable to work out how many graphs to show in all situations, and its heuristics are not working sometimes. This is the only bit of my Xymon installation that is tarnishing its reputation here, meaning that it doesn't compare favourably with other products, so I'd really like to get this fixed somehow. But I'm not sure what to do about it. If I'm simply doing something wrong, then please let me know, and ignore the rest of this post.
So, what am I asking for? There might be a way to get Xymon to work out the graph linecount more universally, perhaps at the expense of more code complexity, compatibility, CPU cycles or disk I/O (I think the some code comments describe an intent to avoid scanning the directory). But even so, I think what I'd like to have is a way of overriding the heuristics other than the "linecount" hack. But what's the best way to do this? I'm willing to cut code to get this fixed, but my effort should be inline with the future of Xymon, as well as having maximal usefulness to others. It also needs to not break the existing heuristics used for the standard graphs (disk, inode, if_load, etc).
One idea is that I could add a "LINECOUNT" keyword into the graphs.cfg file, something like this:
[bindstats] TITLE DNS Queries and Responses YAXIS per second LINECOUNT 6 ...
This would help with both data and status messages that are falling victim to this problem.
It also occurs to me that the multi-graph code doesn't seem (to me) to make sense for graph definitions that don't have @RRDIDX@ type indexed filename lookups. So perhaps the simplest thing would be to assume linecount is zero if FNPATTERN is not specified in the corresponding graph definition.
Other ideas?
Cheers Jeremy
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
I don't think xymon needs to consult rrdtool for the start and count - all it needs do is open the $HOME/data/rrd/server.domain.com directory and count on its fingers how many disk*.rrd entries there are, then determine how to distribute them evenly.
I just compiled up xymon-4.3.7 in CentOS-6.2, with rrdtool-1.3.8 and with 11 filesystems I see 4 graphs, with only two lines on the 4th graph. All graph urls have count=3.
I'll let you know later what version of rrdtool is on my SLES server at work, and if it's less than 1.3.8 I'll upgrade it and see what happens.
Ralph Mitchell
On Mon, Apr 30, 2012 at 12:04 AM, Jeremy Laidman <jlaidman at rebel-it.com.au> wrote:
I had no response on this. What you've reported is Interesting. I run RRDtool v1.2.12. I might be able to upgrade RRDtool on a test server to see if it makes a difference, but not for a few days at least.
I'm a little skeptical of the theory that rrdtool could be the difference, but only because I believe Xymon is generating the URL with the "start" and "count" parameters, and doesn't seem to consult rrdtool for any start/count values or similar. Furthermore, there doesn't seem to be a way to query rrdtool for these values. But this is conjecture, as it's been a while since I reviewed the code.
J
On Sun, Apr 29, 2012 at 4:02 AM, Ralph Mitchell <ralphmitchell at gmail.com> wrote:
Here's a twist - I just tried it at home on a Gentoo system and xymon-4.3.7 is happily doing all the graphs for 11 filesystems, distributed as 3 + 3 + 3 + 2. When I mouse-over the 2 disk graph, the url shows "start=10&count=3", so maybe it's a problem with rrdtool? I know there are other things in between that url and actually getting the graph, but if rrdtool is told to graph 3 data sources and is only given 2, it could just be choking.
I don't know what version I have in SLES11 at work, but at home it's rrdtool-1.4.5-r1. Maybe this version handles it more gracefully if there's a data source missing.
Ralph Mitchell
On Thu, Apr 26, 2012 at 7:46 PM, Ralph Mitchell <ralphmitchell at gmail.com> wrote:
Did you ever get any response on this broken graph issue? I'm seeing the same thing now.
I have a system with 11 file systems. Multi-graph shows them in sets of 3, except for the last 2, which don't show at all. When I view the page source, I can see that the link says first=10&count=3. I figure that must be breaking the graph generator because there are only 2 more graphs to show.
This is stock 4.3.7, btw. I'll dig into the code later and see if I can see why the math miscounts.
Ralph Mitchell
On Mar 15, 2012 11:14 PM, "Jeremy Laidman" <jlaidman at rebel-it.com.au> wrote:
Xymonsters
I'm looking for a way forward on the "broken multiple graphs" problem that I'm experiencing. Excuse the long post; it's part brainstorming, and part context-setting.
For a while there have been some discussion on the list about how custom graphs can get displayed incorrectly as if they're multi-graph when they're not. (I think I'm using the correct term "multi-graph" here.) Xymon works out that there are enough RRD files to fill more than one graph, and shows several graphs, each with a different "first" parameter. For me, in many cases all of the lines fit on one graph, and so the other graphs show as a broken image icon.
A work-around seems to be to explicitly show "<!-- linecount=N>" to define how many lines should be expected on a set of graphs. I've done this in my devmon templates to prevent the broken graphs.
However, this work-around is only available for custom graphs that create their own status webpage using HTML (in which the "<!-- linecount=N>" tag can be included) and send them to Xymon using a "status" message.
I have some collectors that send their data to Xymon using "data" messages, because I don't want to grow my Xymon display too wide, with a bunch of dots that can only ever be green. So my graphs show up in the trends column, which is exactly where I want them. But because I can't add a "linecount" anywhere, I get broken graphs.
I really don't think I'm doing anything out of the ordinary here, and certainly not deviating from the documentation. I've scoured doco, mailing list, and even code to find out what can be done to work around this problem. Finally, I've come to the conclusion that the Xymon code is simply unable to work out how many graphs to show in all situations, and its heuristics are not working sometimes. This is the only bit of my Xymon installation that is tarnishing its reputation here, meaning that it doesn't compare favourably with other products, so I'd really like to get this fixed somehow. But I'm not sure what to do about it. If I'm simply doing something wrong, then please let me know, and ignore the rest of this post.
So, what am I asking for? There might be a way to get Xymon to work out the graph linecount more universally, perhaps at the expense of more code complexity, compatibility, CPU cycles or disk I/O (I think the some code comments describe an intent to avoid scanning the directory). But even so, I think what I'd like to have is a way of overriding the heuristics other than the "linecount" hack. But what's the best way to do this? I'm willing to cut code to get this fixed, but my effort should be inline with the future of Xymon, as well as having maximal usefulness to others. It also needs to not break the existing heuristics used for the standard graphs (disk, inode, if_load, etc).
One idea is that I could add a "LINECOUNT" keyword into the graphs.cfg file, something like this:
[bindstats] TITLE DNS Queries and Responses YAXIS per second LINECOUNT 6 ...
This would help with both data and status messages that are falling victim to this problem.
It also occurs to me that the multi-graph code doesn't seem (to me) to make sense for graph definitions that don't have @RRDIDX@ type indexed filename lookups. So perhaps the simplest thing would be to assume linecount is zero if FNPATTERN is not specified in the corresponding graph definition.
Other ideas?
Cheers Jeremy
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
participants (2)
-
jlaidman＠rebel-it.com.au
-
ralphmitchell＠gmail.com