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