[Xymon] Broken custom graphs on trends page

Mon Apr 30 06:04:18 CEST 2012

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20120430/59cb65ad/attachment.html>