7236

Get a Live Demo

You need to see DPS gear in action. Get a live demo with our engineers.

White Paper Series

Check out our White Paper Series!

A complete library of helpful advice and survival guides for every aspect of system monitoring and control.

DPS is here to help.

1-800-693-0351

Have a specific question? Ask our team of expert engineers and get a specific answer!

Learn the Easy Way

Sign up for the next DPS Factory Training!

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 Today

Buyer's Guide: Network Management Software

By Andrew Erickson

June 21, 2021

Share: 

So, you've decided that it's time to choose the best possible software for network monitoring at your company. That's a big job, but someone's got to do it!

At least you have the good sense to do a bit of homework first. In my line of work, way too many people call me after they've blown most of their time and half of their budget on something that didn't work. That's not good for your company - and it's certainly not good for you.

T/Mon remote monitoring software displaying alarms as a list with a map in the background
Any good network management software will put your alarm events on a list display. The best options will have other intuitive views, like geographic maps or logical network diagrams. (Screenshot of T/Mon web interface)

What you need is a straightforward series of steps to evaluate and select the best network management software. You need to cover your current requirements, plus an allowance for anticipated future growth.

When it comes to tools you can use for effective monitoring, network software varies wildly. Let's take a step-by-step look at how you can eliminate options that won't do the job, then ultimately select the best solution.

Step 1: Application Performance, or Physical Infrastructure Monitoring System?

With a broad umbrella like "network monitoring solutions", you can encapsulate a pretty wide range of equipment. The first decision you need to make is what, exactly, you need out of remote monitoring. What do you need to remotely detect, track, and control?

Is it network traffic that you need to monitor as part of your performance management? Or do you need to monitor remote tower sites, substations, and other physical infrastructure? Maybe you need both?

"I need a feature set that lets me monitor network server status, application monitoring and performance, and bandwidth."

If you need a network monitoring tool that can give you detailed insights into your network traffic and performance, there are some big players in that space:

  • (Solarwinds) Network Performance Monitor is one of the most popular options. The name perhaps won't win many awards for creativity, but you know exactly what you're getting when you buy it. You can see network traffic on a logical map of your network and collect alarm events using popular protocol standards like SNMP.
  • (Paessler) PRTG Network Monitor is another option, which promises to analyze the full breadth of your IT infrastructure.
  • (ManageEngine) OpManager monitors routers, switches, firewalls, load balancers, etc.
  • Open-source network monitoring software also exists. You can use this, but consider the value of your entire enterprise and the people you serve. Often, it's better to choose a commercial option with safeguards, support, training, and ongoing development commensurate with the investment your company has already made. One of the big virtues of these devices is their ability to automatically discover network-based equipment. This is done with various protocols that have a broadcast function. Once your central server has detected the presence of a device, it can query it to learn all of the alarms and other data that is available for collection.

Of course, you might also mean something entirely different when you say "network management"...

"I need a hardware device that collects system alarms from my infrastructure equipment and monitors my remote site for environmental threats like temperature and humidity."

Notice how the concerns above are mostly about the physical layer. We're talking about hardware faults and heat loads, not the finer points of real-time network traffic, bandwidth, and cybersecurity.

The ideal network management software for this use case is quite different than the one above. Obviously, many of the choices in that previous section are acceptable options. They support SNMP protocol, for example, which can definitely be part of physical-layer monitoring.

Alarm icons, including Generator, UPS, and Microwave, appear on a geographic map view
Maps are very intuitive for even novice users. Ideally, you'll be able to tie network alarm events to various icons, which will blink and change color when something requires attention.

What you're trying to do is pick a monitoring system head-end that has a style suited to what you'll be doing. Looking at a logical network diagram makes sense in a multi-story IT data center, but a geographic map makes much more sense if you're managing cell tower huts.

So how do you monitor physical-layer items like hardware alarms and temperature, humidity, water on the floor, break-ins, etc.? You'll need a few things:

  1. Sensors that create data from real-world readings. The 105-degree air in your telecom cabinet can't send you an email/SMS natively, of course. How could it? You need a sensor that takes a reading and translates that into usable data (ex. "Temp is 105 degrees F" ).
  2. Devices that generate data describing their own status. Classically, many different types of gear (telecom switches, generators, rectifiers, microwave radios, etc.) would output via simple dry contact closures (relays). Contact #1 might indicate "high temp" or "overcrank" or just about any other specific problem. More recently, there's been a big shift to protocol-based reporting with standards like MODBUS and CAN bus. That type of interface makes it very easy to make 100 or 1000 or more data points available for polling.
  3. A Remote Telemetry Unit (RTU) that collects the data above and provides remote access. None of the above data does any good if it's just bouncing around inside your data center, hut, or cabinet. It needs a report path. An RTU is a dedicated remote site management device that provides that path. An RTU will collect many different data points from sensors and your other equipment. It will then (usually) offer a web interface for remote viewing of a single site's present status. For large networks (10 sites or more), you can't spend time looking at one site at a time. You'll almost certainly have some kind of network management software involved. Your RTU must be compatible with your management software. For example, SNMP-based software requires an RTU that can output SNMP (and the correct version of it: v1, v2c, or v3).
  4. Your network manager at the top of your system. Your central manager could be one of the options mentioned in the list above. More likely, in a far-flung network of many remote sites, you'll choose something better suited for that purpose. It's common to see hardware/software appliances instead of software you have to load onto a generic server yourself. You'll also probably need support for more management protocols than just SNMP. Good central managers can poll MODBUS devices, process DNP3 alarm events, etc.

Now you understand a key differentiator that affects your best choice for network management. Let's take a deeper look at devices that can monitor physical infrastructure. These are important whether or not you also monitor cybersecurity, bandwidth consumption, and other performance statistics.

Step 2: Start with Monitoring the Foundational Physical Layer of Equipment

Consider two possibilities:

  1. You might be monitoring some incredibly advanced network-layer and application-layer things.
  2. You might instead be monitoring only legacy non-IP infrastructure at tiny remote facilities.

You know what these two versions of you (and every version in between) have in common? The physical layer matters.

In today's cloud-centric era, it's all too easy to think of "network management" as being something that transcends the physical. If you're literally just renting capacity in someone else's cloud, that might well be true.

If you have your own servers and equipment, however, you need to monitor at least some tangible, physical things with equipment alarms and sensors. All of this can be brought back to your network management software, even if 99% of what it monitors is network and application status.

Wireless propane tank monitoring for a remote site generator
You might not think much of it, but consider how monitoring the physical layer is absolutely critical to all the network layers on top. In this example, a smart PDU wirelessly communicates with a propane sensor on your generator tank.

Consider these 20 common sensor types for many hints at what you should likely be monitoring:

  1. Temperature
  2. Exterior temperature
  3. Humidity
  4. Air Flow (HVAC system performance)
  5. Water on floor / leak / flooding
  6. Water at 2 feet deep (for low-elevation areas subject to floods)
  7. Smoke
  8. Carbon monoxide
  9. Vibration (detect whether generator is running, someone trying to break into an enclosure, etc.)
  10. Door open
  11. Motion
  12. Wire cut (a cable may be strung through valuable commodities like UPS batteries, generating an alarm if the cable is removed or cut)
  13. Commercial power failure
  14. Voltage (including UPS battery life remaining)
  15. Current/amps
  16. Battery internal resistance (ohms)
  17. Propane (LPG) or diesel tank level (for generator)
  18. Wind speed (useful for tower sites or if helicopter is required for a site visit)
  19. Hydrogen accumulation (gradual battery off-gassing in a contained space can and has caused dangerous explosions)
  20. Logging entry and exit of employees and contractors with keycards and codes
Bus-powered D-Wire temperature sensor
Sensors are available to monitor a huge range of things. Temperature sensors are probably the most common type, with this one being a bus-powered node with a weather-sealed probe to collect outdoor temperature readings.

As you can see, there's almost no end to the vibrant situational awareness you can give yourself with good sensors.

An office and server room are remotely monitored using management sofware
The best network management software has smooth map zooming - all the way down to individual building, huts, and server rooms.

Review your equipment documentation to find out what outputs are available:

Whenever a new DPS client calls me to get their network management under control, I start by asking for a quick site roster:

  • What is the power source at the site? Commercial AC? Solar? What voltage?
  • Are there UPS batteries? How many batteries per string? What voltage?
  • Do you have a backup generator? Propane (LPG) or diesel? Does it output contact closures, or a serial/IP protocol like MODBUS?
  • What about revenue-generating equipment? What ISP equipment or radioheads or microwave transmitters or other gear do you have? What outputs do they each have, and how many?
  • How many HVAC units do you have? Two? Four? More?
  • Do we just need to monitor a single "ambient" temperature, or do you have some sensitive equipment where we should mount additional temp sensors?

Next, I gather all of these answers and count them up into a total (ex. 14 contact closures, 5 voltages, 2 current, 1 propane tank with R3D gauge analog 0-5 VDC output, 1 generator with MODBUS RS485 interface, etc.)

Select an RTU that matches your totaled input requirements:

Now that you know WHAT you have to monitor (in terms of contacts, analogs, protocols, and more), you can start evaluating your RTU choices.

Small RTUs commonly have 4-8 discrete inputs for contact closures. As a general rule, an RTU will have 25%-50% as many analogs, so perhaps 2-4.

Large RTUs may have 32 or 80 or more discrete inputs. Again, they tend to have fewer analogs, perhaps 8-16.

Newer RTUs, regardless of physical input capacity, can have protocol inputs like MODBUS polling and local SNMP processing.

Narrow down your RTU shopping list by eliminating models that don't have sufficient capacity for your needs (plus a 10-20% allowance for future growth). Also eliminate any RTU that is clearly "overkill" and has way more capacity than you'll ever need.

Make sure your RTU communicates using compatible network management protocol(s):

The job of remote monitoring doesn't end with your RTU. You have to backhaul that data back to your central network management software.

To accomplish that, your RTU will use some kind of M2M (Machine-to-Machine) protocol. There are several common options, including SNMP, MODBUS, and DNP3.

In the past, it was common for remote monitoring equipment manufacturers to "trap" you by developing and selling their own closed, proprietary protocol. If you bought their central manager device/software, you'd be stuck buying their RTUs - and vice versa.

The worst of it was if that manufacturer ever went out of business. At DPS, we largely built our company via extensive protocol compatibility to dig you out of that hole (but that's a story for a different article).

Just understand that the job of picking a protocol is important. Compatibility matters. When you're choosing an RTU, make sure it matches the protocol (including version, like "SNMP v2c") of your aggregator software (or the one you plan to buy).

Step 3: Choose the Right Network Management Software For You Okay, so now we have a fleet of RTUs selected. It's time to choose a network management system that will sit on top.

Remember the distinction that we established in Step 1. You want to choose the best network management software that fits with your operation and goals. Is that more IT/bandwidth/application-centric, or is it more about remote sites, equipment, physical security, and environmental levels like temperature?

Consider other elements, too, like:

  • How do you want alarms to be displayed? On a list? Within specific type or region/site categories? On a zoomable map view?
  • What architecture do you want? Can you tolerate (or even benefit from) the lack of control, reduced security, and low-but-recurring-forever monthly fees of a cloud-based solution? Will you install your chosen software application on your own server? What about an all-in-one hardware/software appliance that you rack, power up, and simply configure?
  • What kind of alerts do you need when your team is away from the NOC center? Maybe you're a big organization with 24/7 staffing of NOC dispatchers. Maybe you only have 3 technicians who go home at 5 PM. If you don't always have someone in the office, email, app-based, or SMS alarm notifications are a great way to coordinate your team.

The Choice is Yours

Ultimately, only you can decide what system to purchase for your network management. If you follow them, the 3 steps above will guide you to a better decision. You'll be able to make an informed choice with your eyes open to many of the costs and benefits.

If you'd like to discuss your options in more detail with an expert, please give me or someone on my team a call at 559-454-1600. You can also send a quick email to sales@dpstele.com.

NMS Option: T/Mon

It's not for nothing that I know a thing or two about network management software. Although I've "only" worked at DPS for 15 years, we've been building and evolving our network management system, called T/Mon, for over 30.

T/Mon MINI with its various available web, email, and smartphone interfaces.
T/Mon is one example of a network management server that is delivered as a pre-built hardware/software appliance. Setup time is reduced, because you don't have to install third-party software on a server you specify and purchase yourself.

Here's how T/Mon fits into the market landscape I described above:

  • T/Mon is a standalone hardware/software appliance that you host on-site. Our operating theory at DPS is that network management is plenty challenging without adding to it. As such, we've adopted something like an Apple-style model. If you entrust us with your project, we won't let you flounder or fail. T/Mons arrive loaded with software and ready to go. You simply use the web interface to configure your RTU fleet, user logins and access rights, alarm display screens, email/SMS notifications, etc. This isn't the only way to handle remote site monitoring, but it has worked well for our clients in the past. In particular, our government and corporate clients strongly prefer a device that is self-contained and can operate in a closed high-security network.
  • You only pay once for T/Mon. In today's era of "everything as a service", a lot of DPS clients are pleased to make a traditional one-time purchase. No ongoing monthly or annual payments are required. We think our maintenance agreement is a good deal overall (especially when your budgeting uncertainty makes it easier to pre-pay for multiple years), but it's not required to continue using T/Mon forever.
  • T/Mon supports many protocols instead of forcing you into a closed ecosystem. Admittedly, more and more manufacturers are moving to an open model rather than proprietary and closed protocols. Still, you often end up with multiple generations of open protocols in your network, so you still need a translator of some kind. T/Mon supports 35+ protocols from many different eras, so you can pull all of your equipment together on one screen. You can also forward alarms to a higher-level SNMP manager (or other MOM device) if you have a preferred top layer.

Talk to an Expert about Network Management Software

If you've read this entire article, stand proud. If you skipped to the end because it sure looked long, I don't blame you.

Network management systems can be complicated, no matter how many times you find the word "simple" in the name of something. Often, the best thing to do is talk to an expert. Once you do that for 15-30 minutes, you can actually get a lot more out of blog posts like this one. You'll have a firm foundation to categorize new knowledge.

So that you can quickly come up to speed about the best network management software for your specific environment, call me (or other DPS engineers) at 559-454-1600 or send me an email at sales@dpstele.com

Share: 
Andrew Erickson

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...