Table of Contents |
---|
NMIS code plugins are meant to augment and extend the update and collect functionality, if and when classic modelling doesn't suffice to handle a
particular scenario.
Each plugin must be valid perl, be named X.pm, must have a 'package X;' line, and its package name must not clash with the other NMIS components. the plugin MUST NOT use Exporter to export anything from its namespace.
It's recommended that the plugin have a version declaration right after the package line, i.e. 'our $VERSION = "1.2.3";'
The plugin may load extra perl modules with use or require, but it must not use any package-level global variables. all its variables and any objects that it might create must have local scope.
A plugin can offer one or more of the functions update_plugin(), collect_plugin() after_update_plugin() or after_collect_plugin().
...
- (0 or undef,rest ignored) means no changes were made, or that the plugin declined to run altogether (for example, because the environment doesn't match the plugin's needs
- (1,rest ignored) means changes were made to the sys object, and nmis should save the nodeinfo and view components.
- (2,list of error messages) means the plugin failed to work and NMIS should please log the error messages. no nodeinfo/view saving will be performed.
How to access the information in NMIS9
Nodes
We can access the node object using the object sys:
Code Block |
---|
my $node_obj = $S->nmisng_node |
Collected Data - As Interfaces
We All the collected data is saved in a new structure called inventory. We can use as many filters that we need:
Code Block |
---|
my $host_ids = $node_obj->get_inventory_ids(
concept => "Host_Storage",
filter => { historic => 0 }); |
Log
We can log any message by using the NMISNG object:
Code Block |
---|
$NG->log->info("Working on $node Host Memory Calculations"); |
Example
You can see a complete example of a collect plugin in the Host_Resources plugin (Released in 9.1.2).