Redhat 7.4

Do you mean that it takes this trigger 5 minutes after agent becomes unreachable to go into problem state, but it takes only 23 to get back to OK? If yes, what would be your suggestions to fix the trigger?

Hi Glebs,
from my point of view, this view must have some problem. Is surely wrong recovery time before detect time. For me if the problem is detected to 13:01:30 the time for tag 'resolved' must be after some second or minutes.. After this I don't known Zabbix architecture.. and so I can't give you idea for solve this trouble.
In add.. I have note this only with this version.. V3.4.5 -neve seen before this release. And have some alarm like this "Zabbix agent is unreachable for 5 minutes" and also this never seen before this version.

All the best.

Giorgio Biondi.

Ah, got it. Can you provide steps to reproduce the issue?

Hi Glebs,
no step need.. I have host linux with agent 3.4.2 AND 3.2.0 and this behaviur random on all hosts.. but always with error "Zabbix agent is unreachable for 5 minutes"...

Managed to reproduce with nodata() trigger based on trapper item by sending value with timestamp from the past when trigger is PROBLEM.

I think what happens is that nodata() trigger gets calculated by timer process and generates an event with current time as a timestamp, then it gets recalculated when the item gets new value (by history syncer) and the timestamp of item value is used as recovery event timestamp. So the recovery will always be before problem, which looks confusing.

Also frontend miscalculates Duration, looks like it takes the absolute value.

Hi at all..

I have installed new version V.3.4.6 and the problem is the same.. The issue is resolver BEFORE occurred..

06:11:30 Average 06:11:26 RESOLVED

Hi,

please edit the version affected.. please add also V3.4.6

Best regard.

Quoting reporting guidelines:

If an issue is reported against some version, it is supposed to affect that version and all later versions, unless noted otherwise.

Most likely solution will be to document this behaviour in more detail and definitely fix duration calculation in the frontend.

(1) No translation string changes.

sasha CLOSED

RESOLVED in svn://svn.zabbix.com/branches/dev/ZBX-13309

Fixed in:

• 3.4.8rc1 r78625
• 4.0.0alpha5 (trunk) r78626

Let's consider one of the most common situations when problem recovery time is displayed before problem start time.
There is a proxy that is monitoring an item and is constantly sending data to a server. After some time occurs an unexpected network error. The server is no longer receiving data about the item and item.nodata() trigger is fired. The proxy keeps collecting data for the server. When network error is fixed, proxy continues to send data to the server and server marks problem as resolved. In this case resolve event will be created with time when next item data was received by proxy, and it will be earlier, than problem was created. And such case will result in a negative problem duration.
Other common situation would be, when resolve item data for resolve event would be sent by Zabbix sender and will contain timestamp earlier than problem creation time.

It is proposed that similar examples should be added to the documentation.

martins-v Great, thanks for these examples.

Documentation:

• Examples of possible negative problem duration added to documentation for 3.4, 4.0.
• Also mentioned in what's new for 3.4.8 that negative values can be displayed

How does negative duration affect Reports -> Availability report and SLA calculation in services:

• Documented as part of ZBX-14592