How We Wrote Our Own SNMP MIB for BeezKeeper

black and white code

SNMP stands for Simple Network Management Protocol, which is an Internet-standard protocol for collecting and organizing information about managed devices on IP networks and for modifying that information to change device behavior. If you use SNMP in your organization, you probably have an SNMP collector to gather information on the status of devices in your network.

Since the NetBeez BeezKeeper is the central server for our network monitoring solution designed to provide an end-user experience view of your network, it would only make sense to be able to integrate it with your organization’s SNMP collector and receive any critical and performance alerts from your remote locations immediately, and be able to correlate them with other SNMP measurements/alerts.

Since NetBeez provides a new and unique view of your network, we had to create our own set of SNMP traps to accommodate our data model and the types of alerts generated by our product.

The first step in writing our own SNMP MIB was to get our Private Enterprise Number (PEN). This number represents the root OID of an organization. For NetBeez, this is 1.3.6.1.4.1.44523, which translates to:

And it should be the first declaration in our MIB:


The next step was to create a hierarchy of the objects that made sense to include in our MIB. First, we decided to create a child object right under the enterprise OID for the specific product: BeezKeeper.


Everything else is rooted under this OID as shown in the diagram below 
(generated using MIB Browser):

OID diagram
Since we wanted to include all the alerts generated by our system, we split them in two categories. The first one is agent device alerts to represent alerts such as reachability and wireless interface up/down alerts. The second one is test alerts, which are generated when a test on an agent is experiencing degraded performance or a failure. Both categories are grouped under the nbAlerts group:

We then decided to include two table objects that will hold a SEQUENCE of the alert records for the two alert types: beezStatusAlerts and the testStatusAlerts. Doing it at this layer of the hierarchy gives us the ability to add more alert types if we need them in the future.

Here is the beezAlertsTable object:

Then for each of the tables, you have to define the entries that go in that table. Here is the beezStatusAlertEntry which is of type BeezStatusAlertEntry:

Then for each sequence, we had to define each of the objects that comprise it. Here’s just the first two for the BeezStatusAlertEntry:

Once all the entries and the sequence of entries (tables) are defined, we defined the notifications, which represent the messages sent from the NetBeez server to your trap collector. You have to group them under a separate notifications group:

Inside this group, you can describe the NOTIFICATION-TYPE messages. These messages are also sequences of attribute objects, referencing the attributes we defined earlier:

This is the design we iteratively came up with. There may be some redundancies, or non-standard things in there, but this was all done by trial and error, and any feedback or discussion on this is always welcome.

Of course, SNMP works great if your organization is using SNMP as their primary way of looking into the status of network devices. Otherwise, you could also integrate the NetBeez BeezKeeper alerts using our Syslog integration.

network monitoring