Already a lot has been written about the fact that in the name of Simple Network Management Protocol the word Simple can be safely written in quotation marks. SNMP is quite simple from the point of view of creating SNMP agents, but on the side of the management software (SNMP manager) the competent processing of complex data is usually a non-trivial task.



We tried to simplify the process of configuring data collection and SNMP events and allow users during this process:

• Never look inside MIB files
• Do not know what OIDs are and never operate with them
• Do not use a separate SNMP utility to preview data during setup

Step 1: add the MIB files

First of all, you need to deal with MIB files. The description of the logic of relations between data elements and their syntax was implemented in SNMP using these files in order to reduce the load on the network and simplify the implementation of agents. Users, however, do not always want to deal with their internal device.

The SNMP module of our AggreGate Network Manager system at startup loads all the MIB files located in a special server folder, after which it allows you to add new ones using a simple dialog:



When files are downloaded, they are automatically compiled. A built-in syntax highlighting MIB editor is available only in case MIBs that do not meet the specification appear. You need to use it extremely rarely.

This ends the work with MIB files, then their names are used only for logical grouping of already collected data. If necessary, downloaded files can be viewed and searched in the MIB table, but during normal operation this is also not required.

Step 2: connect the SNMP device

In the case of building a classic monitoring system, this step is usually not required, since all devices are added to the system automatically during periodic network discovery. However, when adding devices detected by a network scan, approximately the same steps are taken:

1. Select device type. In our case, either SNMP or Network Host is supported, which supports Ping, SNMP, WMI, and other typical IT monitoring protocols.
2. Indication of address and communication settings. This refers to the protocol version, SNMP Communities, timeouts and number of retries, SNMP v3 settings, etc.
   SNMP driver settings

   

   
   
3. Asset selection, that is, MIB files. Network Manager automatically detects which MIBs are supported by the device, which we wrote about in a separate article . It remains only to choose which MIBs will be polled, and the MIBs for which there is “boxed” analytics and visualization are already selected by default.

Step 3: study the device snapshot

After completing the device connection step, the system requires from several seconds to several minutes to complete the polling of the device within the selected MIBs. When the device icon turns green, you can open and study the so-called “device snapshot”:



In this picture, almost the whole essence of our approach to working with SNMP data is concentrated. First of all, it always contains “at hand” all the real data of the device. Moreover, all data is read only once, the subsequent survey is only on important metrics. Full re-reading of the device’s image is done once a day, to reduce the load on the network it can be completely disabled. The device snapshot is optionally saved in the database when the monitoring system is restarted.

Usually, you do not need to resort to the help of any external utilities when you need to find suitable data for monitoring by their descriptions in the MIB file or values. All data is already grouped by MIB-files, however, you can group them by hierarchy of OID-s:



To see a detailed description of any metric or table contained in a MIB file, just move the mouse over the description or value of the metric. The tooltip also shows the SNMP data type and full OID:



If the metric can take one of several numerical values ​​described by text constants in the MIB file, the constant corresponding to the current value is immediately displayed in the device snapshot. A complete list of constants and their numerical values ​​is available through the context menu:



In this case, the current numerical value can always be seen in the tooltip. For editable metrics it’s still easier, you can select a constant and see its value directly in the drop-down list:



But our SNMP data processing method is most useful when processing tables. Each SNMP table is shown in the device snapshot as a separate table type metric:



Editing data in tables can be done right at the time of viewing, for example, to disable the network interface, just change the value of the ifAdminStatus field in the corresponding line.

When you hover over the column heading in the tooltip, you can see the description of the field obtained from the MIB file, as well as its type and OID:



If there are several tables connected to each other, for example, using external indexes or an extension (augmentation), the system automatically processes all internal relations and combines the data of the linked tables into a single whole. In most cases, users are not even aware of the existence of such difficulties. Here, for example, is what the hrSWRunPerfTable table looks like :



At the MIB file level, this table consists of two columns ( hrSWRunPerfCPU and hrSWRunPerfMem ) that extend the hrSWRunTable table . These tables are already combined in the device’s snapshot, which facilitates data analysis, reporting and charting, storage setup, etc.

Because the single AggreGate platform data model is table-oriented, SNMP data tables are an ideal candidate for in-house processing. Using them, the L2 / L3 topology is built, MPLS TE and MPLS VPN data analysis, monitoring and creation of IP SLA tests, as well as hundreds of simpler tasks.

Step 4: set up polling periods and storage periods

AggreGate Network Manager is both a platform and a boxed product , therefore, in most cases, after automatically or manually adding a device, the polling periods and storage periods for metrics are already pre-configured for all metrics and tables that the system “understands”, that is, shows on dashboards and analyzes for the need to generate alarm messages.

You can adjust the polling (synchronization) and storage settings for the metric through its context menu or through the account settings (for all metrics at once).


The storage settings dialog shows only the storage period of raw data in a regular database (relational or NoSQL, depending on the server settings). In most cases, SNMP data is stored in a round-robin database (RRD), which is built into the AggreGate platform. There will be a separate article on the topic of creating statistics channels that transfer metrics and parts of tables to a circular database.

Step 5: move on to data processing and visualization

When the data is collected and stored in the server database, you can start using it for business, that is, for monitoring and managing IT infrastructure. The context menu of any metric in the device’s snapshot provides access to wizards, allowing you to start setting up alarms, reports, graphs, queries, dashboards, and other analysis and visualization tools.



Using these tools, you can configure the impact of metrics and tables on system-wide operations for finding the causes of failures, performance analysis, planning and inventory, configuration management, and other system functions. At the same time, various interfaces are "drawn":

As a result

The process described above may seem complicated due to the many details mentioned, however, in practice, only a few minutes pass from the moment you connect a completely new device to the appearance of its specific data on standard toolbars. During this time, exit from our system is required only while searching for specific MIB files on the site of the manufacturer of the connected equipment.

When setting up monitoring, you do not need to manually specify the names of MIBs, enter OIDs and other low-level identifiers. This makes setting up SNMP monitoring quick and easy.

Of course, we still have work to do. Improving the mechanisms for choosing individual metrics is required to avoid even a single survey of entire MIBs. There is a need to exclude from the survey individual rows and columns of SNMP tables. We would be interested to hear about other shortcomings of the SNMP monitoring setup process in our system.

And detail?

This article does not deal with receiving, processing, and sending SNMP traps, working with SNMP v3, and many other aspects.

For a more detailed story, we invite all hawkers to the SNMP Monitoring and Management webinar , which will be held on May 26, 2015 at 11:00 Moscow time. At this webinar, we will demonstrate live the entire process described above, as well as many other ways to monitor network, server and non-standard equipment using SNMP.

View the program, register for the webinar and add to the calendar >>

Update - webinar entry: