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 <john.thurston at alaska.gov> 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 907-465-8591 John.Thurston at alaska.gov Enterprise Technology Services Department of Administration State of Alaska
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon