You could use SCRIPT instead of MAIL in alerts.cfg, and then in your script you can create whatever subject you like, where $ACKCODE env var will be populated by the alert cookie. You might have slightly different email messages compared with those produced by the MAIL option, but I would guess that with a bit of scripting trial-and-error you should be able to get it pretty close.

J

On 2 September 2015 at 01:24, Mike Burger <mburger at bubbanfriends.org> wrote:

Good morning, all.

Using Xymon in my business environment, we're configured to send alarm emails and recovery emails to our operations center. The emails go into an alarm console, so that the NOCC has a single pane of glass for the initial alarms.

I was asked, this morning, and am noticing this behavior for the first time.

When Xymon sends out yellow or red alarms, there is an alarm ID number in the subject, a la:

Xymon [137502] fqdn.domain.com:http CRITICAL (RED)

or in the body, a la:

hostname:procs red [445232]

But when the alarm recovers, the alarms that had the ID in the subject do not include that ID in the recovery email:

Xymon fqdn.domain.com http recovered

and for the alarms where the ID was in the body, that ID is changed to 0:

hostname:procs red [0]

What I'm being asked for is if we can include the previous alarm ID, so that they can more easily correlate the alarm/recovery pairings (and perhaps add some automation to the mix).

So, I ask...is there something I can configure to make this happen or is this a coding change? If the former, what do I need to do to make it happen? If the latter, is this something the development team is willing to undertake?

Thanks.

Mike Burger http://www.bubbanfriends.org

"It's always suicide-mission this, save-the-planet that. No one ever just stops by to say 'hi' anymore." --Colonel Jack O'Neill, SG1

---

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon