SNMP is a standard protocol that has wide acceptance in the industry and is flexible enough to describe almost anything. Because of these advantages, many network managers have come to believe that SNMP should be used for all telemetry monitoring applications.
SNMP certainly has its place in an effective telemetry monitoring solution, but this doesn't mean that any off-the-shelf SNMP manager can provide adequate visibility and control of your network.
The typical off-the-shelf SNMP manager is not designed for displaying and processing telemetry data, especially not for the kind of real-world monitoring tasks network managers most need performed. These capabilities can be added to an SNMP manager, but it may require substantial custom software development.
Using an off-the-shelf SNMP systems for mission-critical telemetry is disappointing at best and disastrous at worst. If you're used to the standards of classic telecom telemetry, an off-the-shelf SNMP manager will not provide the detailed alarm data you expect. Before you commit to an SNMP monitoring solution, you need to make sure it supports essential telemetry functions.
1. Basic SNMP managers don't provide complete, precise alarm descriptions
A basic SNMP manager doesn't record location, time, severity or descriptions of alarm events. To adapt an off-the-shelf SNMP manager to monitor these factors, you must create and maintain a master alarm list representing all the monitored points in your network - and then also create and maintain a database associating all the Traps that may be sent to the SNMP manager with the alarms on that list.
2. Basic SNMP managers can't identify cleared alarms
Even more work is required to identify whether a Trap represents an alarm or a clear condition. Creating this addition to the Trap association database often requires analyzing multiple variable bindings within the Trap packet.
3. Basic SNMP managers don't maintain a history of standing alarms
Relying on a basic SNMP manager for alarm management can potentially result in completely losing visibility of threats to your network. A basic SNMP manager doesn't maintain a list of standing alarms. Instead, the typical SNMP manager maintains an event log of newly reported Traps and a history log of acknowledged Traps. As soon as a Trap is acknowledged, it is considered cleared. Imagine what might happen to your network if a system operator acknowledges an alarm, and then, for whatever reason, fails to correct the alarm condition. Who would know the alarm is still standing?