NXSL improvements

Started by Victor Kirhenshtein, January 28, 2010, 01:23:12 AM

Previous topic - Next topic

borislavl

Hi Victor,

Here as resume are some NetXMS feature requests, which will improve the management functionality to a point where almost everything can be accomplished using the NXSL:

1. Export for the NetXMS actions, event processing rules and script library
2. Or backup of the entire server configuration
3. Actions to be able to return a value(response from the command) to a specified DCI.
4. Or to call action from NXSL and receive/not receive value as response
5. From NXSL to be possible to set DCI values (activating their Thresholds as configured)
6. Updated version for the DRBD subagent

What do you think?


Thank you,
Boris

Victor Kirhenshtein

Hi!

Quote from: borislavl on March 17, 2010, 09:07:06 PM
1. Export for the NetXMS actions, event processing rules and script library

Agree.

Quote from: borislavl on March 17, 2010, 09:07:06 PM
2. Or backup of the entire server configuration

In fact, you can do this by backing up database or exporting it using nxdbmgr. If you wish to backup only server configuration without collected data, you can just skip idata_xx, event_log, alarms, snmp_trap_log, and audit_log tables.

Quote from: borislavl on March 17, 2010, 09:07:06 PM
3. Actions to be able to return a value(response from the command) to a specified DCI.

How this is different from DCI with external parameter as a source?

Quote from: borislavl on March 17, 2010, 09:07:06 PM
4. Or to call action from NXSL and receive/not receive value as response

I'm not sure that this is needed in DCI transformation and event filtering scripts. Main concern here is performance - for example, if event filtering script calls external action and waits for it's completion, it potentially could block event processing for significant amount of time.

Quote from: borislavl on March 17, 2010, 09:07:06 PM
5. From NXSL to be possible to set DCI values (activating their Thresholds as configured)

Could be implemented, but probably for "push" DCIs only (I mean allow to set value only for push DCIs).

Quote from: borislavl on March 17, 2010, 09:07:06 PM
6. Updated version for the DRBD subagent

This is one of priority changes - we have support request for this, so it should be ready soon.

Best regards,
Victor

borislavl

Victor, thank you for your quick reply and willingness to improve the NXSL flexibility.

Quote from: Victor Kirhenshtein on March 18, 2010, 10:23:36 AM
Quote from: borislavl on March 17, 2010, 09:07:06 PM
3. Actions to be able to return a value(response from the command) to a specified DCI.
How this is different from DCI with external parameter as a source?
The differences are that the External Parameter can be attached to a DCI (collected on a period), but not to the event processing policy. If trying to create management workflow in NXSL - it is needed on some events to execute action, which result to trigger a second event and action on the local server. On the Linux servers this can be done with 2 nested nxpush executions (the result from the first nxpush is being pushed back to the local server from the second nxpush), but on the Windows servers this become complicated, because of the restrictions of the Win cmd shell.

Quote from: Victor Kirhenshtein on March 18, 2010, 10:23:36 AM
Quote from: borislavl on March 17, 2010, 09:07:06 PM
4. Or to call action from NXSL and receive/not receive value as response
I'm not sure that this is needed in DCI transformation and event filtering scripts. Main concern here is performance - for example, if event filtering script calls external action and waits for it's completion, it potentially could block event processing for significant amount of time.
I understand your concerns here, I was looking for such functionality in the scripts library, so when one action with parameter %[script] is executed - to be possible to execute another action before it and pass the result to the main action. Or based on the logic in the script to execute one or more actions.
At the moment if the logic is straight forward - this can be done with multiple lines in the Event Processing Policy, different scripts which return 1 or 0 (execute/not execute) and different action on each line.
Or one action which calls a script in the OS shell and there nxget and nxpush to be used as communication with the variables (DCI).

Quote from: Victor Kirhenshtein on March 18, 2010, 10:23:36 AM
Quote from: borislavl on March 17, 2010, 09:07:06 PM
5. From NXSL to be possible to set DCI values (activating their Thresholds as configured)
Could be implemented, but probably for "push" DCIs only (I mean allow to set value only for push DCIs).
This would be great. Even in "push" DCIs - it will be useful.
At the moment the alternative is to do actions which are calling the shell command nxpush, but if this can be done direct from the script - it will be much easier.