...
A job file must consist of one "hash" datastructure, with the following properties:
| Property | Example | Description |
|---|---|---|
type | "util" "wan" | The report type to generate. Required. See the opReports Report Descriptions for a list of available types. |
| active | "true" or "false" | Whether this schedule is active or not. Only active schedules can create new reports, inactive schedules are consulted only for pruning of old report data. If active is not specified, then the schedule is inactive. |
| description | "some text" | A free-form description of the scheduled job. Optional. |
| frequency | "daily", "weekly", "monthly" or "yearly" | Not present for one-off reports. |
| start | "1-14-2015 20:00:00", "mon 10:30", various others depending on the frequency | The date + time the report collection is to start at. Required. |
| end | The date + time the report collection is to end at. Same format as start. | |
| from | 13 or any integer between 0 and 24 | Start of Business Hours reporting. Optional. Default: 0. See the Formats for Report Periods and Frequencies page for details. |
| to | End of Business Hours reporting. Optional. Default: 24. | |
| node_intf_list | /some/where/some.file | The file describing the nodes and interfaces to collect. See section below for format. |
| util_threshold | 80 | The desired interface utilisation threshold value (in percent), default: 80 (percent). |
| util_threshold_mincount | 1 | The desired minimum number of threshold exceedences for flagging the interface as over-limit, default: 1. |
format
| either a single hash with the keys "html", "csv" or and "xlsx", or a list like [ and values true/false or 1/0. e.g. { "html":0, "csv": true, "xlsx" ]: false} | The formats the report should be saved in. |
| outputdir | /some/where/ | Where the report should be saved. This has to be a full path pointing to a directory. It is suggested that you either use a directory under /var (or /data if you use the Opmantek Virtual Appliance), or /usr/local/omk/var/reports. GUI-scheduled reports will always use one of the configured directories (see opreports_output_dirs in opCommon.nmis), and it is recommended that you use only these even if editing schedule files by hand.Every report schedule can use a different output directory. |
| naming | "simple" or "precise" | What naming scheme should be used for the output files. Default is "simple". Mainly important if you plan to manually work with saved report files. |
sourcesand (at most) one of node_list, node_regexp, node_group, node_intf_list or node_intf_type_list | "everything" | See How to select Nodes (and Interfaces) for details. |
| keep_for | 47 | How many days to keep an old report instance. If set to zero, the report is not expired. If not set, then the defaults for the report type are applied (configuration entry "default_report_keep_for"). |
| options | { "title" : "My Custom ReportTitle" }
| Optional settings. Some are specific to particular report types. See the section on Optional Settings below. |
| control_nmis | "true" or "false" | Whether NMIS should be "remote controlled" or left in peace. See section on Remote Controlling NMIS below. Only relevant for one-off reports. |
| nmis_options | "mthread=true maxthreads=15" | Options to be given to |
| target_audience_group | "HQ" | If present and a known NMIS group name, then the generated report can be viewed only by users who are members of this group (and the administrator). If not present then report viewing is not limited to particular groups. |
Besides these user-definable properties, the scheduler also manages certain others for internal use, and you should not modify these! (Currently these include the properties "uuid", "in_progress", "completed" and all properties named "actual_<something>".)
...
- When the job starts, NMIS is reconfigured with
global_collecttrue and with ONLY the wanted nodes and interfaces (identified by the node_intf_list file) set tocollecttrue. All other interface collection activity is disabled withglobal_nocollect_ifDescr. Annmis.pl type=updaterun will then be performed, and the NMIS data collection commences as normal. - When the job completes, NMIS is disabled, with
global_collectset to false. - This clearly interferes with recurring schedules and should therefore only be used in isolation.
As of version 3.0.2 some limitations apply for this feature:
- The NMIS remote control feature is not supported for recurring report schedules, only for one-off reports.
- The only possible extra action to take at the beginning of a job is enabling NMIS and setting the listed interfaces and nodes for collection.
Optional Settings
The options property can hold sub-properties that fine-tune opReports' behaviour. There are a few common options that are shared by all reports:
...
| Option | Description |
|---|---|
| show_threshold | Default: true. If this is false, then no over threshold counts and exceptions are shown. Instead the interface bandwidths, traffic, utilisation and short report period are shown. |
| show_only_util | Default: false. Ignored if show_threshold isn't false. If this is set to true, then opReports omits the bandwidth and traffic columns and shows only the utilisation (and short period). |
| util_threshold | Default: 80 (%). Defines the level of utilisation above which it counts as exception. |
| util_threshold_mincount | Default: 1. How often the interface utilisation has to be above the threshold value for the interface to be flagged as in exceptional state. |
Limitations
As of version 3.0 this feature is considered stable but some limitations exist:
...
| . |