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