Hi,
We have (userparameter) items that can go "unsupported" because custom scripts return error messages instead of the expected integer value ("Blah blah failed to connect to database" instead of the expected value).
As items are then considered "unsupported" zabbix_server won't evaluate the .nodata() function on them (looks like it won't evaluate anything at all). Detecting such problems is hence a bit more complicated.
What's the rationale behind excluding unsupported items from nodata evaluation (looks like the "filtering" occurs in src/zabbix_server/timer/timer.c with the query only fetching functions working on Active items) ? Avoiding too many false positives ?
On the other hand one may argue that we should harden our scripts so that they catch any error and always return the right type of info. But that's not always as easy as it seems. Plus you would need to define what value means "error / failure" which is not always possible especially with "counter" items.
Any thoughts on this ?
We have (userparameter) items that can go "unsupported" because custom scripts return error messages instead of the expected integer value ("Blah blah failed to connect to database" instead of the expected value).
As items are then considered "unsupported" zabbix_server won't evaluate the .nodata() function on them (looks like it won't evaluate anything at all). Detecting such problems is hence a bit more complicated.
What's the rationale behind excluding unsupported items from nodata evaluation (looks like the "filtering" occurs in src/zabbix_server/timer/timer.c with the query only fetching functions working on Active items) ? Avoiding too many false positives ?
On the other hand one may argue that we should harden our scripts so that they catch any error and always return the right type of info. But that's not always as easy as it seems. Plus you would need to define what value means "error / failure" which is not always possible especially with "counter" items.
Any thoughts on this ?
Comment