API: How to find recovery eventid from original eventid and vice versa

[uKaNU]

Hi,

Using the Zabbix API, for a given an event id, how can I find the related Original or Recovery event id?

For example: This generated alert contains such information
--------------------------------------------------------------------------
10.x.x.x is unavailable by ICMP: OK

Problem:

Original Event ID: 176063
Problem Value: 1
Problem Status: PROBLEM
Problem Date: 09:29:51 2015.03.25

Recovery:

Recovery Event ID: 190134
Recovery Value: 0
Recovery Status: OK
Recovery Date: 11:55:51 2015.03.25

Outstanding Duration: 2h 26m
Acknowledgement: No
Acknowledgement History:
--------------------------------------------------------------------------

The only way I can think of now is by parsing the alerts with a later date for the related host and look for this data. But I'm hoping to find a better way.

Thanks.

[joseh]

Hi!

I ran into this problem today.
In my case, I would like to find out if a recovery event exists before executing an action.

I am still playing with it but it shows promise, here's what I did:

I queried the API through event.get and passed three parameters on three objects.
1. time_from I set it to the original event's 'clock' value so that I will get only events after the PROBLEM event.
2. filter I set to objectid with value of the triggerid which we get from the original PROBLEM event.
3. (optional) limit can be set to 2 so that you get only the event proceeding the problem.

for me it returns something like the following:

[
    {
        "eventid": "557504",
        "source": "0",
        "object": "0",
        "objectid": "15195",
        "clock": "1427381057",
        "value": "1",
        "acknowledged": "0",
        "ns": "132219537"
    },
{
        "eventid": "557506",
        "source": "0",
        "object": "0",
        "objectid": "15195",
        "clock": "1427381117",
        "value": "0",
        "acknowledged": "0",
        "ns": "569004342"
    }
]

So, in this case, (I'm using PHP api) my original event will be $event[0] and my recovery event will be $event[1].
Now, I believe this will work because a trigger can only go into PROBLEM state _from_ an OK state. Cannot go from PROBLEM to PROBLEM.

Someone please correct me if I'm wrong.
I am still experimenting with this and would like to do it right myself.

I hope this helps to some extent.
For finding the original event from a recovery event I assume you can use the same method but instead make the api call using time_till instead of time_from. I have not tested it.

edit: It appears that triggerids are unique per host even if from a template. I believe this method should be reliable.
edit2: Use FILTER instead of SEARCH. I had some false positives show.

[uKaNU]

Hi joseh,

Thanks for that. Appreciate it. I had a look inside the database and your method seems to reliable. I can get the triggerid from the alerts via events.

I'm not sure if the PHP API has this implemented. I'm using C# and using our own API.
But if you also set object = 0 and source = 0 then we can be sure it will only return events from a trigger.

I suggest further filter by hostid(s) and in your case, sorting by eventid in the sortfield. That should make sure your array $event contains the events in the right order instead of relying on the default order which might change in the future.

[joseh]

Hi joseh,

Thanks for that. Appreciate it. I had a look inside the database and your method seems to reliable. I can get the triggerid from the alerts via events.

I'm not sure if the PHP API has this implemented. I'm using C# and using our own API.
But if you also set object = 0 and source = 0 then we can be sure it will only return events from a trigger.

I suggest further filter by hostid(s) and in your case, sorting by eventid in the sortfield. That should make sure your array $event contains the events in the right order instead of relying on the default order which might change in the future.

uKaNU,

I am glad it was of help to you.

I also appreciate your advice and will look into implementing that as it is a good idea to future-proof this.

Thank you.