When I have this happen, it's usually due to something I've done in the config somewhere such that the hostname is not what I thought it was. If you have the mlocate package installed on your server, just run 'locate ASDSim' and see what's returned...it should give you a better idea of exactly what you need to feed the drop command.

=G=

From: Xymon <xymon-bounces at xymon.com> on behalf of Mitchell, Kelvin <kelvin.mitchell at 4mresearch.com> Sent: Tuesday, August 29, 2017 10:05 AM To: xymon at xymon.com Subject: [Xymon] Removing Custom Column question.

EXTERNAL

Hello all,

I know this is probably a horribly stupid question. I created at custom column called ASDSim coming from a client xymon agent. I have tried removing the using the drop command, removing the [ASDSim] tag from the cfg file, and removing the script itself, etc. But it still displays on the monitor. The only way I can get the column off is to put it in the NOCOLUMNS section of the cfg file. Is that the only way, or am I just blind and totally missing something in the documentation?

Thanks!

Kel

From: Xymon <xymon-bounces at xymon.com> on behalf of xymon-request at xymon.com <xymon-request at xymon.com> Sent: Tuesday, August 29, 2017 5:00 AM To: xymon at xymon.com Subject: Xymon Digest, Vol 79, Issue 11

Send Xymon mailing list submissions to xymon at xymon.com

To subscribe or unsubscribe via the World Wide Web, visit http://lists.xymon.com/mailman/listinfo/xymon Xymon -- Discussions about the Xymon monitor<http://lists.xymon.com/mailman/listinfo/xymon> lists.xymon.com The Xymon monitor - www.xymon.com - is an Open Source (GPL) licensed monitoring system. This mailing list is for discussions about installing and using Xymon.

or, via email, send a message with subject or body 'help' to xymon-request at xymon.com

You can reach the person managing the list at xymon-owner at xymon.com

When replying, please edit your Subject line so it is more specific than "Re: Contents of Xymon digest..."

Today's Topics:

1. how to enable/disable an alert automatically (or make an alert conditional upon something else)? (Ribeiro, Glauber)
2. Re: how to enable/disable an alert automatically (or make an alert conditional upon something else)? (Root, Paul T)
3. Loaded client stops reporting to the server (Ribeiro, Glauber)
4. Re: Critical System Page -- HTTP 500 Error (EDSchminke at Hormel.com)
5. Re: Loaded client stops reporting to the server (Ribeiro, Glauber)
6. Suggestion: monitor CPU utilization by process (Ribeiro, Glauber)
7. Re: Suggestion: monitor CPU utilization by process (Root, Paul T)
8. Re: Suggestion: monitor CPU utilization by process (Jeremy Laidman)

Message: 1 Date: Mon, 28 Aug 2017 19:46:24 +0000 From: "Ribeiro, Glauber" <glauber.ribeiro at experian.com> To: "xymon at xymon.com" <xymon at xymon.com> Subject: [Xymon] how to enable/disable an alert automatically (or make an alert conditional upon something else)? Message-ID: <135DD93F19DFE347BC300E008E6744BCFB92C42B at MCKEXCH04.ena.us.experian.local>

Content-Type: text/plain; charset="utf-8"

Hello,

We have a very common situation where there are 2 servers, one being the production server, and the other its “spare”. If anything happens to the production server, we need people to be alerted even if it’s the middle of the night. On the other hand, if the spare server has problems, we may not need to wake people up.

The server roles swap periodically (the one that is production this month may be spare next month, and vice versa).

I can tell which one is production by watching for the existence of certain “flag files”, but I can imagine other places would have different mechanisms.

The question is: is there a way in xymon, to make an alert conditional on some other piece of information? Some way to handle this kind of situation, where the “decision” on the criticality of a server is outside xymon?

I think I could handle this by sending the alert to a script, and having logic in the script to send the communication or not. But I’m wondering if there is a better way, and I imagine that this kind of situation is common enough that people here must have seen it.

Thanks,

glauber