Details

    • Type: New Feature New Feature
    • Status: 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

      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 : zabbix_get -s localhost -p 11050 -k system.sw.packages [packageszzqededqedqedzz,showpms] zabbix_get -s localhost -p 11050 -k system.sw.packages [package,showpms] 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 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 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

          • Assignee:
            Rudolfs Kreicbergs
            Reporter:
            Alexander Vladishev
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: