ZABBIX BUGS AND ISSUES
  1. ZABBIX BUGS AND ISSUES
  2. ZBX-7649

icmp ping items for a single host should be checked together

    Details

      Description

      We have "Template ICMP Ping" in the default installation of Zabbix with three items: icmpping, icmppingsec, and icmppingloss. The time these items will be checked is calculated based on their item ID, so most probably these items will be scheduled for a check at times T, T+1, and T+2.

      Now, suppose Zabbix server only has one pinger running. It will take the first item at time T and process it. Processing will take around 3 seconds, so the next time it looks into the queue it is going to process the other two items. So in order to obtain values for a single host two passes are needed.

      It would be nice to check all three items with a single fping invocation. The easiest way of doing this is scheduling a check based on their interface ID, rather than on item ID.

        Activity

        Hide
        Andris Zeila added a comment -

        Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBX-7649

        Show
        Andris Zeila added a comment - Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBX-7649
        Hide
        Oleksiy Zagorskyi added a comment - - edited

        (1) Would be nice to reflect the changes a bit on:
        https://www.zabbix.com/documentation/2.2/manual/introduction/whatsnew222
        https://www.zabbix.com/documentation/2.2/manual/config/items/itemtypes/simple_checks#icmp_pings

        Andris Zeila Added scheduling optimization information. Please review. RESOLVED.

        Aleksandrs Saveljevs Looks good. I only fixed a typo in the second link. CLOSED.

        Show
        Oleksiy Zagorskyi added a comment - - edited (1) Would be nice to reflect the changes a bit on: https://www.zabbix.com/documentation/2.2/manual/introduction/whatsnew222 https://www.zabbix.com/documentation/2.2/manual/config/items/itemtypes/simple_checks#icmp_pings Andris Zeila Added scheduling optimization information. Please review. RESOLVED. Aleksandrs Saveljevs Looks good. I only fixed a typo in the second link. CLOSED.
        Hide
        Andris Zeila added a comment - - edited

        (2) There is no need to base java/pinger poller item nextchek seed calculations on interfaceid and poller type as they already have different interfaces.

        RESOLVED in r41727

        Aleksandrs Saveljevs CLOSED

        Show
        Andris Zeila added a comment - - edited (2) There is no need to base java/pinger poller item nextchek seed calculations on interfaceid and poller type as they already have different interfaces. RESOLVED in r41727 Aleksandrs Saveljevs CLOSED
        Hide
        Aleksandrs Saveljevs added a comment - - edited

        (3) In the email, Alexander Vladishev offered to rename __config_pinger_nextcheck_compare() and other similar functions to be consistent. You seem to have agreed, but decided not to do it. Reminding about it in this subissue.

        However, it might not be worth doing it, because I am changing this code a bit in ZBXNEXT-98 anyway.

        Andris Zeila Right, forgot about it. RESOLVED in r41762
        However if you are changing it in different ZBX, maybe I should rollback it, to avoid conflicts

        Aleksandrs Saveljevs Yes, let's revert that. Did it in r41780. CLOSED.

        Show
        Aleksandrs Saveljevs added a comment - - edited (3) In the email, Alexander Vladishev offered to rename __config_pinger_nextcheck_compare() and other similar functions to be consistent. You seem to have agreed, but decided not to do it. Reminding about it in this subissue. However, it might not be worth doing it, because I am changing this code a bit in ZBXNEXT-98 anyway. Andris Zeila Right, forgot about it. RESOLVED in r41762 However if you are changing it in different ZBX, maybe I should rollback it, to avoid conflicts Aleksandrs Saveljevs Yes, let's revert that. Did it in r41780. CLOSED.
        Hide
        Aleksandrs Saveljevs added a comment - - edited

        (4) In DCsync_items(), around line 960, we set poller_type to ZBX_NO_POLLER, and then calculate nextcheck seed. Since get_item_nextcheck_seed() relies on poller_type, it would be nice to calculate the seed after poller_type is set.

        Andris Zeila RESOLVED in r41760

        Aleksandrs Saveljevs CLOSED.

        Show
        Aleksandrs Saveljevs added a comment - - edited (4) In DCsync_items(), around line 960, we set poller_type to ZBX_NO_POLLER, and then calculate nextcheck seed. Since get_item_nextcheck_seed() relies on poller_type, it would be nice to calculate the seed after poller_type is set. Andris Zeila RESOLVED in r41760 Aleksandrs Saveljevs CLOSED.
        Hide
        Aleksandrs Saveljevs added a comment - - edited

        (5) Let's adapt function calculateItemNextcheck() in the frontend, too!

        Aleksandrs Saveljevs Adapted in r41785. RESOLVED.

        Andris Zeila CLOSED

        Show
        Aleksandrs Saveljevs added a comment - - edited (5) Let's adapt function calculateItemNextcheck() in the frontend, too! Aleksandrs Saveljevs Adapted in r41785. RESOLVED. Andris Zeila CLOSED
        Hide
        Aleksandrs Saveljevs added a comment - - edited

        (6) Please take a look at minor fixes in r41758.

        Andris Zeila thanks, CLOSED

        Show
        Aleksandrs Saveljevs added a comment - - edited (6) Please take a look at minor fixes in r41758. Andris Zeila thanks, CLOSED
        Hide
        Andris Zeila added a comment - - edited

        Subissues (3), (4) and (6) are fixed. Did not set to resolved state because of (5)

        Show
        Andris Zeila added a comment - - edited Subissues (3), (4) and (6) are fixed. Did not set to resolved state because of (5)
        Hide
        Aleksandrs Saveljevs added a comment - - edited

        (7) Note that after the changes JMX items will be scheduled based on interface ID if their host is reachable, and based on item ID if not (because it will then be processed by an unreachable poller). This is probably not a problem, because this change in scheduling will only affect items whose delay settings change between calls to DCsync_items(). During regular processing, JMX items for unreachable hosts will still be scheduled based on host->jmx_disable_until, as returned by DCget_unreachable_nextcheck() function.

        Andris Zeila CLOSED

        Show
        Aleksandrs Saveljevs added a comment - - edited (7) Note that after the changes JMX items will be scheduled based on interface ID if their host is reachable, and based on item ID if not (because it will then be processed by an unreachable poller). This is probably not a problem, because this change in scheduling will only affect items whose delay settings change between calls to DCsync_items(). During regular processing, JMX items for unreachable hosts will still be scheduled based on host->jmx_disable_until, as returned by DCget_unreachable_nextcheck() function. Andris Zeila CLOSED
        Hide
        Andris Zeila added a comment -

        Released in:
        pre-2.2.2rc1 r41824
        pre-2.3.0 r41825

        Show
        Andris Zeila added a comment - Released in: pre-2.2.2rc1 r41824 pre-2.3.0 r41825

          People

          • Assignee:
            Unassigned
            Reporter:
            Aleksandrs Saveljevs
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: