Item Depency - Zabbix Queuing mechanism!!!

[brandy]

I found out, that there is some kind of item depency in zabbix. For example, i create a snmp host and add several items. One of this items have a wrong configuration (wrong community). When this happens the whole host will get a "connection timeout" and no item gets a new value.

This problem is reproducable also, if you have custom user parameters in your zabbix config. If one custom user parameter get's a problem (script hangs without a timeout), the whole queue mechanism stands still!

Can anyone agree with that?

Cheers brandy

[rob9988]

I just experienced this problem on our Zabbix 1.1 system. We rebooted a monitored server whose items included SNMP items. The processes monitored via SNMP did not start on the monitored server; at that point, our Zabbix server started reporting "Timeout while connecting to [hostname_changed_here]:SNMP_PORT_NUMBER_changed_here" errors.

I disabled all the SNMP items for the host, and the Zabbix server was immediately able to connect to the agent on the monitored server.

I didn't check to see if this is a known bug, but will do that now.

Hope this helps.

-Rob

[Nate Bell]

Unfortunately, I think this is a known bug and has been for a while (I've experienced this since 1.0). It's tricky to catch since you can't use Zabbix to monitor the queue if Zabbix isn't collecting new items.

I recently wrote a script to check Zabbix's queue to collect the information on the queue overview page (how many items are taking 5 sec, 30 sec, etc). I basically just translated the Zabbix php into bash. I then created a cronjob to run the script repeatedly, and to grep for the number of items in the queue that are taking 300+ seconds. If this number gets higher than 300, than I have the server alert me.

Here is the script:

#!/bin/bash
QUEUE=/tmp/zabbix-queue.log

mysql -e "select i.nextcheck from items i,hosts h where i.status=0 and i.type not in (2) and ((h.status=\".HOST_STATUS_MONITORED.\" and h.ava
ilable!=\".HOST_AVAILABLE_FALSE.\") or (h.status=\".HOST_STATUS_MONITORED.\" and h.available=\".HOST_AVAILABLE_FALSE.\" and h.disable_until<=
NOW())) and i.hostid=h.hostid and i.nextcheck<NOW() and i.key_ not in ('status','icmpping','icmppingsec','zabbix[log]') order by i.nextcheck"
 zabbix | grep -v nextcheck > $QUEUE

now=$(date +%s)

sec_5=0
sec_10=0
sec_30=0
sec_60=0
sec_300=0
sec_rest=0
exec < $QUEUE
read row
while [ "$row" != "" ]
do
        if [ $(echo "$[$(echo "$[$now-$row]")]") -le "5" ]
        then
                sec_5=$[sec_5+1]
        elif [ $(echo "$[$now-$row]") -le 10 ]
        then
               sec_10=$[sec_10+1]
        elif [ $(echo "$[$now-$row]") -le 30 ]
        then
                sec_305=$[sec_30+1]
        elif [ $(echo "$[$now-$row]") -le 60 ]
        then
                sec_60=$[sec_60+1]
        elif [ $(echo "$[$now-$row]") -le 300 ]
        then
                sec_300=$[sec_300+1]
        else
                sec_rest=$[sec_rest+1]
        fi
        read row
done
echo "Less than 5 seconds:"$sec_5
echo "Less than 10 seconds:"$sec_10
echo "Less than 30 seconds:"$sec_30
echo "Less than 60 seconds:"$sec_60
echo "Less than 300 seconds:"$sec_300
echo "Everything else:"$sec_rest

And here is the crontab:

[email protected]
# Check the Zabbix queue. If 300 or more items are taking longer than 300 seconds, then send a panic email
0,5,10,15,20,25,30,35,40,45,50,55 * * * * if [ $(/home/zabbix/scripts/queue.sh | grep "300 seconds" | cut -d":" -f2) -ge 300 ]; then echo "The Zabbix Queue is not moving" ; fi

I'm checking every 5 minutes, but this is probably overkill. Hope this is some help until the queue is improved.

Nate

[brandy]

@alexai: do you know anything about this issue?

thx

brandy

[accid]

Bump!

Im using server 1.4.4 and agents 1.4.6 and i just had the same problem. One host hast several application templates assigned and if one item check fails, all the other snmp items in those templates are ignored.

Is there a patch available, or a confirmed fixed server version for this issue?

br

[ataylo13]

I am having the same issue in 1.6.5. Has anyone found a patch/work around for this?