[ZBXNEXT-1455] vfs.fs.discovery on Windows, additional macro Created: 2012 Oct 05 Updated: 2012 Oct 05 Resolved: 2012 Oct 05 |
|
Status: | Closed |
Project: | ZABBIX FEATURE REQUESTS |
Component/s: | Agent (G) |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | Change Request | Priority: | Minor |
Reporter: | Joel Reed | Assignee: | Unassigned |
Resolution: | Duplicate | Votes: | 0 |
Labels: | vfs.fs.discovery, windows, zabbix_agentd | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified | ||
Environment: |
Windows 2008R2 |
Issue Links: |
|
Description |
I would like to see an additional macro added to the vfs.fs.discovery key on Windows. Currently vfs.fs.discovery returns 2 macros, #FSNAME and #FSTYPE. However currently #FSNAME returns the C drive as C:\. Hence the #FSNAME macro works great for the other vfs.* keys. But most Windows based things expect the C drive as C: (no ). For instance the perf counter paths per drive (via perf_counter, i.e. perf_counter["\LogicalDisk(C:)\Avg. Disk Read Queue Length",5]) expect the disk value to be in <letter>:. WMI also keys off of the <letter>: style (see class Win32_LogicalDisk property DeviceID). I understand that C:\ is the "root" of the filesystem and vfs.fs.discovery is inherently for the file system. It would be nice if the vfs.fs.discovery key also returned a #FSLETTER macro. This would preserve #FSNAME in its present form and not break existing configs. For example: { ", "{#FSLETTER}":"A:", "{#FSTYPE}":"UNKNOWN"}, { "{#FSNAME} ":"C: "{#FSTYPE}":"NTFS"}, { "{#FSNAME}":"D: ", "{#FSLETTER} ":"D:", { "{#FSNAME}":"E: ", "{#FSLETTER}":"E:", "{#FSTYPE} ":"UNKNOWN"}]} This would allow greater use (re-use) of that discovery. As of now the only work around I have found is to create my own discovery script that returns <letter>: format. This is unfortunately redundant especially when it is so tantalizingly close with vfs.fs.discovery. |
Comments |
Comment by Joel Reed [ 2012 Oct 05 ] |
Jumped the gun. Should have dug a little deeper. This issue appears to have been included in https://support.zabbix.com/browse/ZBX-5094, part of 2.01. This should be resolve. Thanks. |