Xymon Mailing List Archive search

Extra lines for non-existent data

list Jeremy Laidman
Mon, 27 Mar 2017 12:16:24 +1100
Message-Id: <user-ef782504fd84@xymon.invalid>

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 <user-6956df205d63@xymon.invalid> 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.

Attachments (1)