ZABBIX FEATURE REQUESTS

Add new macro to uniquely identify an alert

Details

  • Type: Improvement Improvement
  • Status: Reopened Reopened
  • Priority: Major Major
  • Resolution: Unresolved
  • 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 -

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 - 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 .
Hide
Alexander Vladishev added a comment -
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.

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

People

Vote (21)
Watch (18)

Dates

  • Created:
    Updated: