Kaseya Community

How do you modify the LUA scripts in KNM?

This question has suggested answer(s)

I am using KNM to monitor the health of my VMWare hosts, using a LUA script called wbem_esxi_health_.lua that came with the product.

For one server I am getting a response of "Alarm: Unacceptable State detected Controller battery status Battery on HPSA1 - Unknown state".  We have checked the battery and everything is OK so Im putting it down to some sort of compatibility issue.  

I was thinking of looking at the LUA script to see if I can remove a reference to the battery, but I cant see where/how you find/modify/save LUA scripts in KNM.

Can someone please help me here?

Thanks

David

All Replies
  • - All Lua scripts are stored in the kaseya\knm\script directory.

    - To help you make changes to Lua scripts, we provide the Lua IDE, a development environment that can be used run scripts just like they where running in KNM, speeding up development and testing (help.kaseya.com/.../index.asp)

    - In case you do no longer need to use a script (its kept around for legacy reasons) , since the script was made we have introduced a dedicated CIM monitor that can do this much better (help.kaseya.com/.../index.asp)

    Hope this helps!

  • Hello Ra,

    We have a similar issue and we modified the LUA script for our purpose.

    Is there any way to modify (add a where clause) to the CIM Query that is executed?

    The issue we have with the CIM indicator you proposed to use,

    is that it is either all or nothing or based to a SINGLE instance.

    Without that functionality the only way is to go for LUA

    (or have to create a HUGE list of CIM indicators, one for each one of the monitoring needed).

    Example:

    Let's say one runs VMWare and only wants to monitor physical host disks health but I am not interested in FAN health or Memory Banks ECC fails.

    The typical CIM Indicator one could use for a Dell Host in VMWare (5.1) is the OMC_DiscreteSensor Class (same indicator used by VCenter with Open Manage vbi installed).

    Now if I could modify the Query I would say: "Where name like "%Drive%"

    I would only get the list of Physical Host Drives and not a million indicators returned by the Class.

    Sure, I could filter the instance but I only can take one and it would be based by DeviceID (that could be different from each host). This would result into an unmanageable number of Monitor lists.

    Hence LUA is currently the only way to do it quickly and the suggested CIM way is not good enough.

    That is unless there's a way to add something to the CIM query in which case I would stand corrected.

    Let me know., I would be very happy to resolve it using CIM as maintaining LUA scripts is definitely more complex.

    Thank you.

  •  

    If I understand you correctly, you want to be able to use a base class, enumerate that and filter it based on a property, for example "SensorType=2" and use the resulting list as a base for further testing (?)

    I can also mention (for anyone else that reads this post) that based on users feedback from the past we have added the ability to monitor one or all instances of a class, and also provided a number of different ways to handle the properties read from the instances, as seen in these two screen shots below.  



    edit
    [edited by: RA at 6:47 AM (GMT -8) on Mar 1, 2016]
  • Hello Ra,

    That's exactly what I was talking about and it is why CIM Indicators cannot be used effectively to resolve David Problem.

    It is either ONE or ALL.

    LUA script is the only sane solution until there's a way to modify the CIM query but not with a Simple: Sensor = 2. I need to pick up a property and say RETURN only INSTANCES WHERE property = like > Expression.

    Basically a way to modify the SQL passed to the CIM Class select (it should be extremely easy to implement as it is basically a text to be concatenated to your CIM Select, but I see no such function currently.).

    Until then, the above example you have illustrated will not be suitable for many classes.

    The OMC_DiscreteSensor I was mentioning in my previous message is a good example of where the CIM will not work effectively (too many sensors at the same time or too little).

    Unless this feature is available, people have to revert to LUA script like we are doing despite we would love to use CIM indicators.

    Thank you.

  • I've added a feature request for this in the backlog.