Xymon Mailing List Archive search

"acceptonly" behavior

list Jeremy Laidman
Tue, 17 Nov 2015 15:39:57 +1100
Message-Id: <user-dfd6eea57ba2@xymon.invalid>

This seems like a really neat idea.  I think it would be useful to have
rejected updates show up in the same way as ghosts in the ghost report.
And/or the host's "info" page.

I wonder if the matching syntax can support exclusion as well as inclusion,
so we might say "accepttests=*:!cpu,!disk" to accept all but not CPU and
disk.  Alternatively, two keywords (such as "acceptonly=" and
"acceptnot="), perhaps mutually exclusive or "last one wins", would be
sufficient.


On 7 November 2015 at 05:19, John Thurston <user-ce4d79d99bab@xymon.invalid> wrote:
The "acceptonly" concept has been discussed briefly here, and was tried
out in 4.3.22-RC3. It's behavior wasn't as expected and it was removed
again. If this tag is going to make its way back in, I think we should have
a little discussion of how we'd like it to behave. Since I originally
brought the subject up, I figure it's polite if I started this conversation.

What would be most useful to me is a per-host tag which was also accepted
on the .default. host lines. The tag would carry one or more test names.
Any messages for the host for a test not named on this tag would be
discarded as if they had never been received. An event would not be logged
for this message. A case-insensitive string match would meet my needs.

The affected host will be able to send any messages they like, but only
those named in the 'acceptonly' tag will be accepted.

If test results for a newly-excluded host.test combination exist, it will
eventually result in a purple for that host.test, just as if the host had
stopped reporting that test.

If test results for a newly-excluded host.test combination do not exist,
there will never be a record of them in the history and they will not
appear on any report or create any alarms.

How might this tag interact with some other functions; like proxy,
msgcache, or pulldata? Do messages from these sources enter the flow early
enough that tags in hosts.cfg can have the desired effect?

--
   Do things because you should, not just because you can.

John Thurston    XXX-XXX-XXXX
user-ce4d79d99bab@xymon.invalid
Enterprise Technology Services
Department of Administration
State of Alaska