ZABBIX FEATURE REQUESTS

Hardware details monitoring by Zabbix Agent

Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.0.0
  • Fix Version/s: 1.9.5 (alpha)
  • Component/s: Agent (G)
  • Labels:
    None
  • Zabbix ID:
    NA

Description

Zabbix Agent should be extended to support native collection of profile-related data, at least:

Hostname
OS (Name, short and full details)
Software (list of installed packages)
MAC Addresses (comma delimited)
CPU info
HW Architecture
Device Hardware (list of PCI devices)
Device Chassis (if available)
Device Vendor (if available)
Device Model (if available)
Device Serial number (if available)

Initially should be supported by Linux Agent. Other operating systems will be supported in the future.

Activity

Hide
richlv added a comment -

also listed as item 4 at ZBXNEXT-647

Show
richlv added a comment - also listed as item 4 at ZBXNEXT-647
Hide
richlv added a comment -

i'm not sure about the "host" and "host.device" keys. maybe it would make sense to split these up in hw/sw parts and make naming a bit more descriptive (as well as extendable) ?

something like system.hw.serial or system.hw.sn, then we'd get system.sw.os[short] etc.

at which point do we make additional narrowing down part of the key and when is it a parameter ?
as in system.cpu.load vs (current) host.device[serial] ?

Show
richlv added a comment - i'm not sure about the "host" and "host.device" keys. maybe it would make sense to split these up in hw/sw parts and make naming a bit more descriptive (as well as extendable) ? something like system.hw.serial or system.hw.sn, then we'd get system.sw.os[short] etc. at which point do we make additional narrowing down part of the key and when is it a parameter ? as in system.cpu.load vs (current) host.device[serial] ?
Hide
Alexander Vladishev added a comment - - edited

system.cpu.info => system.hw.cpu[cpunum,<vendor|model|curspeed|maxspeed>]
host.arch => system.sw.arch
host.device[type|vendor|chassis|model] => system.hw.chassis[type|vendor|model|serial]
host.lspci => system.hw.devices[pci|usb]
host.macs => system.hw.macaddr[all|<device>]
host.name => already supported system.hostname, remove
host.os[full|short|...] => system.sw.os[...] + partially supported system.uname
host.packages => system.sw.packages

Show
Alexander Vladishev added a comment - - edited system.cpu.info => system.hw.cpu[cpunum,<vendor|model|curspeed|maxspeed>] host.arch => system.sw.arch host.device[type|vendor|chassis|model] => system.hw.chassis[type|vendor|model|serial] host.lspci => system.hw.devices[pci|usb] host.macs => system.hw.macaddr[all|<device>] host.name => already supported system.hostname, remove host.os[full|short|...] => system.sw.os[...] + partially supported system.uname host.packages => system.sw.packages
Hide
richlv added a comment - - edited

if using lspci... plain lspci ? -v ? -mm ? -t ? -tv ? -k ?

maybe allow manually specifying lspci params ?
<rudolfs> the key system.hw.devices accepts 'usb' or 'pci' as an argument, calling lsusb or lspci. since they do not have the same flags, none are specified

<richlv> maybe we shouldn't mix lsusb & lsbpci in the same item key then ? wouldn't that limit us later if we add support for other buses ?
<rudolfs> reviewer, please discuss the specifications with feature owner

Show
richlv added a comment - - edited if using lspci... plain lspci ? -v ? -mm ? -t ? -tv ? -k ? maybe allow manually specifying lspci params ? <rudolfs> the key system.hw.devices accepts 'usb' or 'pci' as an argument, calling lsusb or lspci. since they do not have the same flags, none are specified <richlv> maybe we shouldn't mix lsusb & lsbpci in the same item key then ? wouldn't that limit us later if we add support for other buses ? <rudolfs> reviewer, please discuss the specifications with feature owner
Hide
Rudolfs Kreicbergs added a comment - - edited

1) Added items:
system.hw.chassis[full|type|vendor|model|serial] - default is [full], root permissions needed
system.hw.cpu[all|cpunum,full|maxfreq|vendor|model|curfreq] - default is [all,full]
system.hw.devices[pci|usb] - default is [pci]
system.hw.macaddr[interface,short|full] - default is [all,full], interface is regex
system.sw.arch
system.sw.os[name|short|full] - default is [name]
system.sw.packages[package,manager,short|full] - default is [all,all,full], package is regex

Show
Rudolfs Kreicbergs added a comment - - edited 1) Added items: system.hw.chassis[full|type|vendor|model|serial] - default is [full], root permissions needed system.hw.cpu[all|cpunum,full|maxfreq|vendor|model|curfreq] - default is [all,full] system.hw.devices[pci|usb] - default is [pci] system.hw.macaddr[interface,short|full] - default is [all,full], interface is regex system.sw.arch system.sw.os[name|short|full] - default is [name] system.sw.packages[package,manager,short|full] - default is [all,all,full], package is regex
Hide
Rudolfs Kreicbergs added a comment -

Available in dev branch: svn://svn.zabbix.com/branches/dev/ZBXNEXT-677

Show
Rudolfs Kreicbergs added a comment - Available in dev branch: svn://svn.zabbix.com/branches/dev/ZBXNEXT-677
Hide
richlv added a comment - - edited

these should also be documented at :

http://www.zabbix.com/documentation/2.0/manual/appendix/items/supported_by_platform
http://www.zabbix.com/documentation/2.0/manual/appendix/items/agent_items

it should include info on what is done to retrieve information, like running lspci, lsusb etc. for those which are read from /dev/mem, it would require running agent as root, right ?
<rudolfs> all documentation will be done after the final changes are accepted

Show
richlv added a comment - - edited these should also be documented at : http://www.zabbix.com/documentation/2.0/manual/appendix/items/supported_by_platform http://www.zabbix.com/documentation/2.0/manual/appendix/items/agent_items it should include info on what is done to retrieve information, like running lspci, lsusb etc. for those which are read from /dev/mem, it would require running agent as root, right ? <rudolfs> all documentation will be done after the final changes are accepted
Hide
richlv added a comment -

package list gathering :

as far as i can figure out, currently dpkg installed package list is read from a file. would be useful to support other approaches :

1. rpm systems - "rpm -qa" will give back a list. by default format is :
sed-4.2.1-2.1.i586
it can be customised with parameters.

2. on slackware, "ls /var/log/packages/" will give a list of installed packages. example :
zabbix-1.9.4-i386-1

but on slackware one can also run rpm and install packages using it, so detecting rpm and running with it would not be desirable...

Show
richlv added a comment - package list gathering : as far as i can figure out, currently dpkg installed package list is read from a file. would be useful to support other approaches : 1. rpm systems - "rpm -qa" will give back a list. by default format is : sed-4.2.1-2.1.i586 it can be customised with parameters. 2. on slackware, "ls /var/log/packages/" will give a list of installed packages. example : zabbix-1.9.4-i386-1 but on slackware one can also run rpm and install packages using it, so detecting rpm and running with it would not be desirable...
Hide
richlv added a comment -

zalex, thanks for the info, although i guess another zbxnext will handle that. is the directory readable by non-root users ?

Show
richlv added a comment - zalex, thanks for the info, although i guess another zbxnext will handle that. is the directory readable by non-root users ?
Hide
richlv added a comment - - edited

(B12)

there seems to be some overly aggressive caching of positive (non-empty) results when requesting package list. consider the following exchange on a freshly started agent :

  1. zabbix_get -s localhost -p 11050 -k system.sw.packages[packageszzqededqedqedzz,showpms]
  1. zabbix_get -s localhost -p 11050 -k system.sw.packages[package,showpms]
  1. zabbix_get -s localhost -p 11050 -k system.sw.packages[age,showpms]
    [pkgtools] damageproto-1.2.1-noarch-1, [pkgtools] imagemagick-6.6.6_10-i486-1, [pkgtools] libXdamage-1.1.3-i486-1, [pkgtools] man-pages-3.32-noarch-1, [pkgtools] qimageblitz-0.0.6-i486-1, [pkgtools] xmessage-1.0.3-i486-1, [rpm] ooobasis-dev3.4-images-3.4.0-9518.i586, [rpm] ooobasis3.2-images-3.2.0-9483.i586
  2. zabbix_get -s localhost -p 11050 -k system.sw.packages[package,showpms]
    [pkgtools] damageproto-1.2.1-noarch-1, [pkgtools] imagemagick-6.6.6_10-i486-1, [pkgtools] libXdamage-1.1.3-i486-1, [pkgtools] man-pages-3.32-noarch-1, [pkgtools] qimageblitz-0.0.6-i486-1, [pkgtools] xmessage-1.0.3-i486-1, [rpm] ooobasis-dev3.4-images-3.4.0-9518.i586, [rpm] ooobasis3.2-images-3.2.0-9483.i586
  3. zabbix_get -s localhost -p 11050 -k system.sw.packages[packageszzqededqedqedzz,showpms]
    [pkgtools] damageproto-1.2.1-noarch-1, [pkgtools] imagemagick-6.6.6_10-i486-1, [pkgtools] libXdamage-1.1.3-i486-1, [pkgtools] man-pages-3.32-noarch-1, [pkgtools] qimageblitz-0.0.6-i486-1, [pkgtools] xmessage-1.0.3-i486-1, [rpm] ooobasis-dev3.4-images-3.4.0-9518.i586, [rpm] ooobasis3.2-images-3.2.0-9483.i586

<rudolfs> FIXED

<richlv> CLOSED

Show
richlv added a comment - - edited (B12) there seems to be some overly aggressive caching of positive (non-empty) results when requesting package list. consider the following exchange on a freshly started agent :
  1. zabbix_get -s localhost -p 11050 -k system.sw.packages[packageszzqededqedqedzz,showpms]
  1. zabbix_get -s localhost -p 11050 -k system.sw.packages[package,showpms]
  1. zabbix_get -s localhost -p 11050 -k system.sw.packages[age,showpms] [pkgtools] damageproto-1.2.1-noarch-1, [pkgtools] imagemagick-6.6.6_10-i486-1, [pkgtools] libXdamage-1.1.3-i486-1, [pkgtools] man-pages-3.32-noarch-1, [pkgtools] qimageblitz-0.0.6-i486-1, [pkgtools] xmessage-1.0.3-i486-1, [rpm] ooobasis-dev3.4-images-3.4.0-9518.i586, [rpm] ooobasis3.2-images-3.2.0-9483.i586
  2. zabbix_get -s localhost -p 11050 -k system.sw.packages[package,showpms] [pkgtools] damageproto-1.2.1-noarch-1, [pkgtools] imagemagick-6.6.6_10-i486-1, [pkgtools] libXdamage-1.1.3-i486-1, [pkgtools] man-pages-3.32-noarch-1, [pkgtools] qimageblitz-0.0.6-i486-1, [pkgtools] xmessage-1.0.3-i486-1, [rpm] ooobasis-dev3.4-images-3.4.0-9518.i586, [rpm] ooobasis3.2-images-3.2.0-9483.i586
  3. zabbix_get -s localhost -p 11050 -k system.sw.packages[packageszzqededqedqedzz,showpms] [pkgtools] damageproto-1.2.1-noarch-1, [pkgtools] imagemagick-6.6.6_10-i486-1, [pkgtools] libXdamage-1.1.3-i486-1, [pkgtools] man-pages-3.32-noarch-1, [pkgtools] qimageblitz-0.0.6-i486-1, [pkgtools] xmessage-1.0.3-i486-1, [rpm] ooobasis-dev3.4-images-3.4.0-9518.i586, [rpm] ooobasis3.2-images-3.2.0-9483.i586
<rudolfs> FIXED <richlv> CLOSED
Hide
richlv added a comment - - edited

(B13)

if package request results in no packages, empty string is returned. zabbix documentation explicitly states that userparameters should not return empty string (http://www.zabbix.com/documentation/1.8/manual/processes/zabbix_agentd), so it should be decided what to do about built-in items.
latest zabbix server seems to simply discard such values, but the item is not set to be unsupported.

<rudolfs> the current logic was to return NOTSUPPORTED only if no supported packaging systems are found, otherwise an empty string should mean that there are no packages installed (which might indeed be useless if another unsupported packaging system have the packages...)

<richlv> yes, but server seems to discard this value, thus the item just stops gathering values (and it also somewhat contradicts our own suggestions and behaviour with userparameters). i don't have a great solution, so just thinking aloud here

<rudolfs> Changed the logic:
1) by default, ''showpms" is used
2) [regex,showpms] lists every supported PMS followed by package list matching regex e.g. "[dpkg] pck, pck2, [rpm] pck3, [pacman]"
3) [regex,onlylist] lists all the packages matching regex and returns an empty string if no package matches the regex

<asaveljevs> Shall we start each package manager on its own line?

<asaveljevs> Fixed in r19396, fixed again in r19406.

<rudolfs> Please review changes in r19423.

<asaveljevs> CLOSED

Show
richlv added a comment - - edited (B13) if package request results in no packages, empty string is returned. zabbix documentation explicitly states that userparameters should not return empty string (http://www.zabbix.com/documentation/1.8/manual/processes/zabbix_agentd), so it should be decided what to do about built-in items. latest zabbix server seems to simply discard such values, but the item is not set to be unsupported. <rudolfs> the current logic was to return NOTSUPPORTED only if no supported packaging systems are found, otherwise an empty string should mean that there are no packages installed (which might indeed be useless if another unsupported packaging system have the packages...) <richlv> yes, but server seems to discard this value, thus the item just stops gathering values (and it also somewhat contradicts our own suggestions and behaviour with userparameters). i don't have a great solution, so just thinking aloud here <rudolfs> Changed the logic: 1) by default, ''showpms" is used 2) [regex,showpms] lists every supported PMS followed by package list matching regex e.g. "[dpkg] pck, pck2, [rpm] pck3, [pacman]" 3) [regex,onlylist] lists all the packages matching regex and returns an empty string if no package matches the regex <asaveljevs> Shall we start each package manager on its own line? <asaveljevs> Fixed in r19396, fixed again in r19406. <rudolfs> Please review changes in r19423. <asaveljevs> CLOSED
Hide
Maarten B. added a comment -

You might want to run the command 'pkginfo -E *' on FreeBSD, this returns the current packagelist.

Show
Maarten B. added a comment - You might want to run the command 'pkginfo -E *' on FreeBSD, this returns the current packagelist.
Hide
Aleksandrs Saveljevs added a comment -

Please add requests for other operating systems to ZBXNEXT-771.

Show
Aleksandrs Saveljevs added a comment - Please add requests for other operating systems to ZBXNEXT-771.
Hide
Rudolfs Kreicbergs added a comment -

Available in pre-1.9.5 r19752.

Show
Rudolfs Kreicbergs added a comment - Available in pre-1.9.5 r19752.
Hide
Oleksiy Zagorskyi added a comment -

I see the patch for the table "help_items" in the rev 19752.
But, if you decide to alter this table, would be very logical to include this issue ZBX-2265 since you are not performed even better way ZBXNEXT-554

Show
Oleksiy Zagorskyi added a comment - I see the patch for the table "help_items" in the rev 19752. But, if you decide to alter this table, would be very logical to include this issue ZBX-2265 since you are not performed even better way ZBXNEXT-554

People

Vote (1)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: