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 <user-cc5c6e80f4c5@xymon.invalid> 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