ZABBIX FEATURE REQUESTS
  1. ZABBIX FEATURE REQUESTS
  2. ZBXNEXT-103

Allow multiple return values from a UserParameter

    Details

    • Type: Change Request Change Request
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Environment:
      Debian, Zabbix 1.6.6

      Description

      It would be nice if a UserParameter could return more than one value.

      (1)
      Take Nagios for example. Their plugins return both a status code (OK, WARN or ALERT) and a text string.
      The status is triggering a notification if needed and the text string is just added to the notification.
      But Zabbix currently doesn't accept these two bits of information from a UserParameter.

      My current task is to monitor a MySQL database replication. I usually have the number of seconds that
      a replication lags behind the master. But things can go wrong and the replication has stopped or I can't
      reach the database or whatever has happened. The shell plugin I wrote knows all these cases
      but cannot properly communicate them to Zabbix. My current workaround is that I return a positive
      number of the number of seconds of replication lag. And -1 if the database is down, -2 if the replication
      has stopped, -3 if I lack permission to access the database and so on. This looks stupid in the graphs.
      So I wished I could return the number of seconds latency as usual but also a general status in the same run
      including a free-form text.

      Example:
      return value #1: UNDEF seconds lag
      return value #2: status: error
      return value #3: status text: Master database server has become unreachable.

      Example:
      return value #1: 129 seconds lag
      return value #2: status: ok
      return value #3: status text: -

      (2)
      Some commands can gather multiple parameters and returning them. But currently Zabbix
      only supports one paramter per UserParameter. As a bad example a shell command may need to be called
      ten times (with the same parameters) to return ten different values.

      Random example:

      UserParameter=mysql.replicationstatus,somecommand | awk '{print $1}'
      UserParameter=mysql.replicationlag,somecommand | awk '{print $2}'
      UserParameter=mysql.replicationposition,somecommand | awk '{print $3}'
      

      It would be nicer if "somecommand" could just be called once and return three values that Zabbix can deal with.

      Hope this makes any sense.

        Activity

        Hide
        João Figueiredo added a comment -

        This improvement allows for a easier setup of custom metrics.

        It would avoid us having a script to parse several values from a sequence of objects and sending each one of them with a different key by zabbix_send

        Show
        João Figueiredo added a comment - This improvement allows for a easier setup of custom metrics. It would avoid us having a script to parse several values from a sequence of objects and sending each one of them with a different key by zabbix_send
        Hide
        Javier Gonel added a comment -

        This could reduce load generated by zabbix agent when trying to get 50 parameters from the same source by running 50 times the same command but awk-ing something different.

        If the zabbix agent could accept a json object as response (for example), perhaps it could import more than one item at a time.

        Show
        Javier Gonel added a comment - This could reduce load generated by zabbix agent when trying to get 50 parameters from the same source by running 50 times the same command but awk-ing something different. If the zabbix agent could accept a json object as response (for example), perhaps it could import more than one item at a time.
        Hide
        Strahinja Kustudic added a comment -

        I think what is suggested in (1) is not the same issue as what is suggested in (2), they are two different things. In (1) it is suggested that every item besides an item value, has a status and status_text, while in (2) it is suggested that one UserParameter can return values for more items.

        (1) This was one of the things that bothered me in Zabbix the most when I migrated from Nagios. Implementing it as Christoph Haas explained would be a big change for Zabbix in many ways. Since every item would need to have two more columns in the database in the history table: status and status_text. This could make the Zabbix database significantly bigger than it currently is which could be a problem on big Zabbix installations. Also trigger evaluation would need to be changed so that triggers can check values as well as status. It would be easier to write custom scripts which gather information if items had status and status_text, especially because of the status_text since you would be able to return the text and just display it in a Zabbix notification, while now you need to do a workaround like you mentioned, the biggest issue with this is that it looks bad in graphs. The easiest solution to this is to either make it possible to set on graphs what are valid values, so it doesn't display negative values, or even set in the item itself what values are for graphs and what are just for status.

        (2) It would really be great if Zabbix could populate values of multiple items from just one UserParameter. I'm not sure what would be the easiest approach to this. Maybe we could add a UserParameterGroup:

        UserParameterGroup=nginx.status,/usr/local/bin/get_nginx_status.sh

        which returns 4 values number of:

        • active connections
        • reading
        • waiting
        • writing

        respectably. Then in the Zabbix GUI we would create an Item Group which would have a group key nginx.status and in that group we would create 4 items in the order the script is returning values, so the first item in the group will get the first value of the UserParameterGroup, the second one will get the second one, etc. and the get_nginx_status.sh would be called only once.

        Show
        Strahinja Kustudic added a comment - I think what is suggested in (1) is not the same issue as what is suggested in (2), they are two different things. In (1) it is suggested that every item besides an item value, has a status and status_text, while in (2) it is suggested that one UserParameter can return values for more items. (1) This was one of the things that bothered me in Zabbix the most when I migrated from Nagios. Implementing it as Christoph Haas explained would be a big change for Zabbix in many ways. Since every item would need to have two more columns in the database in the history table: status and status_text. This could make the Zabbix database significantly bigger than it currently is which could be a problem on big Zabbix installations. Also trigger evaluation would need to be changed so that triggers can check values as well as status. It would be easier to write custom scripts which gather information if items had status and status_text, especially because of the status_text since you would be able to return the text and just display it in a Zabbix notification, while now you need to do a workaround like you mentioned, the biggest issue with this is that it looks bad in graphs. The easiest solution to this is to either make it possible to set on graphs what are valid values, so it doesn't display negative values, or even set in the item itself what values are for graphs and what are just for status. (2) It would really be great if Zabbix could populate values of multiple items from just one UserParameter. I'm not sure what would be the easiest approach to this. Maybe we could add a UserParameterGroup: UserParameterGroup=nginx.status,/usr/local/bin/get_nginx_status.sh which returns 4 values number of: active connections reading waiting writing respectably. Then in the Zabbix GUI we would create an Item Group which would have a group key nginx.status and in that group we would create 4 items in the order the script is returning values, so the first item in the group will get the first value of the UserParameterGroup, the second one will get the second one, etc. and the get_nginx_status.sh would be called only once.
        Hide
        Spiros Ioannou added a comment - - edited

        You can do this using "run cached" https://bitbucket.org/sivann/runcached/overview
        This allows to run a command once (caching its output) and then parse different parts of its output using a multiple userparameters (or multiple items passing arguments to the same userparameter). Caching time is configurable.
        Not only you can get lots of values with one call which is light on resources, you also get the benefit that all values correspond to the same timestamp.

        Check the link for mysql Userparameter getting multiple status values, while actually executing the mysql query only once. It has proven useful in many zabbix scripts.

        Show
        Spiros Ioannou added a comment - - edited You can do this using "run cached" https://bitbucket.org/sivann/runcached/overview This allows to run a command once (caching its output) and then parse different parts of its output using a multiple userparameters (or multiple items passing arguments to the same userparameter). Caching time is configurable. Not only you can get lots of values with one call which is light on resources, you also get the benefit that all values correspond to the same timestamp. Check the link for mysql Userparameter getting multiple status values, while actually executing the mysql query only once. It has proven useful in many zabbix scripts.
        Hide
        Strahinja Kustudic added a comment -

        That is a cool software, but it doesn't solve the problem completely. If you create all items to refresh every 60 seconds and they all pull date from a user parameter which uses runcached, those items could still be executed in different times from the zabbix server and they would have different timestamps on the server. This means that some items could have values from the first execution of runcached, while others from the fresher call.

        For now we us an item which calls a script which sends multiple items using zabbix_sender, this works much better, if your network allows you to securely use zabbix_sender, since you get items with the exact same timestamp. But even using zabbix_sender doesn't solve the problem of zabbix server trigger evaluation on multiple items with same timestamp occuring multiple times, instead of once, which is explained in a separate issue ZBXNEXT-2617.

        Show
        Strahinja Kustudic added a comment - That is a cool software, but it doesn't solve the problem completely. If you create all items to refresh every 60 seconds and they all pull date from a user parameter which uses runcached , those items could still be executed in different times from the zabbix server and they would have different timestamps on the server. This means that some items could have values from the first execution of runcached , while others from the fresher call. For now we us an item which calls a script which sends multiple items using zabbix_sender , this works much better, if your network allows you to securely use zabbix_sender , since you get items with the exact same timestamp. But even using zabbix_sender doesn't solve the problem of zabbix server trigger evaluation on multiple items with same timestamp occuring multiple times, instead of once, which is explained in a separate issue ZBXNEXT-2617 .
        Hide
        Spiros Ioannou added a comment -

        Yes, you are correct, it doesn't solve the problem completely. But I think you could combine runcached with zabbix_sender.

        Show
        Spiros Ioannou added a comment - Yes, you are correct, it doesn't solve the problem completely. But I think you could combine runcached with zabbix_sender.
        Hide
        Marc added a comment - - edited

        Similar aim but different approach ZBXNEXT-3006.

        Show
        Marc added a comment - - edited Similar aim but different approach ZBXNEXT-3006 .
        Hide
        Oleksiy Zagorskyi added a comment -

        It reminds me about https://www.zabbix.org/wiki/Docs/howto/apache_monitoring_script solution where many values are returned back to zabbix server using zabbix sender, as Strahinja Kustudic mentioned.

        Show
        Oleksiy Zagorskyi added a comment - It reminds me about https://www.zabbix.org/wiki/Docs/howto/apache_monitoring_script solution where many values are returned back to zabbix server using zabbix sender, as Strahinja Kustudic mentioned.

          People

          • Assignee:
            Unassigned
            Reporter:
            Christoph Haas
          • Votes:
            33 Vote for this issue
            Watchers:
            22 Start watching this issue

            Dates

            • Created:
              Updated: