[Xymon] server-side message pre-processor?

[Japheth Cleaver]

Another interesting thing was that none of the tests went purple... 
since even the "xymond" messages were getting blocked.

Running for a bit it seems to be working okay (with a fix for that); no 
real impact for hosts that don't have anything specified.

Seems useful to run an RC3 with it.

-jc


On 11/3/2015 10:53 PM, Henrik Størner wrote:
> Hi,
>
> I think you are right about my first take not working if the first 
> "strstr" wasn't the right match. Your version looks better.
>
> Maybe John could take it for a spin?
>
> /Henrik
>
> Den 04-11-2015 kl. 01:46 skrev Japheth Cleaver:
>> On 11/3/2015 2:20 PM, Henrik Størner wrote:
>>> Hi,
>>>
>>> Den 03-11-2015 kl. 19:22 skrev Japheth Cleaver:
>>>> On 11/3/2015 9:20 AM, John Thurston wrote:
>>>>> It would be cool if there were a per-host "accept" tag. I could stick
>>>>> it in a .default. line in hosts.cfg, "accept=disk,cpu,conn,http". Any
>>>>> other test reported for the host would be dropped.
>>>
>>>> Is the problem more along the lines of "I don't want to receive test
>>>> 'xyz' on any host", or more "Here's a list of 38 different tests I 
>>>> want
>>>> to reject on 18 / 400 servers". If it's the latter, a hosts.cfg text
>>>> value (before an internal testname record is generated with which to
>>>> assign accept/deny values to) might be the best option, performance
>>>> concerns not withstanding.
>>>
>>> The attached patch against 4.x-master would do something like that - 
>>> an "acceptonly:cpu,disk,conn,http" in hosts.cfg on the relevant 
>>> hosts, and xymond will then match incoming tests against that entry 
>>> and only process those that are permitted.
>>>
>>> For hosts without an acceptonly-setting, the overhead should be 
>>> fairly small.
>>>
>>> (It compiles, but otherwise it is untested).
>>>
>>> JC, feel free to veto it if you think it would be too much overhead.
>>>
>>
>> The performance overhead is pretty small, as far as I can tell... It 
>> seems like it would fail with substrings after the first check, 
>> though (eg, "acceptonly:test123,test12,test1234" rejects 'test12').
>>
>> How about this one?
>>
>> -jc