Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.8.2
    • Fix Version/s: 2.1.0
    • Component/s: None

      Description

      We need to have a way to uniquely identify an alert during its whole life cycle.
      EVENT.ID cannot be used because a new event is generated on recovery (trigger goes from PROBLEM to OK state).

      This feature is important because we need to automatically open and close tickets on an ITSM system and automatic closing is impossible without it.

      A possible solution would be to have a

      {EVENTID.SRC}

      /ORIG or whatever macro in recovery message that would return EVENT.ID of the event that triggered the alert.

        Issue Links

          Activity

          Hide
          Danny Lancashire added a comment -

          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.

          {EVENT.RECOVER}

          .

          Show
          Danny Lancashire added a comment - 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. {EVENT.RECOVER} .
          Hide
          Garth Dahlstrom added a comment - - edited

          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.

          Show
          Garth Dahlstrom added a comment - - edited 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.
          Hide
          Garth Dahlstrom added a comment -

          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

          Show
          Garth Dahlstrom added a comment - 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
          Hide
          Garth Dahlstrom added a comment -

          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.

          Show
          Garth Dahlstrom added a comment - 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.
          Hide
          richlv added a comment -

          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...

          Show
          richlv added a comment - 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...
          Hide
          Garth Dahlstrom added a comment -

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

          Show
          Garth Dahlstrom added a comment - Now that 2.0 is out and approaching stability, any chance we can get this added into the mix for 2.1.x?
          Hide
          Garth Dahlstrom added a comment -

          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?

          Show
          Garth Dahlstrom added a comment - 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?
          Hide
          lubyou added a comment -

          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.

          Show
          lubyou added a comment - 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.
          Hide
          Raymond Kuiper added a comment -

          Very much needed for integration with ITIL tooling.

          Show
          Raymond Kuiper added a comment - Very much needed for integration with ITIL tooling.
          Hide
          Robby Dermody added a comment -

          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.

          Show
          Robby Dermody added a comment - 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.
          Hide
          richlv added a comment -
          Show
          richlv added a comment - please see the last item in https://zabbix.org/wiki/Docs/bug_reporting_guidelines#Reporting_an_issue
          Hide
          Alexei Vladishev added a comment -

          See also ZBXNEXT-252.

          Show
          Alexei Vladishev added a comment - See also ZBXNEXT-252 .
          Hide
          Alexei Vladishev added a comment - - edited

          ZBXNEXT-1001 should be closed after implementing this one.

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

          Show
          Alexei Vladishev added a comment - - edited ZBXNEXT-1001 should be closed after implementing this one. <richlv> hmm, ZBXNEXT-1001 doesn't seem to be related
          Hide
          richlv added a comment -

          ZBXNEXT-1318 had another proof-of-concept patch

          Show
          richlv added a comment - ZBXNEXT-1318 had another proof-of-concept patch
          Hide
          Garth Dahlstrom added a comment - - edited

          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))
          
          Show
          Garth Dahlstrom added a comment - - edited 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))
          Hide
          Garth Dahlstrom added a comment -

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

          Show
          Garth Dahlstrom added a comment - What is the status of this? Has the provided patch been committed yet? Please update the ticket.
          Hide
          Oleksiy Zagorskyi added a comment -

          As you can see above - Status: is Open

          Show
          Oleksiy Zagorskyi added a comment - As you can see above - Status: is Open
          Hide
          Garth Dahlstrom added a comment -

          @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?

          Show
          Garth Dahlstrom added a comment - @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?
          Hide
          Oleksiy Zagorskyi added a comment -

          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.

          Show
          Oleksiy Zagorskyi added a comment - 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.
          Hide
          Garth Dahlstrom added a comment -

          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.

          Show
          Garth Dahlstrom added a comment - 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.
          Hide
          dimir added a comment -

          Just confirmed that this is in roadmap for 2.2 .

          Show
          dimir added a comment - Just confirmed that this is in roadmap for 2.2 .
          Show
          Alexander Vladishev added a comment - Specification: https://www.zabbix.org/wiki/Docs/specs/ZBXNEXT-384
          Hide
          Alexander Vladishev added a comment -

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

          Show
          Alexander Vladishev added a comment - Available in the development branch svn://svn.zabbix.com/branches/dev/ZBXNEXT-384
          Hide
          Alexander Vladishev added a comment - - edited

          (1) Documentation needs to be updated.

          Alexander Vladishev Partially updated:

          Martins Valkovskis Updated:

          Oleksiy Zagorskyi 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 Valkovskis RESOLVED:

          Oleksiy Zagorskyi 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 Valkovskis 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 Valkovskis The first sentence changed, for more clarity. RESOLVED.

          Oleksiy Zagorskyi looks ok, now is CLOSED.

          Show
          Alexander Vladishev added a comment - - edited (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 Alexander Vladishev Partially updated: https://www.zabbix.com/documentation/2.2/manual/appendix/macros/supported_by_location Martins Valkovskis 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 Oleksiy Zagorskyi 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 Valkovskis 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 Oleksiy Zagorskyi 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 Valkovskis 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 Valkovskis The first sentence changed, for more clarity. RESOLVED. Oleksiy Zagorskyi looks ok, now is CLOSED.
          Hide
          dimir added a comment - - edited

          Successfully tested. Please review my small changes in r34941.

          Alexander Vladishev Great! Thanks. CLOSED

          Show
          dimir added a comment - - edited Successfully tested. Please review my small changes in r34941. Alexander Vladishev Great! Thanks. CLOSED
          Hide
          Alexander Vladishev added a comment -

          Available in version pre-2.1.0 (trunk) r34950.

          Show
          Alexander Vladishev added a comment - Available in version pre-2.1.0 (trunk) r34950.
          Hide
          richlv added a comment -

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

          Show
          richlv added a comment - ZBXNEXT-1288 is a somewhat similar issue about EVENT.ACK.HISTORY
          Hide
          richlv added a comment -

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

          Show
          richlv added a comment - doc subissue (1) has not been reviewed, and it says "partially updated" - supposedly something is still missing ?
          Hide
          Oleksiy Zagorskyi added a comment -

          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):

          event\action for Recovery for OK
          1st step ACTION.ID: 8
          ACTION.NAME: Test ation - for Recovery condition
          EVENT.ID: 6444
          EVENT.TIME: 17:01:18
          EVENT.DATE: 2013.12.26
          EVENT.AGE: 0m
          EVENT.ACK.HISTORY:
          EVENT.ACK.STATUS: No
          EVENT.RECOVERY.ID: {EVENT.RECOVERY.ID}
          EVENT.RECOVERY.STATUS: {EVENT.RECOVERY.STATUS}
          EVENT.RECOVERY.VALUE: {EVENT.RECOVERY.VALUE}
          EVENT.RECOVERY.TIME: {EVENT.RECOVERY.TIME}
          EVENT.RECOVERY.DATE: {EVENT.RECOVERY.DATE}
          ACTION.ID: 9
          ACTION.NAME: Test ation - for OK condition
          EVENT.ID: 6444
          EVENT.TIME: 17:01:18
          EVENT.DATE: 2013.12.26
          EVENT.AGE: 0m
          EVENT.ACK.HISTORY:
          EVENT.ACK.STATUS: No
          EVENT.RECOVERY.ID: {EVENT.RECOVERY.ID}
          EVENT.RECOVERY.STATUS: {EVENT.RECOVERY.STATUS}
          EVENT.RECOVERY.VALUE: {EVENT.RECOVERY.VALUE}
          EVENT.RECOVERY.TIME: {EVENT.RECOVERY.TIME}
          EVENT.RECOVERY.DATE: {EVENT.RECOVERY.DATE}
          2nd step ACTION.ID: 8
          ACTION.NAME: Test ation - for Recovery condition
          EVENT.ID: 6444
          EVENT.TIME: 17:01:18
          EVENT.DATE: 2013.12.26
          EVENT.AGE: 2m
          EVENT.ACK.HISTORY: 2013.12.26 17:01:42 "Zabbix Administrator (Admin)"
          An ack on a 10 seconds
          EVENT.ACK.STATUS: Yes
          EVENT.RECOVERY.ID: {EVENT.RECOVERY.ID}
          EVENT.RECOVERY.STATUS: {EVENT.RECOVERY.STATUS}
          EVENT.RECOVERY.VALUE: {EVENT.RECOVERY.VALUE}
          EVENT.RECOVERY.TIME: {EVENT.RECOVERY.TIME}
          EVENT.RECOVERY.DATE: {EVENT.RECOVERY.DATE}
          ACTION.ID: 9
          ACTION.NAME: Test ation - for OK condition
          EVENT.ID: 6444
          EVENT.TIME: 17:01:18
          EVENT.DATE: 2013.12.26
          EVENT.AGE: 2m
          EVENT.ACK.HISTORY: 2013.12.26 17:01:42 "Zabbix Administrator (Admin)"
          An ack on a 10 seconds
          EVENT.ACK.STATUS: Yes
          EVENT.RECOVERY.ID: {EVENT.RECOVERY.ID}
          EVENT.RECOVERY.STATUS: {EVENT.RECOVERY.STATUS}
          EVENT.RECOVERY.VALUE: {EVENT.RECOVERY.VALUE}
          EVENT.RECOVERY.TIME: {EVENT.RECOVERY.TIME}
          EVENT.RECOVERY.DATE: {EVENT.RECOVERY.DATE}
          OK event ACTION.ID: 8
          ACTION.NAME: Test ation - for Recovery condition
          EVENT.ID: 6444
          EVENT.TIME: 17:01:18
          EVENT.DATE: 2013.12.26
          EVENT.AGE: 6m
          EVENT.ACK.HISTORY: 2013.12.26 17:01:42 "Zabbix Administrator (Admin)"
          An ack on a 10 seconds
          EVENT.ACK.STATUS: Yes
          EVENT.RECOVERY.ID: 6448
          EVENT.RECOVERY.STATUS: OK
          EVENT.RECOVERY.VALUE: 0
          EVENT.RECOVERY.TIME: 17:07:24
          EVENT.RECOVERY.DATE: 2013.12.26
          ACTION.ID: 9
          ACTION.NAME: Test ation - for OK condition
          EVENT.ID: 6448
          EVENT.TIME: 17:07:24
          EVENT.DATE: 2013.12.26
          EVENT.AGE: 0m
          EVENT.ACK.HISTORY:
          EVENT.ACK.STATUS: No
          EVENT.RECOVERY.ID: {EVENT.RECOVERY.ID}
          EVENT.RECOVERY.STATUS: {EVENT.RECOVERY.STATUS}
          EVENT.RECOVERY.VALUE: {EVENT.RECOVERY.VALUE}
          EVENT.RECOVERY.TIME: {EVENT.RECOVERY.TIME}
          EVENT.RECOVERY.DATE: {EVENT.RECOVERY.DATE}

          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.

          Show
          Oleksiy Zagorskyi added a comment - 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): event\action for Recovery for OK 1st step ACTION.ID: 8 ACTION.NAME: Test ation - for Recovery condition EVENT.ID: 6444 EVENT.TIME: 17:01:18 EVENT.DATE: 2013.12.26 EVENT.AGE: 0m EVENT.ACK.HISTORY: EVENT.ACK.STATUS: No EVENT.RECOVERY.ID: {EVENT.RECOVERY.ID} EVENT.RECOVERY.STATUS: {EVENT.RECOVERY.STATUS} EVENT.RECOVERY.VALUE: {EVENT.RECOVERY.VALUE} EVENT.RECOVERY.TIME: {EVENT.RECOVERY.TIME} EVENT.RECOVERY.DATE: {EVENT.RECOVERY.DATE} ACTION.ID: 9 ACTION.NAME: Test ation - for OK condition EVENT.ID: 6444 EVENT.TIME: 17:01:18 EVENT.DATE: 2013.12.26 EVENT.AGE: 0m EVENT.ACK.HISTORY: EVENT.ACK.STATUS: No EVENT.RECOVERY.ID: {EVENT.RECOVERY.ID} EVENT.RECOVERY.STATUS: {EVENT.RECOVERY.STATUS} EVENT.RECOVERY.VALUE: {EVENT.RECOVERY.VALUE} EVENT.RECOVERY.TIME: {EVENT.RECOVERY.TIME} EVENT.RECOVERY.DATE: {EVENT.RECOVERY.DATE} 2nd step ACTION.ID: 8 ACTION.NAME: Test ation - for Recovery condition EVENT.ID: 6444 EVENT.TIME: 17:01:18 EVENT.DATE: 2013.12.26 EVENT.AGE: 2m EVENT.ACK.HISTORY: 2013.12.26 17:01:42 "Zabbix Administrator (Admin)" An ack on a 10 seconds EVENT.ACK.STATUS: Yes EVENT.RECOVERY.ID: {EVENT.RECOVERY.ID} EVENT.RECOVERY.STATUS: {EVENT.RECOVERY.STATUS} EVENT.RECOVERY.VALUE: {EVENT.RECOVERY.VALUE} EVENT.RECOVERY.TIME: {EVENT.RECOVERY.TIME} EVENT.RECOVERY.DATE: {EVENT.RECOVERY.DATE} ACTION.ID: 9 ACTION.NAME: Test ation - for OK condition EVENT.ID: 6444 EVENT.TIME: 17:01:18 EVENT.DATE: 2013.12.26 EVENT.AGE: 2m EVENT.ACK.HISTORY: 2013.12.26 17:01:42 "Zabbix Administrator (Admin)" An ack on a 10 seconds EVENT.ACK.STATUS: Yes EVENT.RECOVERY.ID: {EVENT.RECOVERY.ID} EVENT.RECOVERY.STATUS: {EVENT.RECOVERY.STATUS} EVENT.RECOVERY.VALUE: {EVENT.RECOVERY.VALUE} EVENT.RECOVERY.TIME: {EVENT.RECOVERY.TIME} EVENT.RECOVERY.DATE: {EVENT.RECOVERY.DATE} OK event ACTION.ID: 8 ACTION.NAME: Test ation - for Recovery condition EVENT.ID: 6444 EVENT.TIME: 17:01:18 EVENT.DATE: 2013.12.26 EVENT.AGE: 6m EVENT.ACK.HISTORY: 2013.12.26 17:01:42 "Zabbix Administrator (Admin)" An ack on a 10 seconds EVENT.ACK.STATUS: Yes EVENT.RECOVERY.ID: 6448 EVENT.RECOVERY.STATUS: OK EVENT.RECOVERY.VALUE: 0 EVENT.RECOVERY.TIME: 17:07:24 EVENT.RECOVERY.DATE: 2013.12.26 ACTION.ID: 9 ACTION.NAME: Test ation - for OK condition EVENT.ID: 6448 EVENT.TIME: 17:07:24 EVENT.DATE: 2013.12.26 EVENT.AGE: 0m EVENT.ACK.HISTORY: EVENT.ACK.STATUS: No EVENT.RECOVERY.ID: {EVENT.RECOVERY.ID} EVENT.RECOVERY.STATUS: {EVENT.RECOVERY.STATUS} EVENT.RECOVERY.VALUE: {EVENT.RECOVERY.VALUE} EVENT.RECOVERY.TIME: {EVENT.RECOVERY.TIME} EVENT.RECOVERY.DATE: {EVENT.RECOVERY.DATE} 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.
          Hide
          Frank added a comment -

          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.

          Show
          Frank added a comment - 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.
          Hide
          Mohammed Razem added a comment -

          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.

          Show
          Mohammed Razem added a comment - 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.

            People

            • Assignee:
              Unassigned
              Reporter:
              Alixen
            • Votes:
              23 Vote for this issue
              Watchers:
              22 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: