[Xymon] Extra lines for non-existent data

[Jeremy Laidman]

Thanks Wim

I updated GRAPHS and appended "::1" to my test name as you suggested. But
the trends page still tries to show multiple graphs instead of one.

It's weird how the exact same graph definition attempts to display one too
many graphs for one server, and two too many graphs for another. It's a
mystery how svcstatus.cgi determines how many graphs to show.

I don't know how I could use the "linecount" hack for the trends page. I
should have mentioned that this is where the problem is.

This seems to be a problem that goes back a long time, and hasn't been
implemented in the best way, as suggested by comments in
generate_html_log():

* What we *really* should do was to scan the RRD directory and count how
many
* RRD database files are present matching this service - but that is way too
* much overhead for something that might be called on every status logged.

This makes sense. However, I wonder if the filesystem lookups required for
this would be cached by a modern filesystem, minimising the performance
impact and I/O penalty.

Nevertheless, in absence of reliable heuristics for guessing the number of
graphs required, it would be really valuable to be able to override the
guess in cases where the operator knows the correct answer. If I had
sufficient coding chops, I'd have a crack at adding a feature like this.
Perhaps another modifier like "::=n" to set the number to "n".

J

On 24 March 2017 at 21:24, Nelis, Wim <Wim.Nelis at nlr.nl> wrote:

> Hello Jeremy,
>
>
>
> perhaps you can use the “<!—linecount=N -->” line in the status message to
> xymon, which states that there are N graphs to be shown. This can be handy
> if multiple RRD’s are to be combined in a single graph.
>
> (I’ve patched Devmon to include this linecount-directive in front of the
> RRD table. This improves the output of Xymon, but does not solve all
> probems.)
>
>
>
> And again perhaps, the optional parameter  in the definition of a test in
> environmental variable GRAPHS might help. Definition  “test::M” specifies
> that at most M RRD’s may be combined into a single graph. What happens if
> you set M to one?
>
>
>
> Regards,
>
>   Wim Nelis.
>
>
>
> *From:* Xymon [mailto:xymon-bounces at xymon.com] *On Behalf Of *Jeremy
> Laidman
> *Sent:* 23 March 2017 15:46
> *To:* xymon at xymon.com
> *Subject:* [Xymon] Extra lines for non-existent data
>
>
>
> Hi
>
>
>
> I'm sure this has been discussed previously, but I don't know if there was
> a fix or a work-around.
>
>
>
> I have a few graphs that Xymon wants to show over multiple graphs. In the
> example below, this is happening for two different graph definitions.The
> second of each graph has no data, and so the graphs are broken.
>
>
>
> [image: Inline images 1]
>
>
>
> In the first of the two graphs (in each case) the URL for the graph image
> contains "first=1&count=5". The second, broken, graph image URL contains
> "first=6&count=5". Each of these graph definitions, in graphs.cfg, uses one
> RRD file per DEF, where each RRD file has only one data series (named
> "lambda").
>
>
>
> I seem to recall that when xymongen is constructing the URLs for the
> images, it has to make a guess about how many to include, based on how many
> lines it things there might be, and that guess is not always accurate. Is
> there a way to provide hints to xymongen about the number of lines in a
> graph? I also seem to recall that Devmon managed to work around this
> problem, but I don't know how, or if the same technique can be applied
> outside of Devmon.
>
>
>
> J
>
>
>
> ------------------------------
>
>
>
> ------------------------------
> *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.
> ------------------------------
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20170327/2328a1b3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 80960 bytes
Desc: not available
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20170327/2328a1b3/attachment.png>