opReports

All you need to know about network reports that come out of the box.
Download NowBook a Demo

How to select Nodes (and Interfaces) for reporting

In opReports 3.0 the various methods for selecting what to report on have been consolidated and simplified.

Which selection mechanisms are supported by what report types?

Join Paul McClendon, an Opmantek Support Engineer, as he demonstrates quickly and easily you can generate reports using opReports.

Certain reports do have specific requirements which are shown in the table below.

In general, however, providing more precision than necessary is allowed.
For example, you can use a node and interfaces (and even types) list file for all reports; for reports where interfaces are not relevant, the extra information will simply be discarded and just the listed nodes will be used. Reports that don’t need the summary type will simply use the nodes (and possibly the interfaces).

On the other hand, providing insufficiently precise information to reports that require it will result in an error message (e.g. trying to run a summary report with just group=X).

Node Report

Selection Mechanisms: Single node only

Notes: The node report supports a single node only. If your selection contains more nodes, then the report is created for the first listed node.

The Node Report provides a detailed summary of one node. Node details such as status, sysName, ip address, type, model, uptime, interfaces, location, contact, description, last update, vendor, object name, group role and net and the interface table are presented.Interfaces and storage items are details if present. Graphs are provided which details the following: reachability, availability and health, response time, CPU utilisation, number of routes, ip utilisation, IP fragmentation/reassembly (as a % of packets received), buffer utilisation.

Items of note:

  • This report cannot be created for more than one node. If your node selection contains more than one node, then the report is created for the first node in your list.
  • This report relies directly on NMIS for inline graphs, and therefore won’t work unless the configuration item nmis_host_base is correctly set (i.e. has the public web address of your NMIS server).
  • Business Hours reporting is not supported for this report.
  • This report cannot be generated in formats other than HTML.
  • While it can be saved it is not self-contained (the NMIS graphs are live and created on viewing!), therefore it’s primarily of use as an on-demand report for immediate consumption.

 

Node Health Report

Selection Mechanisms: All, interfaces irrelevant

Notes: Interface selections are not relevant for this report.

The Node Health report display health-related attributes for all selected nodes for a given period. Attributes displayed are: Status, Device, Availability, Interface Availability, %CPU, 95th% CPU, Max %CPU, CPU Exc., %Mem Free, 95th% Mem Used, Max %Mem Used, %Mem Util, %IO/VIR Mem Free, 95th% IO Mem Used, Max %IO Mem Used, %IO/VIR Mem Util. As of version 3.1.4 when this report is exported to XLSX and CSV formats the following columns of information are also displayed: Group, %IO Mem Free.

The report also includes two columns with the detected (abnormal) Conditions and the recommended Actions.

If you pass this report the option exceptions=true, then only nodes with exceptional conditions present are shown; the default is to show all nodes.

Below shows the outcome of a default Node Health Report or where exceptions=false.
To create a Node Health Report showing exceptions only, click the box that the arrow points to in the image below.
A Node Health Report using the same devices where exceptions=true looks similar to the image below.

The formulas used for calculation of the reporting conditions can be tuned and adjusted by the user:

The section opreports_rules (in conf/opCommon.nmis in opReports 3.x, or opReports.nmis in version 2.x) defines the threshold values for the following conditions:

Device Availability = Condition: “Device has LOW or VERY LOW availability”

Action: Investigate causes for low availability

Formula used for Calculation:

  • Very Low device availability less than 99.9
  • Low device availability less than 99.999
Interface Availability = Condition: “Device has LOW or VERY LOW interface availability”

Action: Investigate causes for low interface availability

Formula used for Calculation:

  • Very Low interface availability less than 80
  • Low interface availability less than 95
CPU Utilisation = Condition: “Device has VERY HIGH, HIGH or MODERATE CPU utilisation”

Action: Investigate causes for CPU utilisation

Formula used for Calculation:

  • Very High CPU utilisation: greater than 30%
  • High CPU utilisation: greater than 20%
  • Moderate CPU utilisation: greater than 12%

If the node has multiple CPUs then the utilisation measure is averaged over all CPUs.

CPU Exceptions

The count of times the CPU utilisation exceeded the “CPU Exception Threshold” of 20%. If the node has multiple CPUs then this is the sum of the exception counts of all CPUs.

Memory Utilisation = Condition: “Device has VERY LOW or LOW main memory free”

Action: Investigate causes for free low main memory

Formula used for Calculation:

  • Very Low free main memory less than 10
  • Low free main memory less than 25
IO or Virtual Memory Utilisation = Condition: “Device has VERY LOW or LOW IO or Virtual memory free”

Action: Investigate causes for low free IO or Virtual memory

Formula used for Calculation:

  • Very Low free main memory less than 10
  • Low free main memory less than 25
Node Availability Report

Selection Mechanisms: All, interfaces irrelevant

Notes: Interface selections are not relevant for this report.

This report provides an overview of nodes’ reachability and down time for a given period (which may include business days and/or business hours filtering).
For each selected node the report shows the percentage of time the node was up, down, or partially reachable (i.e. up but packet loss was encountered), plus the percentage of time where NMIS couldn’t collect any reachability information whatsoever, as well as the cumulative periods for up, down and periods with missing data.

From version 3.0.10 on this report offers optional embedded graphs of each node’s availability. The default choice is to include graphs but you can change that using the report option embedgraphs. In the GUI this option is named “Include Embedded Graphs”. The contents of the graph are not configurable, but the desired size can be set using the configuration option opreports_embedded_graph_size (default: 600 pixels wide by 150 pixels high).

Configurable Graph Colours

It is possible to set different colors for the node state using hex notation using the following variable:

'report_node_availability_colors' =>
{
'down' => '#d9534f',
'unreachable' => '#e6e619',
'up' => '#59cf59',
'partially_reachable' =>'#288a28'
},
Further Configuration

‘opreports_availability_average_packetloss’ in /path/to/omk/conf/opCommon.nmis, controls whether the previous ‘Packet Loss %’ (now renamed ‘Count Packet Loss %’ ) or ‘Average Packet Loss %’ is displayed in this report.
‘opreports_availability_average_packetloss’ => ‘false’ , the default setting, causes ‘Count Packet Loss %’ to be displayed: This can be interpreted as ‘percentage of readings with some amount of packet loss (Count readings with any packet loss / Number of readings)’.
‘opreports_availability_average_packetloss’ => ‘true’ causes ‘Average Packet Loss %’ to be displayed: This can be interpreted as ”Average Packet Loss (Sum of packets lost / Number of readings).

Grouped Node Availability Report

Selection Mechanisms: All, interfaces irrelevant

Notes: Interface selections are not relevant for this report.

The Grouped Availability Report computes reachability statistics similar to the Node Availability Report, but devices are then categorised based on their overall availability metric; the report shows these results spread over various summary table sections (for HTML output) or work sheets (for XLSX output). Both business days and business hour filtering are supported. The availability categories can be configured flexibly by adjusting thresholds and settings.

A combined total availability metric for all nodes is computed and presented in a summary section, and similar metrics and categorisation device counts for both grouping by Customer and Group (ie. NMIS configuration properties customer and group) are computed and presented. Finally the detailed availability stats are shown for all devices, in order of the devices’ group memberships. Instead of determining an individual devices availability as the Node Availability Report does, the Grouped Availability Report is based on the overall availability metric and gives a summary of the availability of all the devices within a specific group. The summary section displays the number of devices within that group, the number customers within the group, the number of groups and the overall availability of them. The summary section will display devices with availability of 100%, 99 < 100%, 98 < 99%, and < 98% to easily understand if any group of devices has had unexpected downtime. The Grouped Availability Report also displays the Down%, Packet Loss %, No Data %, Uptime, and Downtime for a quick look at overall network health. The Grouped Availability Report can be configured flexibly by adjusting the threshold settings of report_groupedavailability_levels in /usr/local/omk/conf/opCommon.nmis

WAN Report

Selection Mechanisms: All

Notes: It operates on all active or any selected interfaces of the selected nodes whose net type is “wan”.

he WAN report displays the WAN Link performance for selected nodes. Node details displayed are: status, conditions, actions, device, availability and response time.

For each interface on the node, the following are displayed: interface, speed, average utilisation, maximum utilisation, average inbound errors (in %), average outbound errors (in %), average inbound discards (in %), average outbound discards (in %), average inbound utilisation (in %), average outbound utilisation (in %), maximum inbound utilisation (in %), maximum outbound utilisation (in %).
The WAN report health rules are configurable (section opreport_rules) and the report type supports customisable detail levels for the display.

WAN Utilisation Distribution and WAN Utilisation Distribution Summary

Selection Mechanisms: All

Notes: It operates on all active or any selected interfaces of the selected nodes whose net type is “wan”.

The WAN Utilisation Distribution Report displays the combined, input and output utilisation frequency distributions for configured distribution groups. The WAN Utilisation Distribution Summary Report displays only the combined utilisation frequency distribution for configured distribution groups.

QoS

Selection Mechanisms: All

Notes: It operates on all active or any selected interfaces of the selected nodes, if QoS is configured for the interface.

The QoS report is intended to provide an overview of the Quality of Service configuration and utilisation of the selected nodes.

CoS

Selection Mechanisms: All

Notes: For each selected node this report covers all active or any selected interfaces that have Class of Service configured.

The Class of Service report is intended to provide an overview of the Quality/Class of Service configuration and utilisation of the selected Juniper devices.

It presents for each selected Node, Interface and Class, the Policy/Interface Speed, the average Utilisation of the class, the 95th percentile of the class Utilisation, the percentage of dropped bytes and the cumulative Class Usage or traffic.

Level Coloring Options
The report offers configurable level coloring for the utilisation, 95th percentile and drop percentage columns (separately):
The named set of coloring rules is selected in the report scheduling GUI in the Layout tab, under “Level Color Scheme”.

opReports ships with one rule set called ‘default’, and you can configure further sets by editing conf/opCommon.nmis.

Uptime

Selection Mechanisms: All, interfaces irrelevant

Notes: Interface selections are not relevant for this report.

The Uptime Report provides an overview of recently restarted devices, as well as very long running ones.

The configuration items uptime_shortest_days (default 7) and uptime_longest_days (default 365) define which nodes should be selected for display.

Response Time

Selection Mechanisms: All, interfaces irrelevant

Notes: Interface selections are not relevant for this report.

The Response Time report tabulates the selected nodes in descending order of their average response time. Besides the average and maximum measurements, the report also shows the 95th percentile of the response time. These readings are in milliseconds.

Interface Capacity

Selection Mechanisms: All

The interface capacity report displays a comparison between configured interface speeds and observed actual bandwidth figures.

For each selected interface, it shows the configured input and output speeds, the observed maxima of input and output bandwidth for the report period, and the 95th percentile of the interface utilisation.
Before version 3.0.14, the 95th percentile for combined interface utilisation was shown (Combined utilisation in this report means the set of averages of each input and output utilisation reading). From 3.0.14 onward, you can select from three options: the 95th of combined utilisation, two separate columns for 95th of input and output utilisation, or three separate columns for 95th of input, output and combined utilisation.

In the HTML output format all interface speed and bandwidth figures are auto-scaled and shown with the most appropriate unit, whereas CSV and XLSX outputs contain the unscaled data in bits per second.
From version 3.0.10 on this report offers optional embedded graphs of each interface’s capacity. These graphs show the observed input and output bandwidth (input in green, output in blue), and the higher of the configured in and out speeds as a red warning line. If the configured input and output speeds are identical, the 95th percentile of the combined interface utilisation is also shown as a dotted line.

Grouped Interface Capacity

Selection Mechanisms: All

The Grouped Interface Capacity Report displays a comparison between configured interface speeds and observed actual bandwidth figures.

Statistics are shown for all devices in order of the devices’ Group Membership (ie. NMIS configuration property ‘group’).

To setup, choose Grouped Interface Capacity Report under Create New Report >> General >> Type

Interface Utilisation

Selection Mechanisms: All

Notes: Interface selections are honored but the “type” component (in selections by node+interface+type) are ignored as not relevant.

The interface utilisation report shows the interface utilisation statistics for one or more interfaces. By default it will display the averages for input, output, combined and higher-of-in-and-output bandwidth utilisation, as well as exception counts and cumulative exception period.

Exceptions are defined as any of the utilisation readings rising above option util_threshold (default: 80%). The exception period is defined as all the intervals with over-threshold readings. In addition to those raw readings, the labeling of an interface as in exceptional or normal state is controlled by option util_threshold_mincount (default: 1), which defines how many exceptions have to be observed before the interface is labelled “bad”.

This report can be further adjusted with these options:

  • Option show_threshold (default: true)
    • If set to false, no thresholds are shown; instead the bandwidth, average traffic and average utilisation are presented (plus a shortened report period column).
  • Option show_only_util (default: false)
    • If show_treshold is false, and if show_only_util is set to true, then only bandwidth and average utilisation are shown (i.e. average traffic is omitted).
Interface Unicast packets

Selection Mechanisms: All

Notes: Interface selections are honored but the “type” component (in selections by node+interface+type) are ignored as not relevant.

The Interface Unicast Packets report displays the ifInUcastPkts and ifOutUcastPkts statistics for one or more interfaces.

To Create this report choose Interface Unicast Packets Report under Create New Report >> General >> Type

CPU Report

Selection Mechanisms: All, interfaces irrelevant

Notes: Interface selections are not relevant for this report.

This report shows the average CPU utilisation for Cisco devices, for both 1-minute and 5-minute averages.

Free Memory Report

Selection Mechanisms: All, interfaces irrelevant

Notes: Interface selections are not relevant for this report.

This report shows the free memory statistics for Cisco devices.
The example image shows the average free Memory Proc and the Average Free Memory IO.

Memory Pool Report

Selection Mechanisms: All, interfaces irrelevant

Notes: Interface selections are not relevant for this report.

This report shows the memory pool statistics for Cisco devices.
The example image shows the average free Memory Proc and the Average Free Memory IO.

Memory Buffer Report

Selection Mechanisms: All, interfaces irrelevant

Notes: Interface selections are not relevant for this report.

Link: here

Monitored Services Report

Selection Mechanisms: All, interfaces irrelevant

Notes: Interface selections are not relevant for this report.

The Monitored Services Report can only be configured via View >> Report Schedules >> Create New Report and cannot be run on-demand.

This report provides an overview of monitored services availability and downtime both for a given period (which may include business days and/or business hours filtering) and as a percentage of the given period.
For each selected monitored service the report shows the percentage of time the monitored service was up, down, or partially reachable (i.e. up but packet loss was encountered) as well as the cumulative response time as measured by NMIS while monitoring the service.

Traffic Usage Report

Selection Mechanisms: All

Notes: Interface selections are honored but the “type” component (in selections by node+interface+type) are ignored as not relevant.

This report displays the cumulative traffic usage figures for one or more interfaces. The measurements that are displayed include the node and the interface, and total traffic inbound, outbound and combined (all in Gigabytes), plus a shortened report period column.

Traffic Summary Report

Selection Mechanisms: node+interface+type

Notes: This report strictly requires this specific selection format

The traffic summary report provides a specialized report of categorized and grouped traffic figures for any number of nodes and interfaces.

This report requires a node_intf_type input file that provides nodes, interfaces and “type” for grouping (see How to select Nodes (and Interfaces) for reporting).

The interfaces are grouped both by their “type” attribute and their average combined utilisation (into categories Low=<45%, Minor=<80%, and Major=>80%).

The report consists of

  • A summary table, which displays for each “type” category the number of interfaces in each utilisation category (and a total)
  • And a details table for each combination of “type” and utilisation categories.
  • The details table shows the node and interface, the input and output interface speeds, the average combined traffic and the average combined utilisation, plus a shortened period column.
  • For output formats HTML and CSV these tables are shown one after the other. For XLSX, the tables are put on separate worksheets (within a single spreadsheet file).
Traffic Snapshot Report

Selection Mechanisms: opCharts Business Services, selected per page.

Notes: This report type strictly requires lists of Business Services for each of its (multiple) page definitions.

The Traffic Snapshot report requires a deep structure to describe each of its multiple pages.

Each page covers the (interface) members of one or more opCharts Business Services; utilisation data is computed and shown for all members of a business service combined, but graphs are presented for each interface separately.

Choosing the selection mechanism for scheduled reports

For scheduled reports your schedule must contain a property named sources, with one of the following values: “everything”, “group_each_regexp”, “group_regexp”, “node_regexp”, “node_group”, “nodes”, “node_list”, “node_intf_list”, “node_intf_type_list”, or “business_services” (in 3.0.14 an newer). Those mechanisms are described below.

If you use the opReports schedule editing GUI then this property will be managed on your behalf.

The Simplest Choice: Everything

If you do not make an explicit selection, then opReports will work on all active nodes (and all their active interfaces, for report types that handle interfaces).

In the GUI this choice is shown as “All Active Nodes”.

Nodes that belong to a specific group

In NMIS every node belongs to precisely one group, and this concept therefore applies to opReports as well.

With opreport-cli you have to give the argument group=. In a report schedule this is expressed using the property node_group. In the GUI this choice is presented as “by Group”.

There are two “wildcard” groups available:

  • Group “All” is equivalent to the default choice, all active nodes. This wildcard should not be used as we will likely retire it in a future version of opReports.
  • Group “Each” is available for scheduled reports only, excluding ‘once only’ scheduled reports, and causes the generation of a separate report for each of the known groups.

Nodes whose name matches a regular expression

In the GUI this choice is called “by Regular Expression for Nodes”, opreports-cli uses the command line argument node_regexp=, and for scheduled reports you’d specify this with the property node_regexp.
The node regular expression is evaluated at report creation time.

Nodes and Interfaces whose names/descriptions match regular expressions

Nodes must match the regular expression given for the node name, but interface descriptions must also match a separate regular expression.
Only those interfaces are selected where both regular expressions match.
However, for reports where interfaces are not relevant, interfaces are disregarded.

The regular expression for interfaces is applied to both the interface’s ifDescr and Description properties in parallel, and a match for either or both selects the interface.
(The NMIS GUI presents ifDescr as “Name” or “Name (ifDescr)”. Depending on the device and its modelling ifDescr may or may not be adjustable, but Description can be set easily within NMIS.)

In the GUI this option is called “by Regular Expression for Nodes and Interfaces”.
opreports-cli requires that you supply both node_regexp= and node_intf_regexp= arguments.
The report schedules use the same property names as the opreports-cli parameters.

Both regular expressions are evaluated at report creation time.

Groups, Nodes and Interfaces whose names/descriptions match regular expressions

Groups must match the regular expression given for the group name AND
Nodes must match the regular expression given for the node name AND
Interface descriptions must also match a separate regular expression.

Only those interfaces are selected where all three regular expressions match.
However, for reports where interfaces are not relevant, interfaces are disregarded.

The regular expression for interfaces is applied to both the interface’s ifDescr and Description properties in parallel, and a match for either or both selects the interface.
(The NMIS GUI presents ifDescr as “Name” or “Name (ifDescr)”. Depending on the device and its modelling ifDescr may or may not be adjustable, but Description can be set easily within NMIS.)

In the GUI this option is called “by Regular Expression for Groups Nodes and Interfaces”.
opreports-cli requires that you supply group_regexp= AND node_regexp= AND node_intf_regexp= arguments.
The report schedules use the same property names as the opreports-cli parameters.

All three regular expressions are evaluated at report creation time.

Groups, Nodes and Interfaces whose names/descriptions match regular expressions for separate report for each group

This option causes the generation of a separate report for each of the known groups.
This option is available for scheduled reports only, excluding ‘once only’ scheduled reports.

Groups must match the regular expression given for the group name AND
Nodes must match the regular expression given for the node name AND
Interface descriptions must also match a separate regular expression.

Only those interfaces are selected where all three regular expressions match.
However, for reports where interfaces are not relevant, interfaces are disregarded.

The regular expression for interfaces is applied to both the interface’s ifDescr and Description properties in parallel, and a match for either or both selects the interface.
(The NMIS GUI presents ifDescr as “Name” or “Name (ifDescr)”. Depending on the device and its modelling ifDescr may or may not be adjustable, but Description can be set easily within NMIS.)

In the GUI this option is called “by Regular Expression for a Nodes and Interfaces Report per Group”.
The report schedules requires that you supply group_each_regexp= AND node_regexp= AND node_intf_regexp=.

All three regular expressions are evaluated at report creation time.

Explicitly listed Nodes

In the GUI this choice is called “Pick from Node List”.

To use this mechanism with opreports-cli, you have to list each node you want in a separate nodes= argument.

In a report schedule the property nodes would have to be set to an array of node names, like in this example:

"nodes" : [
  "ASGARD",
  "midgard"
],

Nodes listed in a file

opReports expects a node list file to contain one node name per line. Whitespace before or after the node name is removed.

In the GUI this choice is called “from Node List File (Upload)”, and you need to select a suitable file for uploading.

For opreports-cli, the command line argument node_list= would be used. In that case the node list file must already reside on the opReports server.

In a report schedule definition, you’d use the property node_list, with the path to the list file as value:

node_list" : "/tmp/my_list_of_lotsa_nodes.txt

Nodes and specific Interfaces, listed in a file

Certain reports allow a more precise selection of nodes and just some of their interfaces. This is implemented using a list file.

In the GUI you’d select “from Node and Interfaces List File (Upload)” and upload the file of choice. For opreports-cli you use node_intf_list=, and for a scheduled report you would set the property node_intf_list with the value being the path to the list file.

The node and interface list can be in one of two formats, JSON or plain text:

JSON: it must be a valid JSON document, consisting of a hash of the node name as key, and the value being a list of the interfaces in question.

{ "testnode": [ "eth0" ], "othernode" : [ 1, 2, "Tunnel20" ] }

Plain Text: a text file, one entry per line.
Each entry must start with the node name, followed by one or more TAB characters, and one or more interfaces (again separated by TAB characters). If you list a node on multiple lines then all listed interfaces will be combined into a single list. Blank lines and lines starting with the “#” sign are treated as comments and are ignored.

testnode   2   14    eth0
othernode  Dialer1
testnode   17

For both JSON and Plain Text formats, interfaces can be identified by the numeric SNMP interface index, or by the SNMP ifDescr property.

Nodes, specific Interfaces and Types, listed in a file

Certain reports offer a refinement of the above, with the added notion of a “Type” for grouping of Node+Interface into particular reporting classes.
This is implemented again using a list file, but with a very specific format – which has a few inherent limitations.

The relevant GUI choice is called “from Node, Interfaces and Type List File (Upload)”, for opreports-cli the parameter is node_intf_type_list=, and in a report schedule the controlling property is node_intf_type_list (value again the path to the list file).

Plain Text Format

The list file format is plain text, and each line must consist of precisely one node name, one of its interfaces and a “type” declaration. The interface must be identified by its SNMP Interface Index.

Node name and interface must be separated by “_”, and this must be separated by the “type” by one or more spaces, like in the example below:

nodeA_1 groupA
nodeB_41 groupB
nodeC_41_eth0 groupB

The example also shows an optional format variant: the node+interface stanza may include a trailing “_”, but the interface description is not used for the selection logic: only the SNMP Interface Index is relevant. It is recommended that you do not use this flavour as it’s ambiguous: interface descriptions can (and often do) include both _ and space characters.

The “type” will be used to group all nodes and interfaces with the same type value into a group for summary reporting.

CSV Format

opReports now also supports CSV (with comma as the separator character) for this kind of input.
The lines in your file must contain at least the following four columns, in the following order:

The node name,
the SNMP Interface Index (must be present but may be empty if the Interface Description is given)
the Interface Description (must be present but is ignored if an SNMP Interface Index is given),
the “type” declaration.
Extra columns are ignored; files with fewer columns are rejected. Empty lines and comment lines (ie. lines starting with a “#” character) are ignored.

For extra convenience you may now also specify interfaces by their Interface Description instead of the Interface Index; both columns must be present in your input, but one of them may be blank.
The SNMP Interface Index is considered authoritative, if given. If it is not, then opReports looks for an interface with the given Interface Description. Nonexistent interfaces are skipped, and a warning message is logged.

Here is an example CSV file:

# comment, ignored. columns: nodename,interface index,interface description,type name
"some node","1","FastEthernet0/0","categoryA"
"not_the_greatest_name","10","Dialer1","catB"
"pleasefindme",,"Dialer1194","categoryA"
"iknowtheindex",12,,"catB"

Nodes and Interfaces that are part of an opCharts Business Services

If you have opReports version 3.0.14 and newer and opCharts is installed on the same system, then you can make use of Business Services to declare nodes and interfaces for reporting.

Configuration

The following three configuration options (in conf/opCommon.nmis) are vital for opReports accessing opCharts:

# base of opCharts server url, eg http://localhost or http://localhost:80 - no slash at the end
'opreports_opcharts_url_base' => "http://127.0.0.1:8042",
'opreports_opcharts_user' => "nmis", # opreports needs a user with readonly-access
'opreports_opcharts_password' => "nm1888",

If you’ve changed the password for the default nmis user (or disabled it altogether), then these configuration items need to be adjusted accordingly.
Once that’s done you need to restart the OMK webserver (using sudo service omkd restart) to activate the changed configuration.

Usage

In the GUI you will be presented with a list of known Business Service names, which supports multiple selections.

When using opreports-cli, the parameter is called business_services and you need to pass in each business service name separately, e.g. opreports-cli.pl type=health business_services=first_service business_services=second_service.

In a report schedule file, the property is called business_services and its value must be a list of business service names.

Business service memberships are expanded at report creation time.

Who We Work With

Ready to Take the Next Step?

See the Power of our Network Solutions in Action

OMK-Book-a-Demo_1