7 Key Telemetry Functions not Supported by Off-the-Shelf SNMP Managers

SNMP is an open, highly refined, standard protocol that has wide acceptance in the industry. (See our SNMP Tutorial Series) The great advantage of SNMP is that it is flexible enough to describe almost anything. Because of this, many network managers have come to believe that SNMP should be used for all telemetry monitoring applications, and that other protocols should be phased out. But, are there cases where SNMP's flexibility may be more of a burden than a benefit?

SNMP certainly has its place in an effective telemetry monitoring solution, but this doesn't mean that replacing your traditional telemetry master with an SNMP manager will immediately provide you with increased visibility and control - in fact it could be quite the opposite.

The typical off-the-shelf SNMP manager is not designed for displaying and processing telemetry data for effective alarm management, especially for the kind of real-world monitoring tasks network managers most need performed. These capabilities can be added to an SNMP manager, but it usually requires substantial custom software development.

Getting the highest level of telemetry visibility

If you can start from scratch and review all the vendor-supplied MIB files and software modules for every type of equipment in your network, an SNMP implementation can be relatively easy. But if you're trying to create a smooth migration path from traditional telemetry monitoring to SNMP, you should consider some of the obstacles to getting the highest level of telemetry visibility from an SNMP manager.

1. Traditionally, high-quality telemetry monitoring records the location, time, severity, and a precise description 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. (Traps are a type of SNMP message sent from an SNMP agent, such as an RTU - see our SNMP Tutorial Series to learn more about SNMP.)

2. Even more database work is required to identify whether a trap corresponds to an alarm condition or a clear condition. Creating this addition to the trap association database often requires analyzing multiple variable bindings within the trap packet.

3. Relying on a basic SNMP manager for alarm management can potentially result in completely losing visibility of threats to your network. Unlike high-quality telemetry masters, SNMP managers do not 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?

4. Basic SNMP managers do not record the identity of the system operator who acknowledges an alarm. In the example of the negligent system operator, it would be impossible to determine who had made the mistake or to assign responsibility for the resulting problems.

5. Out of the box, the typical SNMP manager is not designed for multi-user security. All traps are posted to one alarm list; all users may view all alarms, and all users may acknowledge all alarms.

6. SNMP managers have no built-in functions for organizing alarms by logical category, posting the same alarm to multiple logical categories, or sorting which alarms the user wants to see. If Jones is in charge of all equipment for the Western region, and Smith is in charge of power plants, both need to know about a generator failure in Tucson, but neither one needs to know about all the alarms in the network. And if one manager corrects the alarm condition and acknowledges the alarm, the other manager needs to know it was acknowledged and by whom. Unfortunately, standard SNMP managers will not support these functions.

7. No SNMP manager supports the advanced features necessary for best quality telemetry monitoring, such as notifications escalation, legacy protocol mediation, nuisance alarm silencing, automatic control relay operation, and automatic notifications by pager and e-mail.

It is true that many, but not all, of these functions can be added to standard SNMP managers, but implementing telemetry monitoring in an SNMP manager usually involves a substantial amount of custom software module development. Even when pre-built software modules are available, they usually require custom tweaking to perform exactly as you want them to.

The need for extensive customization eliminates the advantage of using a simple open standard, and it is difficult to justify significant development costs after purchasing an already expensive SNMP manager. Why take the time, trouble, and expense to recreate capabilities that are already present in a high-quality telemetry master?

And in fact, it is much easier to adapt a traditional telemetry master to process SNMP traps than to adapt an SNMP manager to perform telemetry functions. There is no question that SNMP is right for many applications, and it is clear that SNMP will be increasingly used in the future.

SNMP can be an effective tool, but it's only one item in your telemetry monitoring toolkit, and it can be used more effectively when it is part of a total alarm management solution.

Are you having technical issues and need support?
Give us a call and talk to one of our tech support specialists. They'll help answer any questions you may have.

Tech Support: 559-454-1600 · Fax: 559-454-1688