Weird behavior of x.last(1) & x.last(2)

[novakm]

Hello everyone.
I have following problem:
I am watching a server via icmp ping, tcp,80 and http,80 simple checks (btw I wonder if tcp,80 and http,80 is the same, I couldn't find any details the check is done). I check these items once every 10s and have triggers bound to them, but sometimes I get "false positive" alarm. What I mean is that there is 0 in icmp ping history, although when I issued the ping from commandline, no ping is lost.
Ok, I said to myself that maybe in the very moment of the scan it was somehow unreachable and solved it by using
{Server 1:icmpping.last(1)}#1 & {Server 1:icmpping,.last(2)}#1
According to the docs, last(0)=last(1) is the last value, but beginning with 2, these are values in history. So it would have to be unreachable for more than 10s to trigger the alarm (or 2 "false positives" in a row, which is not very probable). However, the alarm gets triggered sometimes and when I look in the last values, there is only one 0, not two in a row. I don't get it... why the alarm gets triggered by this? I even tried to use x.last(1) & x.last(2) & x.last(3) with the same result.

I am having this problem with 1.6.2 on Debian 2.6.18 and 1.4.6 on FreeBSD.
Anyone can help, please?

Thanks!

[zabbix_zen]

"According to the docs, last(0)=last(1) is the last value"

I don't know where you read this in the manual, but last(1) means the value the item had 1 second ago, as well as last(2) means the value 2 seconds ago.

What you're looking for is,
x.last(0) & x.last(#1)
to compare with previous value. (
.last(#1) is equivalent to prev(0)
)

[richlv]

i'm a bit uncertain whether you both are reading zabbix manual

Last (most recent) value. Parameter:
sec – ignored
#num – Nth value

[novakm]

Argh, I got it wrong from the manual. As ordinal numbers are often prefixed with #, I thought this was the case too. I didn't actually try to use it exactly... I really feel embarrassed

Anyway, thanks for the tip, I believe it will solve my problem.

Martin

[zabbix_zen]

Thanks richlv,
I wrote that in a hurry and explained it in a misleading way without noticing it.

[richlv]

sure, that's understandable. thanks for helping new users