[Xymon] NCV Bug-Fix / Feature Request

[Jeremy Laidman]

Yes, agreed.  This is a good run-down of the problems and a good range of
options to fix the problem.

A few other options to consider:

4. Have a qualifier for each entry in SPLITNCV_*/NCV_* like so:

  SPLITNCV_test="this:GAUGE,that:GAUGE:data"

or

  SPLITNCV_test="*:GAUGE:data,this:DERIVE,that::status"

5. Somehow hook into the "flags" feature of a status message to modify the
NCV parsing behaviour.  This could be to not assume an NCV string unless
prefixed by or embedded in an HTML comment, or to specify an alternative
separator character/string other than the colon (eg "=" or "==").  I've
never really looked into flags, so this might be unnecessary feature abuse
that could break future functionality.

6. Ignore NCV lines where the "V" contains non-numeric characters, that is,
if what follows the number is anything but a newline.  This could break
some existing configurations, so there could be a run-time option for
xymond to re-enable the current behaviour.

If I had to choose how to fix this problem, I would simply have the status
message parser look for NCVs on every line as it does now, but also look
for an <NCV></NCV> pair (for example).  Thus allows the client to determine
how its data needs to be interpreted, which means it isn't a global change
that could break other tests.

I imagine (as I am want) the code would be fairly simple: the parser could
simply discard any NCVs it had found so far, when it saw the <NCV> tag, and
would then stop looking for any NCVs when it saw the closing tag,
potentially starting/stopping again with a new pair of tags.  This is much
the same as Vernon's second option, and what Galen as suggested in the past.

Like Galen, my C skills are insufficient to do anything more than make
suggestions.  But there's already code to parse things like "<!--
linecount", "<!-- [flags:", and "<!--DEVMON" so at least there's something
to start with there.  I think the file do_ncv.c is where the behaviour
would need to be adjusted.

Interestingly, while reviewing do_ncv.c, it seems the parser stops looking
when it sees "@@" on a line by itself.  It could be that we can do achieve
what we want with something like this in the data/status message:

<!-- NCV data here:
val1 : 23.6
val2: -19
-->
@@
Sun Jul 19 08:46:06 WST 2015
Status of this test is: yada yada

The "@@" should stop the date from being parsed.  Somehow, I think the "@@"
line in the middle of the message might cause other problems, such as a
truncated status message.  But it might actually work!


J


On 19 July 2015 at 12:16, Vernon Everett <everett.vernon at gmail.com> wrote:

> Hi all
>
> Not sure if this is a bug or a feature request. Split_NCV is doing exactly
> what it says on the tin, so it's not really a bug.
> But, it makes things not work right, so it looks like a bug.
> Maybe I should call it an annoyance?
>
> Once again, I bashed heads with the amazingly useful Split_NCV  feature of
> taking your data points and converting them to rrds graphs.
> Don't get me wrong, this is probably one of the coolest things in Xymon,
> because you can have an undefined number of data sets, and add more
> dynamically.
> However, it looks at your status output, and anything of that looks like a
> *description:value*
> it sticks into an associated rrd file.
> Including
> *Sun Jul 19 08:46:06 WST 2015*
> Which happens to be the first line of my test status, and is generally
> used as the first line of any test.
>
> So I switched to using status messages for display and data messages for
> graphing, which makes logical sense.
> And it still grabs the date and makes an rrd file of it. Which is wrong,
> and annoying.
>
> My request is that this be fixed. And I can think of a bunch of really
> simple ways to fix it, and bunch of more interesting ways.
> Some of the simpler ones I can think of are
> 1. Include metadata tag in your status. A simple #NoNCV which gets removed
> server-side for display, and the status doesn't get parsed by the NCV
> module. This means only the data messages will get parsed by the NCV
> module. (This will preserve backward compatibility)
> 2. Include metadata tags to indicate where the NCV data starts and stops
> in a status message. A #StartNC and #StopNCV or #NCV #/NCV.
> Of course there's nothing stopping us from using HTML like tags either.
> <NoNCV> or <NCV> and </NCV>
>  pick a format. (Depending on how it's implemented, this might break
> backward compatibility)
> 3. Change/Add a server config tag. Instead of simply Split_NCV, we have
> Split_NCV that works like it does now. And a Split_NCVD tag, that will only
> parse the data messages. (This will preserve backward compatibility)
>
> There are many ways to achieve the result I am looking for, but please, we
> need to fix this. It's been an annoyance for way too long.
>
> Regards
> Vernon
>
>
>
>
> --
> "Accept the challenges so that you can feel the exhilaration of victory"
> - General George Patton
>
> _______________________________________________
> 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/20150720/fd2fd686/attachment.html>