Details

      Description

      I'm in a situation where 2 client have the same range of IP.
      I have setup discovery on the deployed proxies, with "Device uniqueness criteria" set to IP address as it the only data I'm sure to get.
      Unfortunately the associated hosts are mixed up between the 2 proxies.

      I think IP "uniqueness criteria" should include the proxy, or at least give us the option of using the proxy as part of the uniqueness algorithm.

      1. ZBXNEXT-1267_2.0.8.patch
        4 kB
        Michael Brown
      1. 1hi13.png
        98 kB
      2. b4E8n.png
        41 kB
      3. ipkAt.png
        50 kB
      4. l2mTl.png
        30 kB
      5. nByLV.png
        94 kB
      6. oiwnk.png
        43 kB
      7. oRwBG.png
        30 kB
      8. Tfgjo.png
        18 kB
      9. ZbbjV.png
        19 kB

        Issue Links

          Activity

          Hide
          Oleksiy Zagorskyi added a comment - - edited

          I'd consider this feature as most critical if we will concern the "uniqueness" limitations, so I'm linking in this comment related issues.

          A bit related issue - ZBXNEXT-1495
          Related issue ZBXNEXT-213

          Show
          Oleksiy Zagorskyi added a comment - - edited I'd consider this feature as most critical if we will concern the "uniqueness" limitations, so I'm linking in this comment related issues. A bit related issue - ZBXNEXT-1495 Related issue ZBXNEXT-213
          Hide
          Oleksiy Zagorskyi added a comment - - edited

          Some technical details available here: http://www.zabbix.com/documentation/2.0/manual/config/notifications/action/operation/other

          I've performed several experiments with and without proxies (all are ~2.0.4rc1).
          I used two discovery rules (1st(id=10) - zabbix agent check "system.uname", 2nd(id=11) - snmp check "SNMPv2-MIB::sysName.0") with identical short IP range.

          In each discovery rule I used NOT IP address uniqueness criteria but different ones - zabbix and snmp respectively.
          Returned values for particular host were different for agent and snmp checks.

          Without proxies the result I've received was as expected:
          snmp interfaces have been added to existing hosts (already with zabbix agent interfaces)
          It's actually described in documentation bottom of a page http://www.zabbix.com/documentation/2.0/manual/discovery/network_discovery.
          There hard to complain for zabbix server because a server executing it has single routing table.
          But ... there still could be an option to control this - create new host or add new interface.

          But WITH proxies received results were as not intuitively expected.
          I had hosts (with zabbix interfaces) created by 1st drule DISCOVERED by a 1st proxy,
          then I disabled 1st drule and enabled 2nd drule performed on another 2nd proxy.

          IPs from 2nd proxy have been added as snmp-interfaces to hosts previously created by 1st discovery from 1st proxy.

          We know that zabbix server is responsible to process results of network discovery from proxies.
          But in this case I would expect that zabbix server will take care that results of discovery returned from ANOTHER 2nd proxy.

          So zabbix anyhow is not ready to perform discovery of identical IP ranges.

          Show
          Oleksiy Zagorskyi added a comment - - edited Some technical details available here: http://www.zabbix.com/documentation/2.0/manual/config/notifications/action/operation/other I've performed several experiments with and without proxies (all are ~2.0.4rc1). I used two discovery rules (1st(id=10) - zabbix agent check "system.uname", 2nd(id=11) - snmp check "SNMPv2-MIB::sysName.0") with identical short IP range. In each discovery rule I used NOT IP address uniqueness criteria but different ones - zabbix and snmp respectively. Returned values for particular host were different for agent and snmp checks. Without proxies the result I've received was as expected: snmp interfaces have been added to existing hosts (already with zabbix agent interfaces) It's actually described in documentation bottom of a page http://www.zabbix.com/documentation/2.0/manual/discovery/network_discovery . There hard to complain for zabbix server because a server executing it has single routing table. But ... there still could be an option to control this - create new host or add new interface. But WITH proxies received results were as not intuitively expected. I had hosts (with zabbix interfaces) created by 1st drule DISCOVERED by a 1st proxy, then I disabled 1st drule and enabled 2nd drule performed on another 2nd proxy. IPs from 2nd proxy have been added as snmp-interfaces to hosts previously created by 1st discovery from 1st proxy. We know that zabbix server is responsible to process results of network discovery from proxies. But in this case I would expect that zabbix server will take care that results of discovery returned from ANOTHER 2nd proxy. So zabbix anyhow is not ready to perform discovery of identical IP ranges.
          Hide
          Adrian Lewis added a comment -

          I don't suppose there's any way to extend this to cover situations where you may want two proxies to monitor the same device for redundancy purposes. While the redundancy aspect may not be a current feature, designing the uniqueness to account for this would be good architecturally. Perhaps have some form of metadata attached to the proxy that would define whether the devices are in fact on the same IP network or not. In the use-case of an IT service provider monitoring clients, the metadata would clearly be the customer name or ID.

          I'm just mentioning this as it seems that this feature is currently under development so it would be a shame not to mention it now. If it requires more funding I would consider helping on this front.

          Show
          Adrian Lewis added a comment - I don't suppose there's any way to extend this to cover situations where you may want two proxies to monitor the same device for redundancy purposes. While the redundancy aspect may not be a current feature, designing the uniqueness to account for this would be good architecturally. Perhaps have some form of metadata attached to the proxy that would define whether the devices are in fact on the same IP network or not. In the use-case of an IT service provider monitoring clients, the metadata would clearly be the customer name or ID. I'm just mentioning this as it seems that this feature is currently under development so it would be a shame not to mention it now. If it requires more funding I would consider helping on this front.
          Hide
          Oleksiy Zagorskyi added a comment -

          No, this feature is not under development currently (status=open).

          I wanted to add some technical details.
          In a function "add_discovered_host" (operations.c#190) for both (network discovery and autoregistration) events server will update "monitored by proxy" host field:

          else
          			{
          				if (host_proxy_hostid != proxy_hostid)
          				{
          					DBexecute("update hosts"
          							" set proxy_hostid=%s"
          							" where hostid=" ZBX_FS_UI64,
          							DBsql_id_ins(proxy_hostid), hostid);
          				}
          
          				DBadd_interface(hostid, interface_type, 1, row[2], row[3], port);
          			}
          

          if discovered|autoregistered host by|from another proxy and the host already exists.

          Show
          Oleksiy Zagorskyi added a comment - No, this feature is not under development currently (status=open). I wanted to add some technical details. In a function "add_discovered_host" (operations.c#190) for both (network discovery and autoregistration) events server will update "monitored by proxy" host field: else { if (host_proxy_hostid != proxy_hostid) { DBexecute( "update hosts" " set proxy_hostid=%s" " where hostid=" ZBX_FS_UI64, DBsql_id_ins(proxy_hostid), hostid); } DBadd_interface(hostid, interface_type, 1, row[2], row[3], port); } if discovered|autoregistered host by|from another proxy and the host already exists.
          Hide
          Michael Brown added a comment -

          Screenshots of my configuration causing the issue

          Show
          Michael Brown added a comment - Screenshots of my configuration causing the issue
          Hide
          Adrian Lewis added a comment -

          According to http://www.zabbix.com/development_services.php this is under development. Is that not correct?

          Show
          Adrian Lewis added a comment - According to http://www.zabbix.com/development_services.php this is under development. Is that not correct?
          Hide
          Oleksiy Zagorskyi added a comment -

          hmm, god catch Adrian
          I didn't know about that.

          I'm not sure is it indeed under development at the moment.

          Show
          Oleksiy Zagorskyi added a comment - hmm, god catch Adrian I didn't know about that. I'm not sure is it indeed under development at the moment.
          Hide
          Michael Brown added a comment -

          Any update on the development progress of this feature? This is a showstopper for us fully implementing Zabbix.

          Show
          Michael Brown added a comment - Any update on the development progress of this feature? This is a showstopper for us fully implementing Zabbix.
          Hide
          Michael Brown added a comment -

          I see that Andris Zeila was assigned to this task.

          Hello Andris! Does this mean that you are working on this feature?

          How far along is the development? We are eagerly awaiting this feature as this is a showstopper for our Zabbix implementation.

          Show
          Michael Brown added a comment - I see that Andris Zeila was assigned to this task. Hello Andris! Does this mean that you are working on this feature? How far along is the development? We are eagerly awaiting this feature as this is a showstopper for our Zabbix implementation.
          Hide
          Adrian Lewis added a comment - - edited

          Hi Andris - just want to say pretty much the same as what Michael has said. Obviously I can read that the details on this issue do not have a "Fix Version" set but do you know at this early stage if this is likely to end up in 2.2 or are we probably going to have to wait for 2.2.1 or even 2.4?

          Show
          Adrian Lewis added a comment - - edited Hi Andris - just want to say pretty much the same as what Michael has said. Obviously I can read that the details on this issue do not have a "Fix Version" set but do you know at this early stage if this is likely to end up in 2.2 or are we probably going to have to wait for 2.2.1 or even 2.4?
          Hide
          Andris Zeila added a comment -

          Hi, I just started to work on it and yes, it should be done for 2.2

          Show
          Andris Zeila added a comment - Hi, I just started to work on it and yes, it should be done for 2.2
          Hide
          Andris Zeila added a comment -

          Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBXNEXT-1267

          Show
          Andris Zeila added a comment - Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBXNEXT-1267
          Hide
          richlv added a comment - - edited

          (1) let's have a spec on .org

          Andris Zeila as it was decided to nod create an option for this the changes are quite trivial. I don't think we need to write a spec on such changes.

          <richlv> as could be seen by other changes, we do - but i guess it's too late for this one, CLOSED

          Show
          richlv added a comment - - edited (1) let's have a spec on .org Andris Zeila as it was decided to nod create an option for this the changes are quite trivial. I don't think we need to write a spec on such changes. < richlv > as could be seen by other changes, we do - but i guess it's too late for this one, CLOSED
          Hide
          Alexei Vladishev added a comment -

          I just discussed it with Alexander Vladishev. We decided to implement it as initially suggested, i.e. hosts discovered by different proxies are considered to be different. There will be no options to control it.

          Note that current implementation allows several physical hosts (having same IP) to be treated as a single one in Zabbix, it should not be allowed by design.

          Show
          Alexei Vladishev added a comment - I just discussed it with Alexander Vladishev . We decided to implement it as initially suggested, i.e. hosts discovered by different proxies are considered to be different. There will be no options to control it. Note that current implementation allows several physical hosts (having same IP) to be treated as a single one in Zabbix, it should not be allowed by design.
          Hide
          Andris Zeila added a comment -

          In that case I'm setting it as resolved - the current fix (r38521) covers the initial suggestion (considering hosts discovered by different proxies to be different).

          Show
          Andris Zeila added a comment - In that case I'm setting it as resolved - the current fix (r38521) covers the initial suggestion (considering hosts discovered by different proxies to be different).
          Hide
          Michael Brown added a comment -

          Andris,

          Does this feature depend on anything in 2.2? Or will we be able to backport it to 2.0?

          Show
          Michael Brown added a comment - Andris, Does this feature depend on anything in 2.2? Or will we be able to backport it to 2.0?
          Hide
          Michael Brown added a comment -

          Untested backport of ZBXNEXT-1267 to 2.0.8

          Show
          Michael Brown added a comment - Untested backport of ZBXNEXT-1267 to 2.0.8
          Hide
          Andris Zeila added a comment -

          If there were no real problems in backporting this patch (missing fields or something like), then it should work. At least I can't think about any dependencies offhand.

          Show
          Andris Zeila added a comment - If there were no real problems in backporting this patch (missing fields or something like), then it should work. At least I can't think about any dependencies offhand.
          Hide
          Alexander Vladishev added a comment -

          Successfully tested!

          Please review my changes in r38620.

          Show
          Alexander Vladishev added a comment - Successfully tested! Please review my changes in r38620.
          Show
          Andris Zeila added a comment - - edited Updated documentation, please review: https://www.zabbix.com/documentation/2.2/manual/introduction/whatsnew220#network_discovery_changes https://www.zabbix.com/documentation/2.2/manual/discovery/network_discovery/rule#changing_proxy_setting Alexander Vladishev CLOSED
          Hide
          Michael Brown added a comment -

          I've been running on 2.0.8 using the backported patch with no issues - much better, thanks!

          Show
          Michael Brown added a comment - I've been running on 2.0.8 using the backported patch with no issues - much better, thanks!
          Hide
          Adrian Lewis added a comment -

          Thank you for all this work - you've made me very happy. Just one last question - when is it likely that we'll see this in a full release. Do you think we'll see it first as 2.0.9 or as 2.2 and are there any projected dates, even vague? I'm really not comfortable patching 2.0.8 or running pre-release 2.2 code.

          Show
          Adrian Lewis added a comment - Thank you for all this work - you've made me very happy. Just one last question - when is it likely that we'll see this in a full release. Do you think we'll see it first as 2.0.9 or as 2.2 and are there any projected dates, even vague? I'm really not comfortable patching 2.0.8 or running pre-release 2.2 code.
          Hide
          Alexander Vladishev added a comment -

          Available in version pre-2.1.5 (trunk) r38622.

          Show
          Alexander Vladishev added a comment - Available in version pre-2.1.5 (trunk) r38622.
          Hide
          richlv added a comment -

          this seems to work incorrectly with uniqueness criteria other than ip - see ZBX-7744

          Show
          richlv added a comment - this seems to work incorrectly with uniqueness criteria other than ip - see ZBX-7744

            People

            • Assignee:
              Unassigned
              Reporter:
              Ghozlane TOUMI
            • Votes:
              2 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: