This content is also relevant to NMIS9, the model files are 100%, the main difference being the use of models-custom and models-default for storing models and NMIS8 plugins are not compatible with NMIS9, these need to be ported.

Table of Contents

1 Basic Modelling
- 1.1 NMIS 8 Architecture
- 1.2 Modelling process
  - 1.2.1 Types of Model Files
- 1.3 Overview
  - 1.3.1 1. Collect From Device
  - 1.3.2 2. Determine the Vendor
    - 1.3.2.1 conf/Enterprise.nmis
  - 1.3.3 3. Auto-discovery model
    - 1.3.3.1 models/Model.nmis
  - 1.3.4 4. Load the model
    - 1.3.4.1 models/Model-Windows2008.nmis
    - 1.3.4.2 models/Model-Windows2008.nmis
  - 1.3.5 5. Load the data
- 1.4 Structure of a model
- 1.5 Common Models
- 1.6 Modelling a Device
  - 1.6.1 Goal for Modelling
    - 1.6.1.1 Device Instrumentation
    - 1.6.1.2 Relevance of Instrumentation
    - 1.6.1.3 Verify the MIB Operation
  - 1.6.2 What do we need
    - 1.6.2.1 Device Access
    - 1.6.2.2 SNMP MIBS
      - 1.6.2.2.1 SNMPWALK (SNMP Dump)
      - 1.6.2.2.2 MIB Decoding Example
      - 1.6.2.2.3 SNMPv2-SMI::enterprises.6302.2.1.
      - 1.6.2.2.4 SNMPv2-SMI::enterprises.6302.2.1.2 → SNMPv2-SMI::enterprises.ees.global.powerMIB.system
      - 1.6.2.2.5 MIB tree for the three components
- 1.7 Implementing a new device model
  - - 1.7.1.1 conf/Enterprise.nmis
    - 1.7.1.2 models/Model.nmis
    - 1.7.1.3 conf/Enterprise.nmis
    - 1.7.1.4 models/Model.nmis
  - 1.7.2 Adding a New Metric to Node Health
    - 1.7.2.1 mibs/nmis_mibs.oid
    - 1.7.2.2 models/Model-CiscoRouter.nmis
    - 1.7.2.3 models/Model-CiscoRouter.nmis
    - 1.7.2.4 models/Model-CiscoRouter.nmis
    - 1.7.2.5 models/Common-heading.nmis
    - 1.7.2.6 models/Graph-routenumber.nmis
  - 1.7.3 System Section
    - 1.7.3.1 models/Model-net-snmp.nmis
    - 1.7.3.2 models/Model-net-snmp.nmis
    - 1.7.3.3 models/Common-heading.nmis
    - 1.7.3.4 models/Common-database.nmis
    - 1.7.3.5 models/Common-heading.nmis
  - 1.7.4 System Health Section (Indexes)
    - 1.7.4.1 Model file
    - 1.7.4.2 sys section
    - 1.7.4.3 rrd section
    - 1.7.4.4 Common-heading.nmis file
    - 1.7.4.5 Common-database.nmis file
    - 1.7.4.6 Graph-diskio-rw.nmis and Graph-diskio-rwbytes.nmis files
2 Thresholding
- - 2.1.1 Considerations
  - 2.1.2 Implementation
  - 2.1.3 Standard Thresholds (Common)
  - 2.1.4 Creating Thresholds (Detailed)
    - 2.1.4.1 Files
    - 2.1.4.2 Relationship
    - 2.1.4.3 Common Attributes
  - 2.1.5 Thresholds Controls
    - 2.1.5.1 Simple Thresholds
    - 2.1.5.2 Have a set of thresholds for Core CPU
    - 2.1.5.3 Advanced Thresholds with Controls
    - 2.1.5.4 Advanced Control Options
    - 2.1.5.5 Sample Controls
- 2.2 Alerting
  - 2.2.1 Basic Alerts
  - 2.2.2 Test
  - 2.2.3 Where to add the Alert
  - 2.2.4 Example
  - 2.2.5 More Advanced Alerts
  - 2.2.6 Custom Variables
- 2.3 Thresholding VS Alerting
  - 2.3.1 When to use
- 2.4 Running a Model
- 2.5 Debugging Device Modelling
3 Advanced Modelling
- 3.1 Advanced Modelling Options
  - 3.1.1 Regex OID
  - 3.1.2 Control
  - 3.1.3 Calculate
  - 3.1.4 ParseString
  - 3.1.5 Replace
  - 3.1.6 No graphs
  - 3.1.7 Not saving to RRD (nosave)
  - 3.1.8 index_regex
  - 3.1.9 Additional Options
- 3.2 Advanced Modelling: Custom variables
  - 3.2.1 Where and How to use CVARs
  - 3.2.2 An example scenario
  - 3.2.3 How to keep temporary CVAR data out of the RRD databases
- 3.3 Plugins
  - 3.3.1 NMIS8 Plugin Operation
  - 3.3.2 Intro (Concepts)
  - 3.3.3 Basic Plugins
  - 3.3.4 Examples
  - 3.3.5 NMIS8 Node Polling Configuration
- 3.4 Model Policy
  - 3.4.1 The Model Policy Document
  - 3.4.2 Example Policy

Basic Modelling

NMIS 8 Architecture

The nodes information is accessed using daemons or pollers that are part of the Polling System. The information obtained at this level could be ICMP (Internet Control Message Protocol), SNMP (Simple Network Management Protocol), etc.

Once the device information is collected, the Abstraction System is loaded, this system includes Sys.pm that specifies the methods to be able to communicate with the devices, loads information form the NMIS "VAR" directory and from the databases. The Abstraction System also includes NMIS.pm, which load NMIS and Devices configuration and is the responsible to load the models for the devices, collect information from the device base on that model, write down this information into the databases and into the VAR directory.

At the User Interface level, most of the heavy lifting is done by Network.pl, which loads up the Abstraction System and Data to produce the views, dashboard and everything displayed to the user in a meaningful and useful manner.

Modelling process

Types of Model Files

This are the files that we need to get familiar with in order to be able to successfully follow the modelling process.

Model.nmis : This file contains our model auto-discovery rules, it will determine, based on certain conditions, which model should be loaded.

Common-*.nmis : A collection of files that contains common sections, these are included in many models that share certain features.

Graph-*.nmis : It contains the graph definitions for each graph to be generated and is loaded dynamically on runtime.

Model-*.nmis : Device models which pull together related elements obtained from the devices, it must include all the structure needed to represent the device on NMIS.

Enterprise.nmis : It is part of the config files, it lives on “/conf” directory and contains the SNMP OID mappings used by Model.nmis to match the vendors of the device.

nodename-node.json and nodename-view.json : For each node a node and view file are generated and maintained after a poll cycle (Update and Collect). It contains node cached information from the SNMP MIBS and other derived data, the data that it holds is temporarily persisted. The view file is data to be displayed when presenting the User Interface.

Overview

1. Collect From Device

The first step is to collect from the device sysDescr (System Description) and SysObjectId (Vendor's authoritative identification of the device). NMIS does a SNMP GET on the route and gets the sysDescr and SysObjectId.

From the sysObjectID, we obtain the ID and it is compared with the Enterprise.nmis file to match the vendor of the device. In this example the OID: 1.3.6.1.4.1.311 is a match for a Microsoft device.

From the sysDescr we obtain detailed information related to the device, in this case, the hardware and software description.

'sysDescr' => 'Hardware: Intel64 Family 6 Model 15 Stepping 6 AT/AT COMPATIBLE - Software: Windows Version 6.1 (Build 7600 Multiprocessor Free)'
'sysObjectID' => '1.3.6.1.4.1.311.1.1.3.1.1'

2. Determine the Vendor

Compare the sysObjectID to the Enterprises defined in Enterprise.nmis, the OID 311 will return the value of Enterprise, in this particular case, is 'Microsoft'.

conf/Enterprise.nmis

'311' => {
 'OID' => '311',
 'Enterprise' => 'Microsoft'  
},

3. Auto-discovery model

To obtain the model to load, a matching process needs to be done on the Model.nmis file. The vendor name obtained from the previous step is used to find the section that matches its value, once we have the section to use, a regular expression will be perform to match the value of every item on that section against the sysDescr, this process will be done in numerical ascending order.
In this example, the vendor name will match the “Microsoft” section on the Model.nmis file, then, it will look for a match in order, starting from 10, it will try to identify if the value 'Windows Version 5.2' is included in the sysDescr. It will keep looking until a match is found. In this case, 'Windows Version 6.1' is a match, so the model to load is set to: 'Windows2008'.

models/Model.nmis

'Microsoft' => {
  'order' => {
    '30' => {
      'Windows2000' => 'Windows 2000 Version 5.0'
    },
    '10' => {
      'Windows2003' => 'Windows Version 5.2'
    },
    '20' => {
      'Windows2008' => 'Windows Version 6.1'
    }
  }
},

NMIS8 Modelling Training