Monitoring

Monitoring variables

Each monitoring script has its own execution environment. It means that writing a lua variable will not be visible from another monitoring script.

In addition to the individual environment the Monitoring engine adds several tables where to read and write other variables.

• system: this table holds all system variables. Usually those variables are used in read only.
• user: this table holds all the user defined variables.
• global: this is a non-monitored table. It can be use to store static data.
• persist: this is a non-monitored and persisted table. It can be used to store data that will survive reboots.

Monitoring variables access

Let's say that in the following examples we want to get the Cellular RSSI value.

in a script:

In a script all variables can be accessed in a natural Lua way.

local rssi = system.cellular.rssi

using Data Reading:

M3DA ReadNode command can be used to read any varaible.

Command name: ReadNode
Command path: @sys
Command arg#1: monitoring.system.cellular.rssi

in Agent context:

In a global Lua environement (in Agent code or in the Lua shell attached to the Agent).

local rssi = Monitoring.vars.system.cellular.rssi

System variables

The following system variables are available, depending on what the different hardware may provide.

Cellular

Power

Memory / CPU

NetworkManager

Monitoring Script Engine API

install(name, script, autoenable)

Install a new monitoring script.
name is the name identifying the monitoring script
script is the script content as a Lua string
autoenable when set to true (i.e. non false value), the script is installed and will be automatically enabled on next Agent boot.
when set to "now", the script is started right now, but not installed nor enabled (test purpose),
when set to false value, the script is installed but not enable for the next Agent boot,
when set to nil (or absent), the enable flag will stay unchanged (meaning equal to the flag of a script that was installed with the same name)

uninstall(name)

Uninstall an installed monitoring script.
name is the name identifying the monitoring script to uninstall

uninstallall()

Uninstall all installed monitoring scripts.

enable(name)

Enable an installed monitoring script: the script will be started on next Agent boot.
name is the name identifying the monitoring script to enable

disable(name)

Disable an installed monitoring script: the script will not be started on next Agent boot.
name is the name identifying the monitoring script to disable
Note: The script remains installed

registerextvar(var, pushenable, getvar, varlist)

This function allows to add additional variables in the monitored tables
pushenable and getvar are functions.
pushenable will be called by the monitoring engine in order to enable asynchronous mode
getvar will be called if asynchronous push mode is not enabled and the variable is read.
varlist argument must be provided only when registering group of variables. varlist must be either a table (array) that list the names of the variables, or a function that returns that table.
When successful, this function returns the table that holds the monitored variable or group of variables
notes:
if pushenable is a string or a number, then getvar is ignored and the value of pushenable is set as a static value into the monitoring variable table
pushenable and getvar can be equal to nil, restricting the usage of that variable, according to what is nil
var can actually a path designating a group of variables, in that case it must have a trailing '.'. ex 'system.cellular.'
the actual tables will be automatically created by this function
pushenable and getvar, when defined as functions will be called with two parameters: the path, and the variable name. pushenable may be called with a nil variable name, meaning the pushenable is on the whole group (=path) of variable.