"acceptonly" behavior
list John Thurston
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
list Jeremy Laidman
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
list John Thurston
▸
On 11/16/2015 7:39 PM, Jeremy Laidman wrote:
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 could go for inclusion on the host's "info" page, but would really dislike it being treated like a "ghost". Having the xymond test column flapping yellow because some unauthorized workstation (a ghost) is sending me messages is bad enough. Having it bounce yellow because a host is sending messages I have specifically excluded would be awful.
▸
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.
I am certainly not _opposed_ to a "!" syntax. For my business need, "acceptonly" with an inclusion list is perfectly adequate. My need is to prevent noise. If I blackball specific tests, the noise can just be moved to a test with a new name. Yes, in some cases it could make the acceptonly tag a little long-winded. But if I can use it on the .default. line, I won't have to type it very often.
▸
--
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
list Jeremy Laidman
On 18 November 2015 at 04:41, John Thurston <user-ce4d79d99bab@xymon.invalid>
▸
wrote:
I could go for inclusion on the host's "info" page, but would really dislike it being treated like a "ghost". Having the xymond test column flapping yellow because some unauthorized workstation (a ghost) is sending me messages is bad enough. Having it bounce yellow because a host is sending messages I have specifically excluded would be awful.
Fair enough. As long as there's some place for a confused sysadmin to look
for reasons why status messages are not showing up. Could be in a log file.
▸
I am certainly not _opposed_ to a "!" syntax. For my business need, "acceptonly" with an inclusion list is perfectly adequate. My need is to prevent noise. If I blackball specific tests, the noise can just be moved to a test with a new name. Yes, in some cases it could make the acceptonly tag a little long-winded. But if I can use it on the .default. line, I won't have to type it very often.
In another discussion, mention was made to the NOPROPRED tag, which has a
useful format that would seem to work well for this also, and obviously the
parsing code already exists. Examples to demonstrate:
0.0.0.0 .default. # ACCEPTONLY:-memory
192.168.0.1 host1.example.com # ACCEPTONLY:+memory,-disk
192.168.0.2 host2.example.com # ACCEPTONLY:cpu,disk,memory
0.0.0.0 .default. # ACCEPTONLY:*
192.168.0.3 host3.example.com # ACCEPTONLY:-disk
Now, a question. Should this matching apply to:
* only messages from the IP address from hosts.cfg?
* to any message not from the Xymon server?
* to any message including from the Xymon server, eg if I exclude "conn"
messages, should they be dropped?
J