Simple check for HTTP returns 2

[steve.hall]

I am in the process of commissioning a new Zabbix monitoring server to replace an existing one, this has been built from scratch - I have not dumped/loaded the data from the original box. The old server is running Zabbix 1.1beta9, the new 1.1.2.

My problem is that the simple http check for a remote web server returns 0 when the site is down under 1.1beta9, but 1.1.2 returns 2. Also the http_perf check under 1.1beta9 is showing 0 but 1.1.2 shows 5.01! Looking at the manual I believe the 1.1beta9 behaviour is what should be happening. I could change the triggers to look for 2 instead of 0 but I'm wondering if there is something I've done wron somewhere. Any ideas?

[DiedX]

This is the same issue with Zabbix 1.1.4. Everything else works like a charm, but my browser times out, and Zabbix returns an 2 instead of an 0.

[Calimero]

This is actually an undocumented feature

1 = OK
2 = Timeout
0 = unreachable (?) or TCP port closed/server not listening at all

If you want to test this and your zabbix server is on Linux:

1.2.3.4 = HTTP server IP

iptables -I OUTPUT -p tcp --destination 1.2.3.4 --destination-port 80 -j REJECT
==> packet will be rejected, simple check will fail with return value 0

Use:
iptables -D OUTPUT -p tcp --destination 1.2.3.4 --destination-port 80 -j REJECT
to remove the filtering rule.

Then:
iptables -I OUTPUT -p tcp --destination 1.2.3.4 --destination-port 80 -j DROP
==> packet will be dropped without any reply, simple check will timeout and return 2

Use:
iptables -D OUTPUT -p tcp --destination 1.2.3.4 --destination-port 80 -j DROP
to remove rule.

You should write you triggers like this:
{some.host:http.last(0)}#1

[DiedX]

That is what I thought

[steve.hall]

DiedX & Calimero,

Thanks for the response, it does work as you say.

I just need to get the IT guys to believe that there is actually a problem. When I created the action it had the words 'website down' in it, of course when they check the webserver it is actually running (I think the problem is their connectivity to the internet).

Of course they decided to test the monitoring by temporarily blocking port 80 using the firewall - just after I switched the check to test for a 2, so the event was missed Wish I'd thought of the iptables trick!

Cheers,

Steve