<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 7 November 2015 at 05:19, John Thurston <span dir="ltr"><<a href="mailto:john.thurston@alaska.gov" target="_blank">john.thurston@alaska.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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.<br>
<br>
The affected host will be able to send any messages they like, but only those named in the 'acceptonly' tag will be accepted.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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?<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
   Do things because you should, not just because you can.<br>
<br>
John Thurston    907-465-8591<br>
<a href="mailto:John.Thurston@alaska.gov" target="_blank">John.Thurston@alaska.gov</a><br>
Enterprise Technology Services<br>
Department of Administration<br>
State of Alaska<br>
_______________________________________________<br>
Xymon mailing list<br>
<a href="mailto:Xymon@xymon.com" target="_blank">Xymon@xymon.com</a><br>
<a href="http://lists.xymon.com/mailman/listinfo/xymon" rel="noreferrer" target="_blank">http://lists.xymon.com/mailman/listinfo/xymon</a><br>
</font></span></blockquote></div><br></div>