Solaris 10 - vfs.fs.discovery Problem

[solzab]

Hello all,

Having an issue with filesystem discovery on Solaris 10. I have a mix of Solaris 10 clients, both x86 and sparc from update 4 through update 9 and one Linux 2.6 client.

I'm using the pre-compiled 2.0.0 agents. I'm using the v2.0.2rc2 server because I'm also having issues with my Solaris compiled agents crashing, and decided to try the latest version; which didn't fix my compile problem, hence the pre-comp binaries

Server and front end work fine, no issues compiling and vfs.fs.discovery works ok on the Linux client.

Running the following on the Solaris clients (as the agent user) also works:

zabbix_agentd -p
zabbix_agentd -t vfs.fs.discovery
zabbix_agentd -t vfs.fs.size[/,free]
zabbix_agentd -t vfs.fs.size[/,available]

Debug level 4 on the client side shows the discovery is being run:

 26520:20120731:103458.463 Requested [vfs.fs.discovery]
 26520:20120731:103458.463 Sending back [{
        "data":[
                {
                        "{#FSNAME}":"\/",
                        "{#FSTYPE}":"zfs"},

      - - - snip - - -

                       "{#FSTYPE}":"lofs"}]}]

Note: above output pruned a little (ie: snip).

Debug level 4 on the server shows the following:

 15213:20120731:123105.618 In get_value_agent() host:'myhost' addr:'myhost' key:'system.localtime'
 15216:20120731:123105.618 get value from agent result: '{
        "data":[
                {
                        "{#FSNAME}":"\/",
                        "{#FSTYPE}":"zfs"},

           - - - snip - - -

                        "{#FSTYPE}":"autofs"}]}'
 15216:20120731:123105.618 End of get_value():SUCCEED

Those log entries aren't exactly matched up, but you get the idea. The issue is these fs items aren't showing up in the host config.

The net.if.discovery is working fine

Anyone point me in the right direction, kinda at a loss here. Perhaps I should revert to using the v2.0.0 server?

[solzab]

Ah, bogus, didn't scroll down enough in the server log.

I disabled the discovery, changed the interval to 60 seconds and re-enabled it. Found this pop up in the server log:

 15217:20120731:132739.748 DBlld_process_discovery_rule() f_macro:'{#FSTYPE}' f_regexp:'@File systems for discovery'
 15217:20120731:132739.748 In DBlld_update_items()
 15217:20120731:132739.748 query [txnlev:1] [select i.itemid,i.name,i.key_,i.type,i.v
alue_type,i.data_type,i.delay,i.delay_flex,i.history,i.trends,i.status,i.trapper_host
s,i.units,i.multiplier,i.delta,i.formula,i.logtimefmt,i.valuemapid,i.params,i.ipmi_se
nsor,i.snmp_community,i.snmp_oid,i.port,i.snmpv3_securityname,i.snmpv3_securitylevel,
i.snmpv3_authpassphrase,i.snmpv3_privpassphrase,i.authtype,i.username,i.password,i.pu
blickey,i.privatekey,i.description,i.interfaceid from items i,item_discovery id where
 i.itemid=id.itemid and id.parent_itemid=23379]
 15217:20120731:132739.748 In DBlld_check_record() jp_row:'{"{#FSNAME}":"\/","{#FSTYP
E}":"zfs"}'
 15217:20120731:132739.748 End of DBlld_check_record():FAIL

So now I have something to look at. I'll post back if I find a solution. Not entirely sure why this part of the process works differently between the Solaris and Linux clients

I'm also not sure if the FAIL above is because the item doesn't exist, which it obviously doesn't, but then... why doesn't it get created? Duh.

I am not cloning anything, I create a new host and applying the stock Solaris template.

[tchjts1]

I don't believe the issue is the version of Zabbix, or using the pre-compiled agents. I am also using 2.0.2rc2 along with the 2.0 pre-comps. using discovery of the fs is populating items into the host config on my setup with Solaris10 clients.

If you feel it might be the Zabbix version anyway, I see they released 2.0.2 stable today... you could try that and see if it helps.

maybe see here also: http://www.zabbix.com/forum/showthread.php?t=26681

[solzab]

WAAAAAA!

Your powers of search are greater than mine! Worked like a charm! Thank you sir.

But... why no loves for the zfs? Or anything other that ext3 for that matter.

[solzab]

Oh, wait, nevermind... I was looking at the test string in the db, not the regex. Fixed in the proper location now.