[ZBXNEXT-3368] vfs.fs.discovery: Discover devices (not only mountpoint and filesystems) Created: 2016 Aug 08  Updated: 2016 Aug 16  Resolved: 2016 Aug 16

Status: Closed
Project: ZABBIX FEATURE REQUESTS
Component/s: Agent (G)
Affects Version/s: 3.2.0alpha2
Fix Version/s: None

Type: Change Request Priority: Minor
Reporter: Alexis "Horgix" Chotard Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: agent, items, patch
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux. The improvement could be made pour other operating systems, but this issue only provide details for Linux systems (tested on CentOS 7).

Attachments: Text File zabbix_device_discovery_diff.txt     Text File zabbix_discovery_output.txt    
Issue Links:
Duplicate
duplicates ZBXNEXT-1302 Make vfs.dev.read/vfs.dev.write disco... Closed

 Description   

Hi,

Currently, the vfs.fs.discovery on Linux only discovers FSNAME (mountpoints) and FSTYPE (filesystems). It does so by parsing the /proc/mounts file, which provides a bit more infos (https://www.centos.org/docs/5/html/5.2/Deployment_Guide/s2-proc-mounts.html) than these 2.

Actually, some items like vfs.fs.read or vfs.fs.write require a device name (and not a mountpoint) to work, so it would be nice if the vfs.fs.discovery item would discover the devices besides their mountpoints and filesystems. People I'm working with are currently using a perl script to discover devices to be used for vfs.fs.read/write since the "native" vfs.fs.discovery doesn't provide it. I definitively think it would be cleaner and would benefit to other people to have the devices discovered and made available through vfs.fs.discovery.

I took the opportunity to implement and test it for Linux, see the patch below.

I worked on trunk, on the git mirror of the SVN repository. My work as been done from the following commit :

commit 37b978f9ce53ee8b693a1c7dd6b24a6a5afca170
Author: wiper <wiper@f4e7fd02-d210-4e34-a1e0-d4093fb66cc2>
Date:   Tue Jul 19 07:27:08 2016 +0000

    ..F.....S. [ZBXNEXT-3277] added global event correlation rule processing


    git-svn-id: svn://svn.zabbix.com/trunk@61100 f4e7fd02-d210-4e34-a1e0-d4093fb66cc2

The patch itself :

diff --git a/src/libs/zbxsysinfo/linux/diskspace.c b/src/libs/zbxsysinfo/linux/diskspace.c
index e6bb828..b8388ed 100644
--- a/src/libs/zbxsysinfo/linux/diskspace.c
+++ b/src/libs/zbxsysinfo/linux/diskspace.c
@@ -121,7 +121,7 @@ int	VFS_FS_SIZE(AGENT_REQUEST *request, AGENT_RESULT *result)
 
 int	VFS_FS_DISCOVERY(AGENT_REQUEST *request, AGENT_RESULT *result)
 {
-	char		line[MAX_STRING_LEN], *p, *mpoint, *mtype;
+	char		line[MAX_STRING_LEN], *p, *mpoint, *mtype, *mdev;
 	FILE		*f;
 	struct zbx_json	j;
 
@@ -137,9 +137,13 @@ int	VFS_FS_DISCOVERY(AGENT_REQUEST *request, AGENT_RESULT *result)
 
 	while (NULL != fgets(line, sizeof(line), f))
 	{
+		mdev = line;
+
 		if (NULL == (p = strchr(line, ' ')))
 			continue;
 
+		*p = '\0';
+
 		mpoint = ++p;
 
 		if (NULL == (p = strchr(mpoint, ' ')))
@@ -155,6 +159,7 @@ int	VFS_FS_DISCOVERY(AGENT_REQUEST *request, AGENT_RESULT *result)
 		*p = '\0';
 
 		zbx_json_addobject(&j, NULL);
+		zbx_json_addstring(&j, "{#FSDEV}", mdev, ZBX_JSON_TYPE_STRING);
 		zbx_json_addstring(&j, "{#FSNAME}", mpoint, ZBX_JSON_TYPE_STRING);
 		zbx_json_addstring(&j, "{#FSTYPE}", mtype, ZBX_JSON_TYPE_STRING);
 		zbx_json_close(&j);

The output confirming that it's working as intended :

$ zabbix_get -s localhost -k vfs.fs.discovery  | python -m json.tool {
    "data": [
        ...
        {
            "{#FSDEV}": "/dev/mapper/centos-root",
            "{#FSNAME}": "/",
            "{#FSTYPE}": "xfs"
        },
        ...
    ]
}

Now the final question is : is it possible to merge this into Zabbix ?

If that sounds ok for you, how would I go into merging this into Zabbix ?

 Comments   
Comment by Alexis "Horgix" Chotard [ 2016 Aug 08 ]

Looks like Jira didn't keep the formatting for the diff and output.
See attached files for readable, indented versions.

Comment by Alexis "Horgix" Chotard [ 2016 Aug 08 ]

Thanks asaveljevs for the formatting edit !
Could you split the second block in two around "The output confirming that it's working as intended :" ? I can't edit my issue

Comment by Aleksandrs Saveljevs [ 2016 Aug 08 ]

Formatting fixed. Sorry, did not notice that line the first time.

Comment by Aleksandrs Saveljevs [ 2016 Aug 16 ]

Alexis, do you really need device discovery for the purposes of "vfs.fs.discovery" or maybe ZBXNEXT-1302 or ZBXNEXT-2093 would be more appropriate?

Comment by Alexis "Horgix" Chotard [ 2016 Aug 16 ]

asaveljevs : well, ZBXNEXT-2093 is the solution I'm trying to avoid, and is closed as duplicate of ZBXNEXT-1302.

And for ZBXNEXT-1302 : the feature request is indeed the same; if you compare my diff/patch and the one given in ZBXNEXT-1302, they're almost the same; but mine is up-to-date with current trunk while ZBXNEXT-1302 one is 2 years late now.

Comment by Alexis "Horgix" Chotard [ 2016 Aug 16 ]

asaveljevs : also, I believe this issue is far more detailed and clear than ZBXNEXT-1302. And I'm kind of surprised that ZBXNEXT-1302 have not been merged for 2 years; any reason for that ?

Comment by Aleksandrs Saveljevs [ 2016 Aug 16 ]

And I'm kind of surprised that ZBXNEXT-1302 have not been merged for 2 years; any reason for that ?

One of the reasons might be explained in this comment by alexei and maybe ZBXNEXT-3236.

Another reason could be that in order to do ZBXNEXT-1302 properly, it should be done for every platform supported by vfs.dev.read[] and vfs.dev.write[] (see https://www.zabbix.com/documentation/3.0/manual/appendix/items/supported_by_platform), but the patch adds it for Linux only and for vfs.fs.discovery, which I am not sure is the right place for it. If, however, it turns out that vfs.fs.discovery is the right item to add this to, then the number of platforms device discovery has to be supported on is even bigger.

Comment by Aleksandrs Saveljevs [ 2016 Aug 16 ]

Since this feature request is essentially the same as ZBXNEXT-1302, let's close it as a duplicate. The patch in this ticket is based on a newer version of Zabbix and, admittedly, the ticket description is very nice and detailed and sets a nice standard for everybody to follow, but tickets on this tracker are not exactly the same as pull requests on GitHub, unfortunately.

Comment by Alexis "Horgix" Chotard [ 2016 Aug 16 ]

asaveljevs : it's fine, it doesn't bother me that it's closed as duplicate as long as the feature ends up in Zabbix somehow I'll just add a comment on ZBXNEXT-1302 referencing this issue for an up-to-date patch and details, if you don't mind.

About vfs.dev.read/write : I don't really see why it would be there instead of vfs.fs.discovery since, from my understanding, it is vfs.fs.discovery which is responsible for discovering devices themselves (which, once discovered, can then be passed to vfs.dev.read/write for more informations about them).
vfs.fs.discovery already parses /proc/mounts to do so, so adding the device itself is just a matter of retrieving information in an already parsed file (as it can be seen in the 5 lines patch).

For the supported platforms, I'm ready to implement and test it on OpenBSD, FreeBSD and Windows if that's needed, and it's already tested on Linux; however I'll not be able to do it for other platforms.

Comment by Aleksandrs Saveljevs [ 2016 Aug 16 ]

Sure, feel free to add a comment to ZBXNEXT-1302.

One reason I am not sure that vfs.fs.discovery is the right place for discovering devices is that it results in duplicate output for devices. For instance, applying your patch and grepping for {#FSDEV} results in the following on my workstation:

$ cat output.json | python -mjson.tool | grep FSDEV | sort
            "{#FSDEV}": "192.168.1.2:/srv/nfs",
            "{#FSDEV}": "binfmt_misc",
            "{#FSDEV}": "cgroup",
            "{#FSDEV}": "cgroup",
            "{#FSDEV}": "cgroup",
            "{#FSDEV}": "cgroup",
            "{#FSDEV}": "cgroup",
            "{#FSDEV}": "cgroup",
            "{#FSDEV}": "cgroup",
            "{#FSDEV}": "cgroup",
            "{#FSDEV}": "debugfs",
            "{#FSDEV}": "devpts",
            "{#FSDEV}": "/dev/sda1",
            "{#FSDEV}": "/dev/sda2",
            "{#FSDEV}": "fusectl",
            "{#FSDEV}": "hugetlbfs",
            "{#FSDEV}": "mqueue",
            "{#FSDEV}": "proc",
            "{#FSDEV}": "pstore",
            "{#FSDEV}": "rootfs",
            "{#FSDEV}": "rpc_pipefs",
            "{#FSDEV}": "securityfs",
            "{#FSDEV}": "sysfs",
            "{#FSDEV}": "systemd-1",
            "{#FSDEV}": "tmpfs",
            "{#FSDEV}": "tmpfs",
            "{#FSDEV}": "tmpfs",
            "{#FSDEV}": "tmpfs",
            "{#FSDEV}": "tmpfs",
            "{#FSDEV}": "udev",

At a minimum, a proper discovery rule should not give duplicate results. Also, "tmpfs" and "proc" do not look like devices that can be monitored with vfs.dev.read[] and vfs.dev.write[].

So having a separate discovery item like vfs.dev.discovery might be more appropriate.

Comment by richlv [ 2016 Aug 16 ]

a separate discovery item would be much desired, as those devices aren't filesystems either.
and while i'm nitpicking, vfs.dev.discovery might not be the best fit, maybe something like system.blockdev.discovery =)

Generated at Tue May 13 10:43:38 EEST 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.