_
_
The Need for SNMP
Originating in the late 1980's, SNMP was introduced to meet the growing need for network device management and monitoring. Although many corporations are moving into hybrid and purely cloud based infrastructure, there remain other corporations still utilizing on-premise data centers. The divide between these infrastructure paradigms is often unclear, with any given company utilizing a mix of both cloud and on-premise infrastructure. It can be challenging to gain a holistic view of your organization's hybrid cloud infrastructure without the need for an additional monitoring tool. However, RapDev's SNMP Profiles can help manage and fill the gaps in monitoring your organization, no matter if the pieces are physical hardware or virtual appliances that do not support Datadog agent installations like load balancers.
SNMP: MIBs and the sysObjectID
Since SNMP standardized network device monitoring, it holds that any network device will follow suit. Each network device contains a standardized table of information known as SNMP MIB-2. SNMP MIB-2 is located at the same place in any device and it's data can be retrieved the exact same way, regardless of the device. Various SNMP MIB tables and other pieces of data are referred to by their ObjectIDs (OIDs). An ObjectID is a traversal path down the SNMP tree, starting from the root node, ending at the desired node's destination. There is a special type of ObjectID that is the unique ObjectID for a specific device model. This special OID is called the sysObjectID.
In the OID Tree Example above, you can see that the system(1) node can be reached from the root through a traversal path: root-node -> iso -> org -> dod -> internet -> mgmt -> mib-2 -> system. By keeping track of the nodes we passed through we end up with OID 1.3.6.1.2.1.1.0. This is exactly the sysObjectID node.
Device Profile Detection
Now that we've touched on sysObjectIDs and ObjectIDs (OIDs), we can outline how profiles are automatically detected for a given device. When the integration makes initial contact with a device, it gets that device's sysObjectID by traversing the same path we just covered. The integration then looks up the sysObjectID returned from the device and compares it to the sysObjectIDs defined in the SNMP Profiles. After detecting a profile, the integration knows what other OIDs are important on that given device, and to get that set of information when the check runs. This includes what type of value to expect, how it is named, and the value itself.
Extending the Pool of supported Devices
There remains one important issue to cover in regards to SNMP profiles. What happens when a device's sysObjectID does not exist in any of the default profiles? No metrics will be collected from this device! Enter, RapDev Datadog SNMP Profiles. Our profiles cover more than ten of the largest hardware manufacturers. We are constantly updating and creating new profiles to support additional devices per our customer needs. Our profiles automatically create monitors and dashboards for a given model and manufacturer. For example, our Cisco Catalyst, ASR, and ISR dashboards:
Our profiles also include out of the box tagging. Our tags allow you to slice up your data and devices into whatever view you see fit. We have recently added additional tags to our profiles based on the devices' type, regardless of the manufacturer. This allows for additional automatic dashboards and monitors independent of the manufacturer. With this addition, we are developing a high-level network summary dashboard, as well as dashboards based on the different device types (i.e. Network Switch dashboard or Firewall Dashboard)
Concluding Remarks:
If you are looking to get metrics from a device that doesn’t exist in our profiles, reach out to integrations@rapdev.io, and we can work with you to get profiles and out of the box dashboards developed for these devices to satisfy your monitoring needs. Feel free to comment below or message me directly with any questions!
