Domain-IfAlias Data Storage How-To

From OpenNMS
Jump to navigation Jump to search

'

Introduction

This article explains how to configure Snmp data collection to store interface data by the optional domain/ifAlias method.This method provides advantages for managing data storage in an environment of distributed management and frequent adds, moves, and changes. It is assumed that the reader is already familiar with basic data collection configuration. If not, see Data_Collection_Configuration_How-To. For a more detailed discussion of the use case for domain/ifAlias data storage see Data_Storage_and_Display_Options. This feature is available beginning with release 1.3.2.

Domain

The term domain as used here describes any logical grouping of network switches and/or routers based on functional or administrative considerations. Examples would be 1) One or more switches providing network connectivity to a group of servers at a server farm. 2) one or more routers connecting a group of remote sites to a central facility.

IfAlias

IfAlias refers to an administrator-assigned name for an interface on a network device such as a switch or router. The ifAlias for an interface may be set via SNMP or through a management interface on the network device. For the example domains listed above, ifAliases might be 1) the names of the servers at the server farm, or 2) the names of the remote sites or their circuit IDs. See ifAlias for more information.

Use case

Network Environment

Since OpenNMS is intended to be an enterprise management solution we can make the following observations.

  1. The enterprise may consist of several separate internal organizations or departments with varying degrees of autonomy.
  2. Technical personnel who manage and configure network nodes such as switches and routers may or may not be the same people who manage and configure OpenNMS for the enterprise.
  3. Data centers and server farms may consist of large numbers of servers. Server system administrators may or may not be the same people who manage the network devices that provide connectivity to these servers. Server system administrators may be unable or unwilling to provide access to snmp agents on their servers.
  4. A campus enterprise may consist of a large number of separate buildings interconnected with a network infrastructure.
  5. Changes in network device configurations are likely to be frequent due to adds, moves, deletes, and upgrades.

Objectives

  1. Collect traffic data to/from servers in data centers and server farms without requiring SNMP agents on the servers.
  2. Collect traffic data for core network infrastructure links to a large number of campus buildings or other divisions within the enterprise by collecting on a small number of core switches and routers rather than collecting data from a large number of endpoints.
  3. Provide an optional means of storing and displaying SNMP interface data that can be more closely linked to the logical device or link being monitored, for example traffic to and from a server, rather than the physical switch or router port to which the server is connected. This is a key objective.
  4. Provide the ability to distribute a portion of the management responsibility for data storage to departmental technical staff when and where appropriate.
  5. Insure that any departments that may have distributed management responsibility don't interfere with each other.
  6. Provide the above distributed management responsibility without granting OpenNMS administrative status to the departmental network managers, and without making it available to unauthorized persons.
  7. Reduce the amount of manual intervention required on the part of the OpenNMS administrator when managing data collection and storage.

Usage

  1. The OpenNMS administrator chooses to enable this optional data storage feature for a group (domain) of network nodes. Members of the domain may be chosen based on departmental administrative boundaries, or any other rationale that provides a logical grouping of devices. A domain may contain a single device or many.
  2. The OpenNMS administrator configures a separate data collection package for each domain. Package options provide additional flexibility when a combination of storage methods is desired for the nodes covered by a package.
  3. The network administrator configures descriptive names (ifAliases) for the active ports on each switch or router in the network administrator's domain. These should be unique within the domain.
  4. OpenNMS users view data stored by domain/ifAlias from Home > Reports > Resource Graphs by selecting one of two new viewing choices Standard Domain Performance Reports and Custom Domain Performance Reports. Users may also view data from Home > Reports > KSC Reports by selecting the new choice Domain Reports or by incorporating individual graphs into KSC Performance Reports.
  5. OpenNMS users may search for nodes on the OpenNMS system with interfaces having an ifAlias matching a string of characters using a new choice on the search page, ifAlias containing. This is a partial string match analogous to the Name containing search.
  6. When the network administrator moves a device such as a server to a new physical port, he/she deletes the descriptive name (ifAlias) from the old port's configuration and adds it to the new port's configuration. OpenNMS continues to store interface data associated with the server in the same rrd file used before the move.
  7. OpenNMS users view traffic data to/from the server moved in the previous item using one of the new viewing options and see a continuous graph of interface data covering the time periods before and after the move.

The collectd-configuration.xml file

Below is an example from collectd-configuration.xml used for domain/ifAlias storage. Each new option will be explained below.

<package name="example2">
  <filter>IPADDR IPLIKE *.*.*.*</filter>   
  <specific>1.1.1.1</specific>
  <include-range begin="1.1.1.2" end="1.1.1.3"/>
  <include-url>file:/etc/opennms/include</include-url>
  <storeByIfAlias>true</storeByIfAlias>
  <storeByNodeID>normal</storeByNodeID>
  <ifAliasDomain>mydomain</ifAliasDomain>
  <storFlagOverride>true</storFlagOverride>
  <ifAliasComment>#</ifAliasComment>
                
  <service name="SNMP" interval="300000" user-defined="false" status="on">
    <parameter key="collection" value="default"/>
    <parameter key="port" value="161"/>
    <parameter key="retry" value="3"/>
    <parameter key="timeout" value="3000"/>
  </service>
</package>
storeByIfAlias 
This is the main configuration parameter for this feature. If it is absent or false, all the following options are ignored, and data storage proceeds in the regular manner as before. Allowable values are true (yes,on) or false (no, off). Default is false.
storeByNodeID 
Determines if data will be stored by nodeId/interface. Allowable values are true (yes, on), normal, or false (no, off). True means data will be stored by nodeId/interface if data is being stored by domain/ifAlias OR if the snmpStorageFlag indicates it should be stored . False means data will not be stored by nodeId/interface. Normal means data will be stored by nodeId/interface according to the setting of the snmpStorageFlag. Default is normal.
ifAliasDomain 
This text string specifies the name for the domain. If it is absent, the name defaults to the package name. Two new optional keywords have been added beginning with versions 1.8.7 and 1.9.3. These are nodelabel and nodeid. setting ifAliasDomain to nodelabel will create a separate domain for each node in the package, using the node label as the domain name. Setting it to nodeid will set the domain name to the node ID, which causes the data to be stored in the node ID directory. (The same place that other data collected from the node is stored.) Both of these keywords imply one node per domain. By using one of these keywords you can combine all of your single-node domains in a single package instead of defining a separate package for each. The nodeid keyword has the additional advantage of making all data for the node available from the resource graphs link on the opennms node page. No need to go to the reports page and select the domain to access the data.
storFlagOverride 
If true, data will be stored by domain/ifAlias regardless of the snmpStorageFlag setting. If false, data will only be stored by domain/ifAlias if an ifAlias exists for an interface AND the snmpStorageFlag would normally permit data from this node and interface to be stored. Allowable values are true (yes, on) and false (no, off). Default value is false.
ifAliasComment 
An optional comment character that can be used by network administrators when assigning ifAliases to interfaces. The comment character and all following characters will be ignored when creating file names for storage by domain/ifAlias. Any white space immediately preceding the comment character will also be ignored. The comment character can be used to add information to an ifAlias that may change with a move, such as a wiring jack number, without affecting the file name used for storage. An ifAlias that begins with a comment character is treated as if the interface has no ifAlias. Default is no character.

See Also

FAQ

A FAQ can be found at Domain-IfAlias_Data_Storage_FAQ