Check out our White Paper Series!
A complete library of helpful advice and survival guides for every aspect of system monitoring and control.
1-800-693-0351
Have a specific question? Ask our team of expert engineers and get a specific answer!
Sign up for the next DPS Factory Training!
Whether you're new to our equipment or you've used it for years, DPS factory training is the best way to get more from your monitoring.
Reserve Your Seat TodayIf your mission is to remotely monitor computers, there are many possible techniques you can use to do that. Let's walk through some of the reasons why you might want to monitor remote computers & servers, then discuss popular ways to do that.
There are many different reasons why you'd want to remotely track the status and health of a computer (usually a server).
One universal truth is that the computer must have some importance for you. You might be a business where that computer plays a critical role in your service delivery. You could be a government agency using that computer as a tool to protect public safety. You could even be a hobbyist to whom that computer is personally important.
Which of those categories you fall into determines your budget and the importance of you addressing the question of how to monitor your computers. It also affects the acceptable technologies you should choose to do the job.
SNMP is a standard protocol used by the network monitoring industry. "SNMP" is an acronym for "Simple Network Management Protocol". There are several SNMP versions, but the basic principle is the same for all of them.
In short, SNMP is a communications standard that can be implemented into a network management system. It dictates how a managed device (an "SNMP agent") can communicate with a central SNMP manager using SNMP Trap messages.
With SNMP, you're able to monitor devices remotely because your network devices will send SNMP trap messages in real time whenever a problem crops up. That could be an overheating processor, an electrical failure (presuming you have a UPS backup battery, a network issue (presuming the SNMP message still has a LAN reporting path), or almost anything else.
As a monitoring tool, SNMP is not without its flaws. Network administrators have developed several methods to work around these issues.
Firstly, SNMP isn't not as "simple" as the first letter of its name would imply. There are many possible variations that are allowed within the published SNMP standard.
As just one example of this variance, consider that SNMP traps can be implemented as "granular traps" or "universal traps".
In granular SNMP trapping, each possible problem (which you can think of like a machine-to-machine email message) has a different ID. A processor heat warning could be 8001, for example. If your remote computer had an expansion card failure, then that might be 8002. This will vary wildly by manufacturer, but you get the idea. The trap ID provides a handy reference for what is happening.
When you configure your SNMP manager (usually by compiling a "management information base" MIB file into it), your system will have a lookup table for every possible Trap ID representing every monitored problem condition. The combination of an SNMP Trap ID (technically called an Object IDentifier or "OID") and the IP addresses in your network tells you everything you need to know.
Compare that will a standard you might call "universal traps". In this case, the OID doesn't change for any of the different alarm conditions that might be reported by each of your device types. Instead, a text message is embedded as a "variable binding" within the trap itself.
There are pros and cons to this approach. Plain English in machine-to-machine messages is helpful for humans, but generally wasteful in a large-scale system. ASCII text characters are wasted network bandwidth. Fortunately, that's usually not much of an issue in the modern world, unless you're monitoring via wireless or especially satellite.
There are many different things to consider when you're monitoring your computers over an IP network or other means, no matter what transport and protocol you use.
One big item to think about during your purchase decisions is whether you'll use asynchronous communication or a polled architecture in your system.
You can think of asynchronous information as a kind of "email" structure (sometimes literally if you use email alerts). That's a perfectly fine system until you consider that a dead device is just as quiet as a device with no alarms to send.
Compare that to polling, where your network head-end server will ask your remote computers for a status report at regular intervals. That makes it possible to detect, in fairly short order, when one of your computers is offline for any reason.
You should also think about open standards vs. proprietary protocols. The world has trended toward openness in recent years, but you can still get this wrong.
Granted, there are advantages to a "walled garden" where a single manufacturer is the only provider of computers and monitoring tools. Apple has used this strategy, and many people swear by it.
When you're building a telecom network, however, openness tends to be valuable. If your current manufacturer of, say, an SNMP device goes out of business, you have hundreds of replacement options when you shop for a replacement. If that happens to your manufacturer who uses a closed proprietary protocol, you're in big trouble.
At DPS, our entire business is building effective remote monitoring tools for you. This generally takes the form of telco-grade RTUs and central masters.
These are commonly used by major operations. You have a viable use for DPS equipment if you work for a telephone company, an ISP, a power company, a railroad, or a government agency. We've even had users in agriculture and other industries (often simple dialers and other alert devices).
If you're a hobbyist, our devices will generally exceed a typical hobby budget. Even so, I'm happy to talk you through some of the basics if you call in. I've helped plenty of enthusiasts, students, and retirees over the years.
I will help you sort through your options. All it takes is a simple phone call to get started.
To get an overview of your options for computer monitoring, including SNMP and several others, give me a call at 1-800-693-0351 or email me at sales@dpstele.com
Andrew Erickson
Andrew Erickson is an Application Engineer at DPS Telecom, a manufacturer of semi-custom remote alarm monitoring systems based in Fresno, California. Andrew brings more than 17 years of experience building site monitoring solutions, developing intuitive user interfaces and documentation, and opt...