PATCH: Lua Scripts in Zabbix

[nelsonab]

Cool, thanks for the feedback. Lua assigns all variables the value of nil when they are instantiated (first used). Nil is a special type which has no value, and thus cannot be used in arithmetic.

The bug however is that I am not checking for a nil value to be returned.

I hope to have something soon to fix this.

[nelsonab]

Attached is a patch to add some error checking for nil values. This patch is for 1.8.4, and follows the patching methods mentioned previously.

[nelsonab]

Attached is the latest version for 1.8.4.

New in this version is the function get_itemid(host,key) which will return the itemid for the item associated by host:key. Both host and key must be string values.

There are also two global variables now available. zbx_host and zbx_hostid. zbx_host is a string representing the host associated with the currently executing lua script, zbx_hostid is the integer representation of the hostid for the currently executing lua script.

Thus one way to call get_itemid would be:
itemid=get_itemid(zbx_host,"net.if.in[eth1]")

It is recomended not to test this patch in a large distributed environment or an environment with many hosts. There is an issue with the transcription of long long integers (64bit) to Lua. Lua treats all numbers as a double double (64bit floating point) which allows for 52 bits of integer data. This should not be an issue for most people uless your hostids or itemids are greater than (2^53)-1. I will be working to solve this issue in a future version.

[clopez]

Hello

I have just tested the patch 1.8.4-p4-lua.patch and I confirm you that it solves the crashes related to returning nil items

zabbix_server no longer crashs and now I can see on the logs

Lua error: (null)
0.000334 seconds to execute Lua script itemid:22272  script:(null)
Item [HOST:lua[TEMP]] error: Null Value Returned

I am going to test now the -p5 patch

Thanks a lot!

[clopez]

I have tested the -p5 patch and it works like a charm

For postgresql users is need to replace the \" with \' on all DBselect() calls because postgres is more picky with that than mysql

For people willing to use the script on templates note that they can reference the host where the lua script is executed with the global variable zbx_host. For example:

itemid=get_itemid(zbx_host,"TEMP")
value=get_last(itemid)
return (value)

Thanks a lot for this great patch

[nelsonab]

I have added the Postgres changes you mentioned int my dev code. I'm working on tackling the 64bit integer problem right now and hope to have something to post soon.

I will also try and test out loading some other Lua libraries such as the Math ones.

Further down the road I will be working to improve the get_last function (or add a new one) to retrieve and manipulate historical sets of data.

[nelsonab]

Attached is the latest version for 1.8.4, p6
See post #2 for installation instructions.

This version now supports 64bit unsigned integers. This means the earlier limitation on item and hostids should be gone. If you need to create an unsigned 64bit ingeger while within Lua use the following statement:
a=uint64(1234)
This will assign the variable a the value of 1234 which is a 64bit unsigned integer.

Also changes advised by clopez for Postgres have been included.

[clopez]

It is recomended not to test this patch in a large distributed environment or an environment with many hosts. There is an issue with the transcription of long long integers (64bit) to Lua. Lua treats all numbers as a double double (64bit floating point) which allows for 52 bits of integer data. This should not be an issue for most people uless your hostids or itemids are greater than (2^53)-1. I will be working to solve this issue in a future version.

I think that 2^53 is a very very very big number. I don't think nobody in this planet would have such crazy number of hostids/itemids. To make a easy comparative: all IPv4 addresses (the entire Internet) is only 2^32. I have been reading about the topic and seems that lua can be patched to allow long long integers. But I am not sure if this would be a good idea.

I have tested your new patch and it broke the Lua script that I was using on my Zabbix deployment. The script is the following:

itemid=get_itemid(zbx_host,"VOLTS")
sample=get_last(itemid)
milivolts=sample*(3300/1024)
vwc=2.97e-9*(milivolts^3) - 7.37e-6*(milivolts^2) + 6.69e-3*milivolts - 1.92
vwc=vwc*100
if vwc < 0 then vwc=0 end
return (vwc)

After reading carefully the Zabbix logs and some debugging of the code I realized that you changed the type of itemid from int to zbx_uint64_t withing the function lua_item_get_last() in the file src/libs/zbxlua/zbxlua.c but you forgot to change the checking of the parameter against zbx_uint64_t instead of the previous int. That caused the following error on Zabbix logs:

Lua error: [string "number=uint64(0)..."]:3: get_last expected to receive a number

The following patch solves this problem

--- a/src/libs/zbxlua/zbxlua.c
+++ b/src/libs/zbxlua/zbxlua.c
@@ -295,7 +295,7 @@ int lua_item_get_last(lua_State* L)
                luaL_error(L,"One or more arguments expected");
        }
        
-       if (0==lua_isnumber(L,-1))
+       if (0==is_lua_uint64(L,-1))
        {
                luaL_error(L,"%s expected to receive a number","get_last");
        }

After applying it my script seems to be working back

[nelsonab]

Dude, you freaking rock! I'll integrate and post back a little later.

The main reason for creating the 64 bit unsigned integers was because of distributed monitoring. Distributed monitoring uses the first few digits to denote the node, thus if you have only 20 digits available, and the first 4 of which are taken up by the node id it is theoretically possible that you could hit the 52bit boundary for Lua numbers. And I do hope to improve the chances of getting this included into the mainline one day so to do so I need to fix these design bugs as much as possible.

Well time for the "odometer" to roll over... this makes post #1,000. :-)

[nelsonab]

Attached is Lua patch number 7 for Zabbix 1.8.4.

Feature added:
Parameter passing to Lua scripts
- All items inside the brackets [] are now passed to the Lua script as parametetrs. They can be found in the global variable ARGC and ARGV. ARGC is the argument count, and ARGV is an array (Lua Table) of the arguments. The base index for ARGV is 1.

For example:
key: lua[one,two,three,4,five]
script: return ARGV[3]

Would return "three"

If the above script were changed to "return ARGV[6]" the item would become unsupported as there is no 6th value in the array. Specifically Lua returns a nil value, but Zabbix cannot handle a nil value and thus it is marked as unsupported.

[nelsonab]

I have also been working on updating the Documentation page at:
http://trac.red-tux.net/wiki/lua

[Yello]

Hi,
Is there a 1.8.5 version of this patch?


Regards,
David

[nelsonab]

Not yet, but I'm assuming this means there is an interest so I'll add it to my list. I'm working to get a new version of Zabcon pushed out first so when that's done I'll get to work on this.

[Yello]

Not yet, but I'm assuming this means there is an interest...

I think this would be a powerful enhancment to zabbix so I'd urge you to press on regardless. Eventually, the penny will drop with those not showing any interest if the end result is decent and the utility clearly explained.


Regards,
David

[nelsonab]

Don't worry, when people show interest and use the various patches/utilities I have written it motivates me to improve them. Right now I'm working on pushing out an update to Zabcon. I'm hoping to have that pushed out within the next week.