mapping purple to red, and wild card for COMPACT

I was too quick on that... It does not really work.

Hi

so the trick to use wild card with COMPACT while avoiding the columns creation, is to block those in the hosts.cfg .default line. like this:

0.0.0.0 .default. # TRENDS:*,!whatever, !c_.*

This works for a compiled 4.3.28. Might not for others.

Still couldn't find a way around the mapping of purple to red. Will appreciate any help.

Cheers

Ron

On 11/10/2019 18:52, Ron Cohen wrote:

Hi

I was asked to create a test for the non/existence of crontab in hundreds of testers accounts. The issue is that those accounts using cron daily in order the refresh the testing environments during nights in preparation for next day activities. Testers being testers, quite often removed those crontabs, creating havoc for other testers. I wrote a small script which runs from each of those accounts cron, and sends "All good" to the xymon server. If crontab removed, the test obviously goes purple. This is working fine, but the Operation team who monitors xymon, is less sensitive to tests goes purple rather then red,and too often fails to report it.  A while ago, someone asked the same question of mapping purple to red, and I said to myself, "Oh, I should remember this!" which of-course, I didn't, and can't find that exchange... can anyone help with this?

The other issue with this solution, is that there are hundreds of those account, and being lazy, I'm not too enthusiastic with the idea  of maintaining arm length COMPACT lists. So what i tried to do is to use a wild card with the column name which is also the user name. So e.g. tester1 account will send a column c_tester1 etc. The compact will be COMPACT:crontab=c_.*

This is working - sought-of - there is a column named crontab, populated with all of the c_test accounts, BUT it also creates a column for each of them on the main page. Is there a way around it, or it is not a workable solution?

Cheers

Ron