file system monitoring not showing drive

[JKx2]

Hi All,

I've searched through forums and haven't found an answer, so I'm hoping someone here can help.

I am having issues with the low level discovery for the file system monitoring. It shows all of the disk except for one on the web page.

If I run 'zabbix_get -s xxx.xxx.xxx.xxx -p 10050 -k "vfs.fs.discovery"' from the monitoring server it detects the disk. (see screenshot zabbix1.jpg) The one that is not showing is boxed.

Also attached screen shot of what the web page is showing, it show disks /, /boot, /home, and /var

Montoring server OS is Centos 6 running zabbix 2.2.1 all agents are also running version 2.2.1 on CentOS 6.

Thanks in advance,
J

[aib]

Do you mind to check "Discovery rule" ?
Maybe you have some additional Filters, which select only first level of filesystems (/;/var;/home)

[JKx2]

Hi Aleksey,

Thanks for the reply.
I looked at the discovery rule and filter for the Macro is set to '{#FSTYPE}' and the regexp is '@File systems for discovery'

Thanks,
J

[bschmidt001]

Regex Perhaps

When looking at differences between the disk you are having issues with, and the rest of the disks, I noticed that the "9.3" included a period (.) which is used in regex patterns. Could you create / add a bogus disk, that has the period used as part of it, then see if it also fails?

[JKx2]

When looking at differences between the disk you are having issues with, and the rest of the disks, I noticed that the "9.3" included a period (.) which is used in regex patterns. Could you create / add a bogus disk, that has the period used as part of it, then see if it also fails?

Thanks for the suggestion, I think this it. I mounted the same filesystem under /mnt/pgsql93, and it got discovered accordingly.

So there must be something on the server-side web page display side that doesn't like the period '.' in the mount name.

The directory structure is created by the CentOS RPMs, so I would prefer not to change it. I will probably make the mount one level higher (at /var/lib/pgsql), or just keep the second mount as a permanent solution, though that is not the most elegant solution...

[sugraj1119]

File systems low level discovery issue

Dear Team, Kinldy help me to resolve low level discovery issue with file systems.
I have applied discovery for Solaris server which has 2.0.9 version by #FSTYPE filter but it didnt discover any file systems.
When i checked port 10050 is not enabled at host level but 10051 is enabled.

Whether discovery will depends on port 10050, if not how to resolve this issue.

Kindly assist

[eduard.gan]

Another problem

I have similiar issue.

My Zabbix 2.2.7 monitors multiple Windows hosts. Some of them are 2003SP2 and 2003R2x64, and some are 2008R2.

2008R2 works perfectly.

The problem is that the low level discovery did not detected filesystems completely on two hosts with 2003SP2 and 2003R2x64.

At the same time i have third host with 2003SP2 whose filesystems detected correctly without any problems as with 2008R2.

The configurations of agents are the same. In fact they directly copied from working third host with little correction of "Hostname" directive.

The versions of agents are almost the same:

2003SP2 with agent v2.2.1 - not working
2003R2x64 with agent v2.4.4 - not working
2003SP2 with agent v2.4.4 - works
2008R2 with agent v2.4.4 - works
2008R2 with agent v2.2.1 - works

Attaching the configuration of agents which are 99% identical on two hosts - 2003SP2 with agent v2.4.4(which works) and 2003R2x64 with agent v2.4.4 (which have not working low level discovery)zabbix_agentd.txt

Additionally i can do the:

zabbix_get -s 192.168.0.251 -k "vfs.fs.discovery"

and it returns some data:

{"data":[{"{#FSNAME}":"A:","{#FSTYPE}":"UNKNOWN"},{"{#FSNAME}":"C:","{#FSTYPE}":"NTFS"},{"{#FSNAME}":"D:","{#FSTYPE}":"NTFS"},{"{#FSNAME}":"E:","{#FSTYPE}":"NTFS"},{"{#FSNAME}":"F:","{#FSTYPE}":"NTFS"},{"{#FSNAME}":"G:","{#FSTYPE}":"NTFS"},{"{#FSNAME}":"I:","{#FSTYPE}":"NTFS"}]}

I can manually configure the data type and trigger and it works, but some reason not with low level discovery.

Also i see in logfiles of agent on failed server this, for every hour:

213764:20150805:115856.591 Requested [vfs.fs.discovery]
213752:20150805:115856.653 In collect_perfstat()
213752:20150805:115856.653 End of collect_perfstat()
213768:20150805:115856.669 In send_buffer() host:'192.168.0.247' port:10051 values:0/100
213768:20150805:115856.669 End of send_buffer():SUCCEED
213752:20150805:115857.653 In collect_perfstat()
213752:20150805:115857.653 End of collect_perfstat()
213768:20150805:115857.669 In send_buffer() host:'192.168.0.247' port:10051 values:0/100
213768:20150805:115857.669 End of send_buffer():SUCCEED
213752:20150805:115858.653 In collect_perfstat()
213752:20150805:115858.653 End of collect_perfstat()
213768:20150805:115858.669 In send_buffer() host:'192.168.0.247' port:10051 values:0/100
213768:20150805:115858.669 End of send_buffer():SUCCEED
213752:20150805:115859.653 In collect_perfstat()
213752:20150805:115859.653 End of collect_perfstat()
213768:20150805:115859.669 In send_buffer() host:'192.168.0.247' port:10051 values:0/100
213768:20150805:115859.669 End of send_buffer():SUCCEED
213752:20150805:115900.653 In collect_perfstat()
213752:20150805:115900.653 End of collect_perfstat()
213768:20150805:115900.669 In send_buffer() host:'192.168.0.247' port:10051 values:0/100
213768:20150805:115900.669 End of send_buffer():SUCCEED
213752:20150805:115901.653 In collect_perfstat()
213752:20150805:115901.653 End of collect_perfstat()
213768:20150805:115901.669 In send_buffer() host:'192.168.0.247' port:10051 values:0/100
213768:20150805:115901.669 End of send_buffer():SUCCEED
213764:20150805:115902.153 Sending back [{"data":[{"{#FSNAME}":"A:","{#FSTYPE}":"UNKNOWN"},{"{#FSNAME}":"C:","{#FSTYPE}":"NTFS"},{"{#FSNAME}":"D:","{#FSTYPE}":"NTFS"},{"{#FSNAME}":"E:","{#FSTYPE}":"NTFS"},{"{#FSNAME}":"F:","{#FSTYPE}":"NTFS"},{"{#FSNAME}":"G:","{#FSTYPE}":"NTFS"},{"{#FSNAME}":"I:","{#FSTYPE}":"NTFS"}]}]
213752:20150805:115902.653 In collect_perfstat()
213752:20150805:115902.653 End of collect_perfstat()
213768:20150805:115902.669 In send_buffer() host:'192.168.0.247' port:10051 values:0/100
213768:20150805:115902.669 End of send_buffer():SUCCEED
213752:20150805:115903.653 In collect_perfstat()
213752:20150805:115903.653 End of collect_perfstat()

Any feedback is appreciated. Thanks.

[eduard.gan]

I've made a little research and solved this problem.

The root cause of problem was a presence in system of a floppy-drive

It increases a time that agent waits for data in his poll for mounted filesystems, аnd subsequently it sends data to server with a little longer response time allowed by default value of timeout for agent answers in configuration files of zabbix-server and zabbix-agent.

From the agent side you can't see the problem. In logfile you just see that agent receives the request, and sends data back. Nothing bad hapesns.

213764:20150805:115856.591 Requested [vfs.fs.discovery]
213764:20150805:115902.153 Sending back [{"data":[{"{#FSNAME}":"A:","{#FSTYPE}":"UNKNOWN"},{"{#FSNAME}":"C:","{#FSTYPE}":"NTFS"},{"{#FSNAME}":"D:","{#FSTYPE}":"NTFS"},{"{#FSNAME}":"E:","{#FSTYPE}":"NTFS"},{"{#FSNAME}":"F:","{#FSTYPE}":"NTFS"},{"{#FSNAME}":"G:","{#FSTYPE}":"NTFS"},{"{#FSNAME}":"I:","{#FSTYPE}":"NTFS"}]}]

But from server side server logfile will contain at least absolutely misleading warnings about fail of request that claims that you have some problem with your network, which you obviously haven't in this case.

1386:20120829:180144.032 Zabbix agent item [vfs.fs.discovery] on host [host] failed: another network error, wait for 15 seconds

In the worst case you even may get your agent blocked due "network problems" if the request time you configured for failing request is pretty small. For example you may be set the 30s interval for discovery requests in your zabbix frontend.

There is special directive called "Timeout=". I've increased the value to 10 and autodetection of filesystems perfectly worked for the rest of the servers.

Although better solution according to developers which say that increase of timeout is "it is absolutely not recommended solution" is just throw out a floppy and it's driver from the system, which i think is reasonable because it's just a piece of buggy old trash on any server in USB/CD/DVD era.

For additional info about this wired situation see the

https://support.zabbix.com/browse/ZBXNEXT-1395

One question is for developers - could you please make the debugging messages in logfile more informative and less misleading? Obviously this case showed us that response timeout errors should be called the "response timeout errors" and not the "another network error". There's a broken logic here. Anyway guys your product is awesome. Long live zabbix!