Hello,

I could confirm that we also had the same problem.

As a workaround we use a bit more complicated trigger expression.
In your example, instead of initial trigger expression

{host:green.last()}>{host:red.last()}

it is possible to use the following:

{host:green.count(30)}>0 & {host:red.count(30)}>0 & {host:green.last()}>{host:red.last()}

I.e. initial trigger expression (comparing green and red items) will be used only if both these items have a values updated during the last 30 seconds.
The timeout (30 seconds in this case) should be smaller than an update interval for both items, but big enough to have Zabbix-server chance to correctly process both new values even on a busy server.

That is a really cool solution, but the problem is that when that trigger becomes true, on next item fetch it will become false because of the count expressions. For that trigger to work, you would need to use TRIGGER.VALUE, something like this (I didn't test it and I use the 2.4 syntax):

({TRIGGER.VALUE}=1 and not ({host:green.count(30)}>0 and {host:red.count(30)}>0))
or
({host:green.count(30)}>0 and {host:red.count(30)}>0 and {host:green.last()}>{host:red.last()})

But all of this is still a workaround which makes trigger expressions harder to read and understand. Zabbix should support this out of the box for items with the same timestamp.

P.S. In your example, if your items are refreshed every 30 seconds, shouldn't you use count(29)>0?

Good point, thanks.

We use a long enough refresh interval for items (about 20 minutes), so 30 seconds for the count() function is a good timeout. It is just to be sure that item was refrshed "recently" (i.e. both item's values are "fresh").

Really, we need to check a trigger state and describe a different conditions for correct trigger opening/closing. It is possible; however, a very simple trigger expression is transformed to a difficult for understanding (and error-prone) hysteresis-like expression. Of course, it could be much better if we can simple and clear trigger expressions "out of the box" (without these tricks).

Issue description doesn't mention several important points.
Many values may come to zabbix server during single second and that's ok. Fact also is that zabbix uses nanoseconds for time precision.
It's guaranteed (on agent or server side) that two values of an item cannot get identical unix timestamp and nanosecond when they comes into write cache.
Write cache (including triggers evaluation) then processed by history syncers.

I don't think it can be implemented at all, as we even cannot resolve ZBX-9201

Wouldn't it be possible to delay trigger evaluations on triggers with multiple items (for a second or something like that). If zabbix_sender sends two items with the exact same timestamp and those items are used in one trigger, when the first item value is received in the cache, check if the other item's value is within a second, if not, wait a second and evaluate the trigger again. Of course I have no idea if this is possible to do, since I haven't read the Zabbix trigger evaluation code.

If above is not possible, could we maybe add a new function which would make these triggers easier to read, or for example add an additional parameter to last(), e.g.:

{host:green.last(0,3s)}>{host:red.last(0,3s)})

3s means that both green and red have a fresh value within the last 3 seconds.

1. I'm not developer but I suppose it would not be possible, IMO. Remember please about systems with very high NVPS. I could not imagine there any delays.
2. Didn't really get the example

I would translate suggested fictional

{host:green.last(0,3s)}>{host:red.last(0,3s)}

into supported

{host:green.fuzzytime(3s)}=1 and {host:red.fuzzytime(3s)}=1 and ({host:green.last()}>{host:red.last()})

Or more sophisticated variant which preserves existing trigger state if at least one of item values is not "fresh":

({host:green.fuzzytime(3s)}=1 and {host:red.fuzzytime(3s)}=1) * ({host:green.last()}>{host:red.last()}) +
({host:green.fuzzytime(3s)}=0 or {host:red.fuzzytime(3s)}=0) * {TRIGGER.VALUE}

I don't understand how would fuzztyime(3s) help in this situation, since it only checks if the difference between current time of the host and Zabbix server is more than 3 seconds.

Not between host time and server time, but between item value timestamp and current server time.

Looking at the docs I would say fuzzytime only works with items which value is the timestamp, if it's not, it cannot be used. If items red and green are not timestamps, then fuzzytime won't do anything.

Yes, indeed. Sorry for being misleading.

in ZBX-10360 we improved the fuzzytime function description in documentation and item key helper (for 3.0 only).
The doc currently says "item timestamp value", which looks a bit more correct than Gleb's "item value timestamp"

and it sounds like you might want to vote on ZBXNEXT-2045