[Xymon] Broken custom graphs on trends page

[Jeremy Laidman]

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