[ZBXNEXT-103] Allow multiple return values from a UserParameter Created: 2009 Oct 19  Updated: 2021 May 12  Resolved: 2021 May 12

Status: Closed
Project: ZABBIX FEATURE REQUESTS
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Change Request Priority: Minor
Reporter: Christoph Haas Assignee: Unassigned
Resolution: Won't fix Votes: 34
Labels: bulk, items, performance, usability
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
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.



 Comments   
Comment by João Figueiredo [ 2009 Nov 04 ]

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

Comment by Javier Gonel [ 2011 Jun 13 ]

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.

Comment by Strahinja Kustudic [ 2013 Aug 28 ]

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 signum 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.

Comment by Spiros Ioannou [ 2015 Feb 18 ]

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.

Comment by Strahinja Kustudic [ 2015 Feb 24 ]

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.

Comment by Spiros Ioannou [ 2015 Apr 03 ]

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

Comment by Marc [ 2015 Oct 09 ]

Similar aim but different approach ZBXNEXT-3006.

Comment by Oleksii Zagorskyi [ 2015 Oct 10 ]

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 kustodian mentioned.

Comment by richlv [ 2017 Oct 25 ]

this might be solved by the dependent items feature, implemented in 3.4

Comment by Glebs Ivanovskis (Inactive) [ 2017 Oct 25 ]

Good point, richlv! All interested please check this comment and comment if we still need this ticket or ZBXNEXT-4190.

Comment by Alexei Vladishev [ 2021 May 12 ]

I believe a combination of JSON data, preprocessing and dependent items fully covers this use case. I am closing this ticket.

Generated at Fri Mar 29 10:46:21 EET 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.