...

This page describes what mechanisms are available, and how to control them in the GUI, with opreports-cli and for report schedules.

Which selection mechanisms are supported by what report types?

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

...

Note 1. all¹ means All except node_gpon_port_list

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" node_gpon_port_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  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.

...

• 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=<regular expression>, and for scheduled reports you'd specify this with the property  property node_regexp.
The node regular expression is evaluated at report creation time.

The regular expression syntax is Perl's standard, described in detail in this Perl Regexp Tutorial.

Nodes and Interfaces whose names/descriptions match regular expressions

This feature was added to opReports in version 3.1.4.

...

In the GUI this option is called "by Regular Expression for Nodes and Interfaces".
opreports-cli requires that you supply both node_regexp=<regular expression>  and node_intf_regexp=<regular expression> 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

This feature was added to opReports in version 3.1.8.

...

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 feature was added to opReports in version 3.1.8.

...

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=<regular expression> AND node_regexp=<regular expression>  AND node_intf_regexp=<regular expression>.

All three regular expressions are evaluated at report creation time.

Explicitly listed Nodes

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

...

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

Nodes listed in a file

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

...

"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.

...

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

...

• 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  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.

  Code Block
  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

...

...

This is implemented again using a list file, but  but with a very specific format - which has a few inherent limitations; Starting with version 3.0.16, opReports also supports CSV as format for this  type of input.

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

Nodes and specific GPON Ports, listed in a file

Certain GPON Port 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 GPON Port List File (Upload)" and upload the file of choice. For opreports-cli you use node_gpon_port_list=<path to listfile>, and for a scheduled report you would set the property node_gpon_port_list with the value being the path to the list file.

The Node and GPON Port list can be in one of  three formats, JSON, plain text (tab delimited) or CSV (comma delimited):

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

• Plain Text: a text file, one entry per line.

Please note: as of version 3.0.16 it's recommended that you use CSV as a safer alternative to this 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 "_<ifdescr>", 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:

  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.

  Code Block
  { "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.

  Code Block
  testnode 2 14 eth0 othernode Dialer1 testnode 17

  CSV: a csv file, one entry per line.Each entry must start with the node name, followed by one COMMA character, and one or more GPON Ports (again separated by COMMA characters).
  Blank lines and lines starting with the "#" sign are treated as comments and are ignored.

  Code Block
  testnode,2,14,"Service_Port 1/0/9" othernode,"Service_Port 5/0/12" testnode,17

For JSON, Plain Text and CSV formats, GPON Ports can be identified by the numeric SNMP PORT index, or by the SNMP ONTBASE property.

Plain Text Format

Please note: as of version 3.0.16 it's recommended that you use CSV as a safer alternative to this 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 "_<ifdescr>", 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 (3.0.16 and newer)

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:

1. The  node name,
2. the SNMP Interface Index (must be present but may be empty if the Interface Description is given)
3. the Interface Description (must be present but is ignored if an SNMP Interface Index is given),
4. 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:

...

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:

1. 1. TheGPON Portnode name,
   2. the SNMP Interface Index (must be present but may be empty if the Interface Description is given)
   3. the Interface Description (must be present but is ignored if an SNMP Interface Index is given),
   4. 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 specific GPON Ports, listed in a file

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

In the GUI you'd select "from Node and GPON Port List File (Upload)" and upload the file of choice. For opreports-cli you use node_gpon_port_list=<path to listfile>, and for a scheduled report you would set the property node_gpon_port_list with the value being the path to the list file.

The Node and GPON Port list can be in one of three formats, JSON, plain text (tab delimited) or CSV (comma delimited):

• 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 GPON Ports in question.

  Code Block
  { "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 GPON Ports (again separated by TAB characters). If you list a node on multiple lines then all listed GPON Ports will be combined into a single list.
  Blank lines and lines starting with the "#" sign are treated as comments and are ignored.

  Code Block
  testnode 2 14 eth0 othernode Dialer1 testnode 17

  
  

• CSV: a csv file, one entry per line.
  Each entry must start with the node name, followed by one COMMA character, and one or more GPON Ports (again separated by COMMA characters).
  Blank lines and lines starting with the "#" sign are treated as comments and are ignored.

  Code Block
  testnode,2,14,"Service_Port 1/0/9" othernode,"Service_Port 5/0/12" testnode,17

  
  

For JSON, Plain Text and CSV formats, GPON Ports can be identified by the numeric SNMP PORT index, or by the SNMP ONTBASE property.

Nodes and Interfaces that are part of an opCharts Business Service

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:

...

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.

...

Business service memberships are expanded at report creation time.

Related Topics

• How to select Nodes (and Interfaces) for reporting in opReports 3