10 Tips for Successful Network Monitoring

Introduction

There is no doubt that we live in a world with ever evolving technology. From our mobile phones to cloud computing to virtualization and remote working the things we do today and the tools we do it with are so vastly different than the way we did things a short ten or even five years ago. This is particularly true in the broad scope of the ICT (Information and Communication Technologies) industries. And even more so when it comes to successful network monitoring and management within these spheres.

We’ve spent the past 10+ years building and implementing enterprise-class network monitoring software for our customers around the world. Listening to their needs and doing our best to execute their vision. But it hasn’t always been smooth sailing. Hindsight is always 20/20 they say and over the years we (and our customers) have learned some lessons that could be helpful to the reader.

Tip #01

Planning

Monitoring can no longer be an afterthought at the end of a project. For a few reasons. One is budgeting. I’ve seen customer plan X amount of $ for a new broadcast facility and after it’s built realize that there is no longer budget for a monitoring system. This is a big problem because now they have this fancy new facility with lots of fancy new technology and absolutely no way to know if everything is working without logging in to maybe 10 or 15 different sub-system web interfaces to troubleshoot. Tracking down problems can take many hours (and lost weekends)! The other route is to implement a cheap, perhaps open-source monitoring tool that really can’t monitor everything, isn’t easy to use, and ends up costing more again in terms of lost time and productivity.

But let us say you did budget for a monitoring system. By the way, a good rule of thumb is to set aside 15 - 20% of the cost of all the technology for monitoring of that technology. So, say you are buying $1M worth of tech it isn’t unreasonable to plan for $150-$200K for true enterprise class monitoring for that facility. But back to the point. I’ve seen it happen where a workflow has gaping holes in the monitoring visibility because one of the key sub-systems has no remote monitoring access. No SNMP, no API, etc. This now becomes a new “screen” that must be displayed in the NOC that perhaps was not planned or frankly is not practical because of the number of streams/services.

It’s also likely that this particular sub-system has other competitors/alternatives that do have these remote capabilities but monitoring wasn’t planned until late in the game. You get where we’re going here.

If monitoring is part of the planning from the very beginning, then these major operational issues can be avoided. Keep in mind you don’t have to have every single detail. First set aside a rough budget. Then make sure each sub-system in your facility has the key information you need available in some remote way. Don’t worry about the delivery. An enterprise-class NMS (such as Kybio) will be able to ingest data no matter the protocol so these device specific details can be worked out later in the project once workflows are better defined. Enough to know right at the beginning that the capability is there.

Tip #02

Select the correct architecture

This is specifically related to the architecture of the monitoring itself, not the overall network architecture of either the corporate or broadcast networks. What needs to be decided is where the monitoring server (or servers) will be and what rules/whitelists need to be updated for the monitored equipment to be reachable from those servers.

What also needs to be considered is who will be accessing the management system and from where.
That access needs to be considered as well. Does a centralized model make the most sense? Or perhaps a distributed model where edge devices will do the polling in a number of remote locations. Perhaps there are remote teams of people that each will need to have their own management system with an umbrella layer on top, say at a national super head-end that will have visibility over all the other remote systems.

Tools like Kybio can handle all of these scenarios natively with minimal configuration but there are some licensing and hardware options that will need to be used depending on which architecture is needed. Similar to before, some architecture planning in the beginning will go a long way.