...
Historically opReports has relied solely on being run on demand via the GUI (deprecated in opReports 4.3.1) or command line (or periodically with cron). In version 3.0 we've added another feature that extends these capabilities: the opReports Scheduler. The scheduler is meant to act a bit like a combination of "cron" and "at" (a venerable but not especially well known Unix tool, companion of cron) for opReports.
...
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. | |
| exclude | "fri-sun", "sat-mon" | Business week selection. Optional, supported in opReports 3.0.8 and newer. |
| 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 | a hash with the keys "html", "csv" and "xlsx", 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. 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. See the section on Output File Naming below for details. |
sourcesand (at most) one of group_regexp, 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>".)
...
Recurring jobs are processed repeatedly, as soon as the scheduler determines that the end of the report period for that schedule is past.
One-Off Reports ( One-Off Reports are generated using the Create one-off Report button in opReports 4.3.1 and newer )
A one-off job is normally processed exactly once, as soon as the report period has passed. The job is then marked completed and will not be (re)generated.
...
The Utilisation report recognizes the following four options:
| 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. |
The Traffic Snapshot report recognizes the following two global options, and numerous report-specific settings.
| Option | Description |
|---|---|
peak_type | One of combined, busiest_bits or busiest_util. Default is combined.Combined: The peak utilisation for the interface group is defined as the sum of all involved interfaces' traffic. Busiest by Bits: The peak utilisation is sourced from the one interface with the highest traffic figure. Busiest by Utilisation: The peak utilisation is sourced from the one interface with the highest ratio of traffic to configured interface capacity. |
capacity_type | One of |
Report-Specific Settings
For Traffic Snapshot reports, please check the Traffic Snapshot Report detail page.
...
- The file name auto-generation logic only affects the basename of the file; extensions are always set to
.jsonfor the report metadata file and.html,.csvand.xlsxfor the different output formats. - Please note that any graph files associated with a report are not subject to this naming scheme; those names are completely dynamic and can be determined only by analysing the report metadata file.
- On-demand reports generated from the GUI allow the user to supply the 'report name', and if that is present then it'll be used for the file names (but subject to de-clashing as outlined below).
If no report name is supplied, then On-demand reports are treated like scheduled non-recurring/one-off reports. - All file names may be amended with a number if a clashing file already exists, e.g. "some_report.3.xlsx" and "some_report.4.xlsx" may be generated.
- All file names are adjusted to replace certain characters: all spaces and ":" are replaced by "_".
- Depending on the report frequency, the following components are used to build the file name:
Frequency | Simple Naming | Precise Naming |
|---|---|---|
| any | first the report type, then a "_" | same as simple |
| any | n/a | if the report schedule selects nodes by group: the group name and a "_" |
| one-off | the start and end times in ISO8601 format, separated by "_" and followed by a "_" | same as simple |
| daily | 'daily_', then the start and end times in the original format, separated by "-", | same as simple |
| weekly | the abbreviated start date's month name suffixed with the day of month, a "-", | 'weekly_', the start and end date/times in the original format separated by hyphen (e.g. Tue_00-Fri_14_45 after space removal), a "_", |
| monthly | the abbreviated month name of the end date, a "_", then the four-digit year | 'monthly_', the start and end dates/times in the original format separated |
| yearly | 'yearly_', the start and end dates in the original format separated by hyphen | same as simple |