Trigger Difficulties (V1.3.3)

[azymux]

I have done a lot of searching on these forums and Google and didn't have much luck with this problem. Everywhere below that you see "hostname" was replaced with the correct hostname (they do all match, I made sure of that first ).

There are two issues that I am having. I have 6 servers in my host configuration and they are all displaying these same issues so I am certain that the problem is in the server config somewhere.

It is repeatedly triggering "Server hostname is unreachable", but they are still receiving data on a regular basis from the same server. Below is from the agent log on an "unreachable" server:

  8078:20070320:032921 Connection from [hostname] accepted. Allowed servers [hostname]
  8078:20070320:032921 Requested [vfs.fs.size[/,free]]
  8078:20070320:032921 Sending back [5855840]

The other issue that I am having is from the file integrity checks. Every server in my list is showing all the file integrity triggers as active. It appears to flop back and forth pretty often, even when a file hasn't actually changed. An example of one from the same server is:

ALARMS: "/etc/services has been changed on server hostname"
hostname:vfs.file.cksum[/etc/services].diff(0)>0
2007.Mar.20 00:51:02 TRUE - 2.7 hours 2.7 hours 100% 
2007.Mar.20 00:41:02 FALSE - 10 mins 10 mins 5.82% 
2007.Mar.20 00:21:02 TRUE - 20 mins 3 hours 94.78% 
2007.Mar.20 00:01:02 FALSE - 20 mins 30 mins 14.17%

When I check the file on the server:

-rw-r--r-- 1 root root 17814 2007-03-18 07:24 /etc/services

Thanks!

[bobster]

Also getting false triggering "host unreachable"

While the origin of my problem is probably not identical to the above, I suspect it is similiar.

We are getting dozens and dozens of false "Host is unreachable" errors.

I suspect one of the symptoms is that a key I created which contained the substring of "status" within it now TRIGGERS (activates) as if its the Host status's version of 'status'. In other words whenever this particular snmp v1 item named "app.service.status" happens to cycle or change state, it actually interferes somehow via either bad parsing or pattern matching within Zabbix and causes the trigger associated with the item host "status" to fire.
Even changing the latter item to app.service.status1 has not seemed to help. Not good.

There are other unexplainable false triggering issues that crop up as well as the undesired 'propagation' of certain Items from templates out into groups in which the template in which the original Item - was not even accessible.
Have no idea how this happens, although maybe its another variation on the previously mentioned problem.

These, along with a time-out issue on the front-end which some users are forced to shut down every instance of the browser in which they logged in before they can get in again - regrettably has left my peers with some serious reservations about the application.

Otherwise the overall impression of Zabbix had been pretty high.

[bobster]

amendment to previous post regarding "false triggering"

In the interest of accuracy I should have noted that the version of Zabbix to which the previous post referred was 1.6.1 Sorry for posting in wrong area.

I see however, that Beta 1.3.5 version - a bug correction list referred to:
"fixed dependencies of deleted elements for actions"
"fixed trigger dependencies for templated triggers"
"fixed trigger overview status"

and may well refer to solutions the problems I described.

[Alexei]

Thanks for reporting this anyway. We will retest the cksum carefully before release of 1.4.