It's also important to our support team if, when a recovery notification is received, the event details responsible for resolving the alert are reported e.g.

.

This patch adds {ESC.ORIGIN.EVENT.ID} to the list of macros that can be substituted for during Action messages.

ESC.ORIGIN.EVENT.ID is the event id of the first escalation event, it will always be the same id for both problem and recovery messages and is therefore suitable for tracking incidents with their resolutions.

This patch was created against the Zabbix 1.8.8 source tarball, tested against Zabbix 1.8.5 on Ubuntu and will patch against Zabbix 1.9.6 (with 400+ fuzz).

www.2keys.ca assigns copyright for this code to zabbix.com for distribution under GPLv2 and any other licenses zabbix.com sees fit.

Please consider linking this to ZBXNEXT-1001, which also has patches attached to it... as together these will allow for Trigger Email -> JIRA Ticket workflow

The patch provided here is very trivial, yet the functionality for tracking in external systems is so useful... Can we get this targeted to 2.x.something?? I'll happily provided an updated patch if the current attached one needs updating.

with all the hard work on 2.0, this isn't on the short term roadmap yet - we'll see what time permits once 2.0 is out & stable...

Now that 2.0 is out and approaching stability, any chance we can get this added into the mix for 2.1.x?

Seems harder then pulling teeth to get a response about including a patch into Zabbix... I mean, the work is already done, right? Just needs to be merged.

Am I going about this the wrong way? Is there a devel mailing list I should send it to or an IRC channel where devs hang out?

I would also like to see this getting merged. I have been using the patch in production for a while and it works well for me.

Very much needed for integration with ITIL tooling.

Add me to the list of folks that need this feature. As other have stated, it's absolutely critical for tying alert resolution to alert creation.

please see the last item in https://zabbix.org/wiki/Docs/bug_reporting_guidelines#Reporting_an_issue

See also ZBXNEXT-252.

ZBXNEXT-1001 should be closed after implementing this one.

<richlv> hmm, ZBXNEXT-1001 doesn't seem to be related

ZBXNEXT-1318 had another proof-of-concept patch

Alexei, there is nothing to implement. All we need is someone with commit access to apply the attached 3 line patch that has been sitting here for a year and a half. If you have repo access, please stop messing about with the bug's metadata and take 2 minutes & apply the patch!

If you are having trouble downloading it, here it is again inline:

--- ./src/libs/zbxserver/expression.c	2011-10-13 11:38:42.000000000 -0400
+++ ./src/libs/zbxserver/expression.c	2011-10-13 12:01:08.000000000 -0400
@@ -1476,6 +1476,7 @@
 #define MVAR_EVENT_AGE			"{EVENT.AGE}"
 #define MVAR_EVENT_ACK_STATUS		"{EVENT.ACK.STATUS}"
 #define MVAR_EVENT_ACK_HISTORY		"{EVENT.ACK.HISTORY}"
+#define MVAR_ESC_ORIGIN_EVENT_ID	"{ESC.ORIGIN.EVENT.ID}"
 #define MVAR_ESC_HISTORY		"{ESC.HISTORY}"
 #define MVAR_HOSTNAME			"{HOSTNAME}"
 #define MVAR_PROXY_NAME			"{PROXY.NAME}"
@@ -1835,6 +1836,8 @@
 					replace_to = zbx_strdup(replace_to, event->acknowledged ? "Yes" : "No");
 				else if (0 == strcmp(m, MVAR_EVENT_ACK_HISTORY))
 					ret = get_event_ack_history(event, &replace_to);
+				else if (0 == strcmp(m, MVAR_ESC_ORIGIN_EVENT_ID))
+					replace_to = zbx_dsprintf(replace_to, "%d", (int)(escalation != NULL ? escalation->eventid : event->eventid));
 				else if (0 == strcmp(m, MVAR_ESC_HISTORY))
 					ret = get_escalation_history(event, escalation, &replace_to);
 				else if (0 == strcmp(m, MVAR_TRIGGER_SEVERITY))

What is the status of this? Has the provided patch been committed yet? Please update the ticket.

As you can see above - Status: is Open

@Oleksiy as you can see above the ticket has been open for almost 3 years, 1.5 which there has been a patch sitting there waiting to be applied that fixes the issue.

Surely the correct status should be WON'T FIX, should it not?

Garth, I just wanted to say that you can see actual status of this feature request on top of this page, as answer to your question.

If this feature would not be interesting then it would be probably closed already.
I'm sure this feature is very useful and I believe it once will be implemented.

Oleksiy, I appreciate that the literal status of the ticket is Open, but that is also the default status of a ticket when it was first created some 3 years back.

If after 3 years a dev can't stop in for a minute to even target the ticket to a future release, I really have to wonder if it will ever be fixed.

If someone handed me the fix to a problem, I'd spend a minute to look at, decide if it was worth doing/made sense and if were too complex to apply on the spot, I'd plan to apply it in a future release.

The most obvious thing to do would be to just mark this as WON'T FIX, since its unlikely to be relevant to anyone who voted for the ticket by the time it is addressed, if it is even ever addressed at all.

Just confirmed that this is in roadmap for 2.2 .

Specification: https://www.zabbix.org/wiki/Docs/specs/ZBXNEXT-384

Available in the development branch svn://svn.zabbix.com/branches/dev/ZBXNEXT-384

(1) Documentation needs to be updated.

• https://www.zabbix.com/documentation/2.2/manual/introduction/whatsnew220
• https://www.zabbix.com/documentation/2.2/manual/appendix/macros/supported_by_location
• https://www.zabbix.com/documentation/2.2/manual/installation/upgrade_notes_220

sasha Partially updated:

• https://www.zabbix.com/documentation/2.2/manual/appendix/macros/supported_by_location

martins-v Updated:

• https://www.zabbix.com/documentation/2.2/manual/introduction/whatsnew220#new_notification_macros
• https://www.zabbix.com/documentation/2.2/manual/installation/upgrade_notes_220#macro_changes

zalex_ua I think all the changes are good and may be closed.
EXCEPT one page - manual/appendix/macros/supported_by_location

It has to be improved !
(check my test in a separate comment below)
I don't see any nice way to add a lot of details to the table, so we need to add them to other pages.
Just for all {EVENT.RECOVERY.*} macro descriptions we could add internal link to "manual/config/notifications/action" page (new paragraph suggested below), I'm sure it will be useful.
We could add example(s) to https://www.zabbix.com/documentation/2.2/manual/config/notifications/action/operation/
macros where mention new macros and their behavior.

Also, on https://www.zabbix.com/documentation/2.2/manual/config/notifications/action we could add details to "Recovery message" checkbox.
On the page I believe we have to add a paragraph about the "Trigger value = PROBLEM" condition + the checkbox enabled and describe better that OK event and Recovery events ARE DIFFERENT !
We had a discussion with Rich in ZBXNEXT-452 (not finished, IMO) and I still see that zabbix users mix these two different cases.

As I recall there are also some details related to maintenance.

Maybe we need to open separate ZBX to address rest of doc changes?

martins-v RESOLVED:

• more details about recovery events added to https://www.zabbix.com/documentation/2.2/manual/config/notifications/action#configuring_an_action and linked to from recovery event macros in https://www.zabbix.com/documentation/2.2/manual/appendix/macros/supported_by_location
• example of using macros in recovery messages added to https://www.zabbix.com/documentation/2.2/manual/config/notifications/action/operation/macros

zalex_ua Reviewed, seems ok.
But I suggest to replace:
"Note: A custom recovery message works when trigger value action condition is “Trigger value=PROBLEM”."
to:
"Note: A custom recovery message for OK events works only when an action contains a “Trigger value=PROBLEM” condition. In this case the condition record is, say, being suppressed."

Then it will be more clear, imo.

martins-v I agree with the first sentence change. Not so sure about "condition record is, say, being suppressed". Reading it, I cannot immediately get/understand what a "condition record" is.

martins-v The first sentence changed, for more clarity. RESOLVED.

zalex_ua looks ok, now is CLOSED.

Successfully tested. Please review my small changes in r34941.

sasha Great! Thanks. CLOSED

Available in version pre-2.1.0 (trunk) r34950.

ZBXNEXT-1288 is a somewhat similar issue about EVENT.ACK.HISTORY

doc subissue (1) has not been reviewed, and it says "partially updated" - supposedly something is still missing ?

To check documentation changes I've performed a test:
I have two actions with two operation steps each. Delay between steps is 120 seconds (to be able to add ack).

1st action ID:8 is with "Trigger value = PROBLEM" condition and recovery message checkbox enabled - to test, say, "pure recovery" event.
2nd action ID:9 w/o the condition - to test OK event.
All 3 message bodies contain identical macros set.

Here are results (1st, 2nd steps of Problem and then OK):

As we can see the pure recovery case is different from OK.
Two important points:
Acknowledge for OK event will be inherited from PROBLEM event only in case of pure recovery.
EVENT.RECOVERY.* macros will be expanded only for pure recovery.

Based on the results I've added a comment to [1] sub issue.

This doesn't appear to be working in the "Remote Command" Custom Script functionality either. The value is never replaced when an "OK" event occurs, but that is probably due to the same as Oleksiy indicated in December.

I'm using Zabbix 2.2.2 and still cannot use a macro that uses the "original" event ID that triggered the PROBLEM in the recovery message.

I do not understand why this has been marked as fixed.

Is this really implemented?

Given this is supposedly "fixed" with 2.1.0 it should be working on our v3.0.16 install. Yet neither {EVENT.RECOVERY.ID} nor {ESC.ORIGIN.EVENT.ID} makros are expanded and {EVENT.ID} differs between PROBLEM and OK trigger in the remote command.

When following the manual, i.e. checking "Recovery message" and setting trigger.value=problem as condition, then no remote command is executed on recovery (which makes sense looking at the condition, but is in contradiction to the manual).

 Any news on this ? or anyway to get our ticket systems to uniquely identify a monitoring alert and prevent flapping to create multiple new tickets?