purple pages 🔗 link

On Aug 3, 2017 2:46 PM, "Frank" <user-fbc5ef527f6f@xymon.invalid> wrote:

   Hi Everyone,

   I have a feature request or possibly a bug.  If I make a change to the
hosts.cfg, for
example deleting a client the data remains and if I don't remove it the
client turns
purple and then pages.  Is there something that can be done, automated
process to
compare what is in the data files against the hosts file and then remove
any inconsistencies.
Something like this perhaps?

--

sysadm  cronomagic.com/gemstelecom.com
e-mail  user-fbc5ef527f6f@xymon.invalid

POWERED BY LINUX

On 8/3/17 15:48, Josh Luthman wrote:

That's intentional.  Use the command to delete the historical data.

Josh Luthman
Office: XXX-XXX-XXXX
Direct: XXX-XXX-XXXX
XXXX Wayne St
Suite XXXX
Troy, OH XXXXX

On Aug 3, 2017 2:46 PM, "Frank" <user-fbc5ef527f6f@xymon.invalid 
<mailto:user-fbc5ef527f6f@xymon.invalid>> wrote:

       Hi Everyone,

       I have a feature request or possibly a bug.  If I make a change
    to the hosts.cfg, for
    example deleting a client the data remains and if I don't remove
    it the client turns
    purple and then pages.  Is there something that can be done,
    automated process to
    compare what is in the data files against the hosts file and then
    remove any inconsistencies.
    Something like this perhaps?

    -- 

    sysadm cronomagic.com/gemstelecom.com

On 8/3/2017 11:46 AM, Frank wrote:

Is there something that can be done, automated process to
compare what is in the data files against the hosts file and then remove
any inconsistencies.

On 8/3/17 16:35, John Thurston wrote:

On 8/3/2017 11:46 AM, Frank wrote:

Is there something that can be done, automated process to
compare what is in the data files against the hosts file and then remove
any inconsistencies.

On an old instance of Big Brother, our business requirements include just destroying everything purple. We use the following (extremely crude) sledge hammer:

/usr/bin/rm -f `/usr/bin/grep -l "^purple " /opt/bb/bbvar/logs/*`

In our old BB, we run it with crond. On Xymon, it could be just another xymon task.


On our production instance of Xymon, we don't simply remove entries from the hosts.cfg file. We use a script with following syntax:

  Syntax: RetireXY hostname [[hostname]...]

It runs through the offered hostnames and confirms each exists in the hosts.cfg. It then inserts a new display group (with today's date) in a file called retired_hosts.cfg, moves in all original lines for the offered hostnames _as comments_, and creates a new line with for each with all tests suppressed. It then enables any disabled tests for the named hosts.

The above script doesn't destroy data in Xymon. It preserves the original test settings, and all test results for the host so we could include those in reports. It puts the "retired" hosts on an obscure page in Xymon, while giving us a straight forward timeline of retirements.


Every now and then (one a year?), we run another script with identical syntax, called
   DestroyRetired
It confirms all of the offered hostnames have been retired, and removes their lines (and comments) from retired_hosts


We have yet another script with the following syntax:

  Syntax: CleanupPurple hostname testname [[ testname]...]

which our admins can use to blast purple splotches from the screen. It confirms the hostname exists in hosts.cfg, and the requested tests are purple. It then submits the correct "drop" commands to xymon for the specific host and test combinations. This saves us from someone accidentally submitting a "drop foobar.com" command, when they meant to submit "drop foo.bar.com http" :p  {raises hand}

-- 

sysadm  cronomagic.com/gemstelecom.com
e-mail  user-fbc5ef527f6f@xymon.invalid

POWERED BY LINUX