Seems I recall related issue report but cannot find it at the moment.
It was about simplifying Time-based functions syntax.
Also remember about ZBXNEXT-1575 for 2.2
my main complaint is about nodata() behaviour, time-based functions got carried in by an accident (Richlv).
For nodata() we had discussions in ZBXNEXT-341 which have been fixed (supposedly) in ZBXNEXT-1575
ZBXNEXT-1575 is exactly the kind of solution I'm trying to avoid (introducing additional actions)
The issue I meant in first my comment is ZBXNEXT-1719
IMHO, when an item doesn't receive values for X sec (and it does not matter because of item became not supported or zabbix agent became not available or zabbix agent stopped sending values, etc.) condition "there is no data for item" is TRUE, therefore function nodata(X) MUST be evaluated to "1" and corresponding trigger MUST fire independently of item state. Isn't it logical?
one usecase where this would be very useful :
in some clusters, the only way to determine whether cluster has both members is by querying two snmp oids (like serial numbers). if both cluster nodes are there, they will return the value. if not, one will return "no such oid", which will make item unsupported.
as such, there is no nice way to check whether both cluster nodes are up - the internal action does not scale well and does not allow to display this status in the trigger list, on the maps etc
Since duplicate issue was closed, I would like to copy my comment here, it shows two real live scenarios related to this feature request.
We are struggling a lot without having any possibility to trigger on item becoming unsupported. I will give you a couple examples so that you can understand how important it may be.
1. We monitor linecards on some networking chassis. From time to time linecards become invisible to the chassis because of hardware or software failure. There is an SNMP OID which indicates some parameters of the linecard, but once linecard "dies" SNMP OID returns "(noSuchName) There is no such variable name in this MIB.", therefore item becomes unsupported. So currently we don't have a possibility to monitor linecard status without building an ugly cludge with external scripts.
Here how it looks snmp wise:
Linecard present:
root@zabby-proxy:~# snmpget -v1 -c* 172.27.252.60 .1.3.6.1.4.1.8059.1.2.2.1.1.1.2.1.1.9
iso.3.6.1.4.1.8059.1.2.2.1.1.1.2.1.1.9 = INTEGER: 9
Linecard got lost:
snmpget -v1 -c* 172.27.252.60 .1.3.6.1.4.1.8059.1.2.2.1.1.1.2.1.1.9
Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: iso.3.6.1.4.1.8059.1.2.2.1.1.1.2.1.1.9
2. OSPF sessions monitoring is an alike case. While an OSPF session is established we can get it's status via SNMP, but if session goes down - the OID returns "There is no such variable name in this MIB.", item turns unsupported and we cannot trigger on OSPF session being down.
The nature of SNMP design is so that OIDs regarding dynamic entities(such as linecards and ospf sessions) may appear and disappear on the device, currently zabbix is not capable of monitoring such things without external scripts.
Any chance to finally implement it in near future?
There is no sense in non working monitoring system.
Thank you.
Anyone at all looking at this?
I recently had this issue with nodata(). When some item report a null value, and the item is of the type float, the item becomes unsupported with the message
Received value [] is not suitable for value type [Numeric (float)]
This is problematic because in my case, I call a custom script that always run fine, and my only option to tell zabbix that there is no data is to return nothing, but then [] is not a float so it becomes unsupported instead...
As a workaround, I specifically return an other value when I have no response with my script (0 in this case) and I changed the trigger to fire when the return value is 0. But this is not a perfect solution since it mess with the average value of the item, which can be important (in my case, it's timing value in seconds).
Same issue when a script times out:
Timeout while executing a shell script.
The item become then becomes unsupported and nodata() doesn't work either.
Yes, this is something we hope to see in a future release. If an external script times out or returns no value, there is no way to trigger an alert, which is very dangerous.
I know that you can regularly check for unsupported items. But we monitor hundreds of thousands of items, and we always have a few unsupported items.
It is definitively an important thing. It happens with odbc monitoring. If you are monitoring a database and isql can't connect, you get a "unsuported item" and your database may be down and you will never know unless you look at your mail or zabbix_server log. nodata processing would help.
Hi Zabbix team.
It's been a while since I'm not using Zabbix, so sorry in advance if this issue has been already sorted out.
Looking at What's new in Zabbix 3.0.0 apparently the new items_unsupported implementation fix this issue.
If yes, can you please state it clearly in this issue?
Many thanks.
caraconan, in "What's new in Zabbix 3.0.0" there is the following statement with the keyword you quoted:
New internal checks zabbix[host,,items] and zabbix[host,,items_unsupported] have been added. They return the number of items (unsupported items) on the target host.
This statement talks about new internal checks. This issue, however, is about evaluating trigger functions that reference unsupported items. So no, this issue has not been fixed.
Suggested solution for .nodata. Currently returns 1 for no data in X time period, or 0 if all is well. Could we create a third result? "2 - Item not supported". This change I beleive would allow triggers to be built to satisfy many of the above concerns. Mine as well.
thinking more about this specific issue, it's fairly sad for userparameters. if a userparam script fails, it has no way to allow nodata() triggers fire - if it sends crap data, that's bad, timing out makes the item unsupported...
is there a technical difficulty in making nodata() work on "unsupported" items ?
in case anyone is interested in an inspiration on the subject: I'm running the patch supplied in ZBX-1003 for a few years without any problems. the only downside is an extra sql request for each nodata() recalculation, but this is... unnoticeable.
I strongly consider this feature as a very important part of a solid monitoring system.
In a ZBX-10767 it's stated that it will be fixed in current issue.
Would be good to confirm that after fixing and close that issue too.
Development branches:
- svn://svn.zabbix.com/branches/dev/ZBXNEXT-1791-2 - main development
- svn://svn.zabbix.com/branches/dev/ZBXNEXT-1791-3 - nodata() and time-based functions for NOTSUPPORTED items in trigger expressions and calculated items
(1) It would be better to define ZBX_UNKNOWN_STR_LEN as ZBX_CONST_STRLEN(ZBX_UNKNOWN_STR) rather than hardcoded value 11.
andris RESOLVED in r61904 .
wiper CLOSED
The 1st merge is available in pre-3.2.0alpha3 (trunk) r61915 .
It enables evaluation of nodata() and time-based functions for NOTSUPPORTED items in trigger expressions and calculated items.
The 1st merge documented in
https://www.zabbix.com/documentation/3.2/manual/introduction/whatsnew320#trigger_and_calculated_item_functions
https://www.zabbix.com/documentation/3.2/manual/appendix/triggers/functions#functions_and_unsupported_items
https://www.zabbix.com/documentation/3.2/manual/config/items/itemtypes/calculated#configurable_fields
The 2nd merge documented in
https://www.zabbix.com/documentation/3.2/manual/config/triggers/expression#expressions_with_unsupported_items_and_unknown_values
https://www.zabbix.com/documentation/3.2/manual/config/triggers/expression#operators
https://www.zabbix.com/documentation/3.2/manual/config/items/itemtypes/calculated#configurable_fields
https://www.zabbix.com/documentation/3.2/manual/introduction/whatsnew320#triggers_and_calculated_items_with_unsupported_items_and_unknown_values
https://www.zabbix.com/documentation/3.2/manual/installation/upgrade_notes_320#changes_in_evaluation_of_trigger_and_calculated_item_expressions
sasha Excellent! CLOSED
(2) In expression.c:zbx_evaluate_item_functions()
The unknown_idx appears to be used to track the last unknown_msgs vector item. If that's so then unknown_msgs.values_num should be used instead.
andris Thanks! RESOLVED in r61931 .
wiper CLOSED
(3) In evaluate.c:evaluate_number()
If ZBX_UKNOWN value is without index (which can happen with .last() function returning an item value ZBX_UNKNOWN)
THIS_SHOULD_NEVER_HAPPEN is logged, ZBX_INFINITY is returned, but the ptr pointer is not moved. Not sure if that could lead to loops or something, but I suggest moving ptr pointer at the end of ZBX_UNKNOWN value.
andris Good idea! RESOLVED in r61933 .
wiper Also I think it would be better to remove THIS_SHOULD_NEVER_HAPPEN, as user can create valid setup which would result in this error.
REOPENED
andris RESOLVED in r61941
wiper CLOSED
(4) In DCupdate_hosts_availability(void) the sql* variables are renamed to sql_buff*. We have 150+ places where sql* variables are used and 0 with sql_buf* naming. I think it's better to stay with the usual naming.
andris The reason of renaming local variables 'sql', 'sql_alloc' and 'sql_offset' is to avoid shadowing of global variables with the same names. WON'T FIX.
(5) In serveral evaluate_term* functions the returned index is lost if the term does not match the following expression. It can lead to unitialized variable usage and crashes. This crude patch appears to help, but it might still be missing something.
Index: src/libs/zbxalgo/evaluate.c
===================================================================
--- src/libs/zbxalgo/evaluate.c (revision 61904)
+++ src/libs/zbxalgo/evaluate.c (working copy)
@@ -292,6 +292,9 @@
if (ZBX_INFINITY == (result = evaluate_term7(&res_idx)))
return ZBX_INFINITY;
+ if (ZBX_UNKNOWN == result)
+ *unknown_idx = res_idx;
+
/* if evaluate_term7() returns ZBX_UNKNOWN then continue as with regular number */
while ('*' == *ptr || '/' == *ptr)
@@ -365,6 +368,9 @@
if (ZBX_INFINITY == (result = evaluate_term6(&res_idx)))
return ZBX_INFINITY;
+ if (ZBX_UNKNOWN == result)
+ *unknown_idx = res_idx;
+
/* if evaluate_term6() returns ZBX_UNKNOWN then continue as with regular number */
while ('+' == *ptr || '-' == *ptr)
@@ -416,6 +422,9 @@
if (ZBX_INFINITY == (result = evaluate_term5(&res_idx)))
return ZBX_INFINITY;
+ if (ZBX_UNKNOWN == result)
+ *unknown_idx = res_idx;
+
/* if evaluate_term5() returns ZBX_UNKNOWN then continue as with regular number */
while (1)
@@ -489,6 +498,9 @@
if (ZBX_INFINITY == (result = evaluate_term4(&res_idx)))
return ZBX_INFINITY;
+ if (ZBX_UNKNOWN == result)
+ *unknown_idx = res_idx;
+
/* if evaluate_term4() returns ZBX_UNKNOWN then continue as with regular number */
while (1)
@@ -550,6 +562,9 @@
if (ZBX_INFINITY == (result = evaluate_term3(&res_idx)))
return ZBX_INFINITY;
+ if (ZBX_UNKNOWN == result)
+ *unknown_idx = res_idx;
+
/* if evaluate_term3() returns ZBX_UNKNOWN then continue as with regular number */
while ('a' == ptr[0] && 'n' == ptr[1] && 'd' == ptr[2] && SUCCEED == is_operator_delimiter(ptr[3]))
@@ -625,6 +640,9 @@
if (ZBX_INFINITY == (result = evaluate_term2(&res_idx)))
return ZBX_INFINITY;
+ if (ZBX_UNKNOWN == result)
+ *unknown_idx = res_idx;
+
/* if evaluate_term2() returns ZBX_UNKNOWN then continue as with regular number */
while ('o' == ptr[0] && 'r' == ptr[1] && SUCCEED == is_operator_delimiter(ptr[2]))
andris Thanks for finding this and patch! RESOLVED in r61936 .
wiper CLOSED
(6) Continuing from the (3) - we should validate the index returned by evaluate_term1 against the unknown_msgs vector boundaries. Otherwise it's possible to crash server when using last() function if item value is something like ZBX_UNKNOWN1234.
andris RESOLVED in r61949.
wiper CLOSED
The 2nd merge is available in pre-3.2.0beta1 (trunk) r61960 .
It enables evaluation of logical expressions with unsupported items in trigger expressions and calculated items.
(7) When both items in an expression are unknown the generated error refers to the second item. It would be more natural to refer the first item.
andris This is an approved design decision - if there are multiple unknown operands and expression evaluates to Unknown then the error message refers to the last unknown item.
For example, expression '(Unknown1 + Unknown2) or (Unknown3 and Unknown4)' evaluates to Unknown. Concatenating all error messages together is not an option as there are only 128 bytes for error message. There is no single answer which particular operand should be reported in error message as a cause of Unknown result ("too many unsupported items" is worse than pointing to one of items in error message). So we decided to use the last one evaluated. WON'T FIX.
Base evaluation logic tested:
OR
{Trapper:strap[1].last()} or {Trapper:strap[2].last()}
| Left | Right | Expected | Result |
|------|-------|----------|-----------------------------------------------------------------------------------------------------------|
| 0 | 0 | 0 | 0 |
| 0 | 1 | 1 | 1 |
| 1 | 0 | 1 | 1 |
| 1 | 1 | 1 | 1 |
| ? | 0 | ? | Cannot evaluate expression: "Cannot evaluate function "Trapper:strap[1].last()": item is not supported.". |
| 0 | ? | ? | Cannot evaluate expression: "Cannot evaluate function "Trapper:strap[2].last()": item is not supported.". |
| ? | 1 | 1 | 1 |
| 1 | ? | 1 | 1 |
| ? | ? | ? | Cannot evaluate expression: "Cannot evaluate function "Trapper:strap[2].last()": item is not supported.". |
AND
{Trapper:strap[1].last()} and {Trapper:strap[2].last()}
| Left | Right | Expected | Result |
|------|-------|----------|-----------------------------------------------------------------------------------------------------------|
| 0 | 0 | 0 | 0 |
| 0 | 1 | 0 | 0 |
| 1 | 0 | 0 | 0 |
| 1 | 1 | 1 | 1 |
| ? | 0 | 0 | 0 |
| 0 | ? | 0 | 0 |
| ? | 1 | ? | Cannot evaluate expression: "Cannot evaluate function "Trapper:strap[1].last()": item is not supported.". |
| 1 | ? | ? | Cannot evaluate expression: "Cannot evaluate function "Trapper:strap[2].last()": item is not supported.". |
| ? | ? | ? | Cannot evaluate expression: "Cannot evaluate function "Trapper:strap[2].last()": item is not supported.". |
=, <>
{Trapper:strap[1].last()} = {Trapper:strap[2].last()}
| Left | Right | Expected | Result |
|------|-------|----------|-----------------------------------------------------------------------------------------------------------|
| 0 | 0 | 1 | 1 |
| 0 | 1 | 0 | 0 |
| 1 | 0 | 0 | 0 |
| 1 | 1 | 1 | 1 |
| ? | 0 | ? | Cannot evaluate expression: "Cannot evaluate function "Trapper:strap[1].last()": item is not supported.". |
| 0 | ? | ? | Cannot evaluate expression: "Cannot evaluate function "Trapper:strap[2].last()": item is not supported.". |
| ? | 1 | ? | Cannot evaluate expression: "Cannot evaluate function "Trapper:strap[1].last()": item is not supported.". |
| 1 | ? | ? | Cannot evaluate expression: "Cannot evaluate function "Trapper:strap[2].last()": item is not supported.". |
| ? | ? | ? | Cannot evaluate expression: "Cannot evaluate function "Trapper:strap[2].last()": item is not supported.". |
<. <=, >, >=
{Trapper:strap[1].last()} < {Trapper:strap[2].last()}
| Left | Right | Expected | Result |
|------|-------|----------|-----------------------------------------------------------------------------------------------------------|
| 0 | 0 | 0 | 0 |
| 0 | 1 | 1 | 1 |
| 1 | 0 | 0 | 0 |
| 1 | 1 | 0 | 0 |
| ? | 0 | ? | Cannot evaluate expression: "Cannot evaluate function "Trapper:strap[1].last()": item is not supported.". |
| 0 | ? | ? | Cannot evaluate expression: "Cannot evaluate function "Trapper:strap[2].last()": item is not supported.". |
| ? | 1 | ? | Cannot evaluate expression: "Cannot evaluate function "Trapper:strap[1].last()": item is not supported.". |
| 1 | ? | ? | Cannot evaluate expression: "Cannot evaluate function "Trapper:strap[2].last()": item is not supported.". |
| ? | ? | ? | Cannot evaluate expression: "Cannot evaluate function "Trapper:strap[2].last()": item is not supported.". |
+, -
{Trapper:strap[1].last()} + {Trapper:strap[2].last()}
| Left | Right | Expected | Result |
|------|-------|----------|-----------------------------------------------------------------------------------------------------------|
| 0 | 0 | 0 | 0 |
| 0 | 1 | 1 | 1 |
| 1 | 0 | 1 | 1 |
| 1 | 1 | 2 | 2 |
| ? | 0 | ? | Cannot evaluate expression: "Cannot evaluate function "Trapper:strap[1].last()": item is not supported.". |
| 0 | ? | ? | Cannot evaluate expression: "Cannot evaluate function "Trapper:strap[2].last()": item is not supported.". |
| ? | 1 | ? | Cannot evaluate expression: "Cannot evaluate function "Trapper:strap[1].last()": item is not supported.". |
| 1 | ? | ? | Cannot evaluate expression: "Cannot evaluate function "Trapper:strap[2].last()": item is not supported.". |
| ? | ? | ? | Cannot evaluate expression: "Cannot evaluate function "Trapper:strap[2].last()": item is not supported.". |
*, /
{Trapper:strap[1].last()} * {Trapper:strap[2].last()}
| Left | Right | Expected | Result |
|------|-------|----------|-----------------------------------------------------------------------------------------------------------|
| 0 | 0 | 0 | 0 |
| 0 | 1 | 0 | 0 |
| 1 | 0 | 0 | 0 |
| 1 | 1 | 1 | 1 |
| ? | 0 | ? | Cannot evaluate expression: "Cannot evaluate function "Trapper:strap[1].last()": item is not supported.". |
| 0 | ? | ? | Cannot evaluate expression: "Cannot evaluate function "Trapper:strap[2].last()": item is not supported.". |
| ? | 1 | ? | Cannot evaluate expression: "Cannot evaluate function "Trapper:strap[1].last()": item is not supported.". |
| 1 | ? | ? | Cannot evaluate expression: "Cannot evaluate function "Trapper:strap[2].last()": item is not supported.". |
| ? | ? | ? | Cannot evaluate expression: "Cannot evaluate function "Trapper:strap[2].last()": item is not supported.". |
NOT
not {Trapper:strap[1].last()}
| Left | Expected | Result |
|------|----------|-----------------------------------------------------------------------------------------------------------|
| 0 | 1 | 1 |
| 1 | 0 | 0 |
| ? | ? | Cannot evaluate expression: "Cannot evaluate function "Trapper:strap[1].last()": item is not supported.". |
unary -
-{Trapper:strap[1].last()}
| Left | Expected | Result |
|------|----------|-----------------------------------------------------------------------------------------------------------|
| 0 | -0 | -0 |
| 1 | -1 | -1 |
| ? | ? | Cannot evaluate expression: "Cannot evaluate function "Trapper:strap[1].last()": item is not supported.". |
(8) Reverted evaluate() function error parameters to be mandatory. It's being assigned to a static variable and there is a high possibility of bugs if NULL is used.
RESOLVED in development branch svn://svn.zabbix.com/branches/dev/ZBXNEXT-1791-4 r62003
andris Merged into trunk r62051. CLOSED
(9) Currently calculated item "1 or notexistingfunction(vfs.file.cksum[/test_file.txt])" evaluates to 1.
It would be better to make it unsupported with error message like "Cannot evaluate expression: notexistingfunction() function is not supported" to notify user about syntax error.
andris For triggers the frontend does not allow to use non-existing functions. Only calculated items are affected and validation in the frontend should be developed. WON'T FIX.
(10) Clang static analysis tool reports new defects in trunk. Number of defects before this change: 45. Number of defects after: 63. Please take a look!
./bootstrap.sh ./configure --prefix=`pwd`/usr CC=clang CFLAGS="-Wall -Wextra -g" --enable-server --enable-proxy --enable-agent --enable-java --enable-ipv6 --with-mysql --with-jabber --with-libxml2 --with-net-snmp --with-unixodbc --with-ssh2 --with-openipmi --with-ldap --with-libcurl --with-iconv --with-openssl make dbschema scan-build make install 2>&1 | tee make.log scan-view /tmp/scan-build-2016-08-30-103815-15464-1
andris Thanks for finding! This uncovered some bugs.
andris RESOLVED in dev branch svn://svn.zabbix.com/branches/dev/ZBXNEXT-1791-5, r62119.
wiper CLOSED
andris Merged into trunk r62138 .