-
Incident report
-
Resolution: Duplicate
-
Critical
-
None
-
None
-
None
-
RHEL 6.4 amd64, Zabbix 2.0.6
originally written up on ServerFault: http://serverfault.com/q/533088/2101
—
We have a Zabbix environment where we are attempting to monitor systems on customer networks through proxies installed at each location. Many customer sites share the same IP range which seems to be a problem for Zabbix.
We're having an issue where monitored hosts are bouncing between proxies. When it's OK, the hosts look like:
![good config][1]
but for some reason, the server3.office.wolpertinger.com host at this site gets assigned to aardvark's proxy:
![bad config][2]
(this happens with a few different hosts, but I've chosen to focus on this particular one for the purpose of diagnosis)
The end result of this problem is that when the zabbix server builds the configurations for the proxies, it may not include all the necessary host information so that the proxy can properly monitor the agents.
For example, the server will fail to include information about server3.office.wolpertinger.com when sending to wolpertinger's proxy and then suddenly that server is marked as unreachable for an hour.
I've tried:
- Changing Device uniqueness criteria to 'IP address' (this was original config)
- Changing Device uniqueness criteria to 'system.uname'
- Disabling discovery action rules
all with no effect.
What do I need to do to fix this?
—
Discovery rule status for aardvark:
![aardvark discovery rule][3]
Monitoring page for discovery rule:
![aardvark discovery][4]
(you can see how zabbix is getting confused about which host it's seeing, despite the discovery rule being set to distinguish by system.uname)
—
Discovery rule status for wolpertinger:
![wolpertinger discovery rule][5]
Monitoring page for discovery rule:
![wolpertinger discovery][6]
—
Discovery action rules:
![discovery action rules][7]
—
The actual host configurations for the respective hosts are:
![wolpertinger server3][8]
and:
![aardvark server1][9]
—
At one point I realized that Windows doesn't use the FQDN in system.uname so I thought it might be the same across hosts:
server2.office.aardvark.com: Windows SERVER2 6.1.7601 Microsoft Windows 7 Professional Service Pack 1 x86
server3.office.ostrich.com: Windows SERVER3 6.1.7600 Microsoft Windows Server 2008 R2 Standard Edition x64
server2.office.ostrich.com: Windows SERVER2 6.1.7600 Microsoft Windows Server 2008 R2 Standard Edition x64
server3.office.wolpertinger.com: Windows SERVER3 6.1.7601 Microsoft Windows 7 Professional Service Pack 1 x64
server2.office.wolpertinger.com: Windows SERVER2 6.0.6002 Microsoft Windows Server 2008 Standard Edition Service Pack 2 x86
[1]: http://i.stack.imgur.com/b4E8n.png
[2]: http://i.stack.imgur.com/oiwnk.png
[3]: http://i.stack.imgur.com/oRwBG.png
[4]: http://i.stack.imgur.com/Tfgjo.png
[5]: http://i.stack.imgur.com/l2mTl.png
[6]: http://i.stack.imgur.com/ZbbjV.png
[7]: http://i.stack.imgur.com/ipkAt.png
[8]: http://i.stack.imgur.com/nByLV.png
[9]: http://i.stack.imgur.com/1hi13.png
- duplicates
-
ZBXNEXT-1267 discovery uniqueness and proxies
- Closed