Discovery no longer working in 1.8?

[r0k5t4r]

Hi,

i recently upgraded my zabbix installation to 1.8 and noticed that the discovery doesn't start anymore. Looking at the logs it shows nothing suspicious. I believed it was a problem of the upgrade and did a completely fresh install including OS (Ubuntu 9.10). But here it is the same. Even the preconfigured discovery doesn't start.

[frankcheong]

me two.I just thought it is my own problem, but it seems like it isn't, right?

[krzychu]

I'm using zabbix 1.8 for few days now. I do not have any problems with discovery.

[frankcheong]

I am following the 1.8 documentation to create discovery as well as the action rule so as to bind to different server group (linux, freebsd as well as window) automatically based on the system.uname. What is yours then? Can you post your rule here for our reference?

[danrog]

My 2 cents...

I've had problems too with a fresh 1.8 install. I have two types of rules: Simple port discovery and Agent discovery. I noticed if I disable the simple port discovery rules, my agent discovery rules work fine. As soon as I re-enable the simple port discovery rules the agent rules no longer seem to work. I also noticed I had to restart the server after disabling the simple rules before the agent rules (and actions) began to work. With the simple check rules and debugging enabled, I only saw the simple check rules in the logs (and they seemed to be firing every 10 seconds, much faster then what I have configued). I haven't opened a bug yet or searched for one, has anyone else found one yet?

[krzychu]

OK...

I did 2 things to get discovery working:

1. Created a discovery rule
2. Created an action rule linked with discovery rule created under 1.

Critical points:
Ad 1. For "New Check" I use "Zabbix agent" from the pull down menu, then I write "system.uname" in the text field, then click on the "add" button.
Ad 2. For "Action conditions" I use "Discovery rule" from the pull down menu, then I select the discovery rule created under 1.

I hope this helps...

[frankcheong]

I have followed your instruction as below:-

Create discovery rule with name="rule1", ip range=192.168.1.0/24 checks=Zabbix agent (system.uname).
And then create an action with condition below:-
Discovery rule="rule1"
Service Type="zabbix agent"
Discovery Status="up"
uptime/downtime=3600
Received value="FreeBSD"
and Operation below:-
Add Host
Enable Host
Send message to admin
Add to group "FreeBSD Servers"
Link to template "template_FreeBSD"

But it didn't work either. Have also tried to delete the first three operation "Add Host, Enable Host, Send message to admin" but it didn't work either. What went wrong here?

[krzychu]

If I could answer questions like that, probably I would been the reachest man on this planet ; )

Sorry...

[frankcheong]

Haha, you are really funny. OK, do you mind your posting the remaining discovery rule and action detail for my comparison?

One more thing, does your Zabbix server/proxy stays within the same subnet as those discovered machines?

[krzychu]

sure... I was to lazy to do it last time ; )...

Discovery rule:

Name: ANAME
Discovery by proxy: noproxy
IP range: ANIPRANGE (like 192.168.1.10-15)
Delay (seconds): 3600
Checks Zabbix agent "system.uname"
Device uniqueness criteria : IP address
Status: Active

Action:
Name: ANOTHERNAME
Event source: Discovery
Default subject : {TRIGGER.NAME}: {STATUS}
Default message: {TRIGGER.NAME}: {STATUS}
Status: Enabled
Action conditions:
Conditions (A) Discovery rule = "ANAME"
Action operations:
Add host
Enable host
Add to group "AGROUP"
Linkt to template "ATEMPLATE"

Server and Agent are on different Subnets, but communication has been allowed on ports 10050 and 10051.

If you for example are not sure if your Server can connect to your Agent, try "telnet AgentIP 10050" on you Server.

: )

[frankcheong]

In that case, you bind all discovered server to the same group. So how can you group them to different server group based on the system.uname? Isn't it the way it should be so that I can group them based on the system.uname or why should I grep this value?

[krzychu]

I do group them by the specified IPRANGE. How it is meant to be, dont know ; )

[frankcheong]

IN that case, I should have group all server with same OS within a specify range so that I can create minimal rules to perform all the discovery. But in reality, it would not be possible especially when a lot of server is already in production. Don't even mention that the one who allocate IP is not the one who do the server maintenance.

Anyway, thx for your help. But I think it is a bug instead, anyone second my thought?

[krzychu]

I admit, its possible only because our network environment is well organized.

[frankcheong]

Finally I found the place that might cause the problem after turning on the debugging and viewing the 60MB size log file. The problem


19467:20100107:101043.156 In discover_service()
19467:20100107:101043.156 In get_value_agent() host:'' addr:'192.168.1.123' key:'system.uname'
19467:20100107:101043.163 Sending [system.uname
]
19467:20100107:101043.188 Get value from agent result: 'FreeBSD server.domain.com 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #0: Thu Oct 15 12:21:31 HKT 2009 [email protected]:/usr/obj/usr/src/sys/GENERIC i386'
19467:20100107:101043.188 End of discover_service():SUCCEED


It seems like the value of system.uname is the result of the command "uname -a" instead of a simple "uname" which result in a very long string with hostname and datetime of the kernel. With that I have changed the action condition of Received value = "FreeBSD" to Received value LIKE "FreeBSD" and it works.

Guess that the documentation will have to be revised or it will cause a lot of discussion over this forum. Or the system.uname actually relabel it as system.uname -a or even change it as a real system.uname with save a lot of effort.