Network Monitoring Tools: How to Choose

To choose network monitoring tools, put the same nine questions to every supplier and apply five decision rules to the answers. The questions cover size, branch reach, alerts, history and where your data sits. The rules weigh those answers against your sites, your team and your hours.

This guide is for an IT head or infrastructure lead at a firm with several sites in India or the GCC. You have decided to monitor the network, and now you must pick a tool or a service. In this guide, a monitoring tool means any software that collects readings from your links and devices and alerts a person.

The guide works in four moves: settle four facts, compare three routes, ask nine questions and apply five rules. It suits a firm with several branches, where branch links, night cover and local support hours decide the outcome.

How to Choose Network Monitoring Tools: Four Facts to Settle First

Write down four facts before you speak to any supplier. Each one is a decision for a person, and each one changes which questions matter later. A link, in this guide, is a connection between two sites or between a site and the cloud.

1. Sites and devices: the number of sites and devices you run now, and the number you expect in 18 months.
2. Day-to-day owner: who looks at the monitoring every working day, and who covers that person on leave.
3. Data location: where your monitoring data may be kept, in line with your own rules in each country.
4. Night answer: who answers an alert at night and at weekends, and who answers if that person does not.

A firm that settles these four facts can choose by its own needs, not by a supplier’s demonstration. For example, a firm with plants in Pune and Dammam may find that fact 4 outweighs everything on a feature list. Facts 1 and 2 also decide how much of the work you want to hand over. Network design for a firm with many sites is a larger subject than this guide, so read enterprise networking for the wider picture.

Three Routes to Compare Before Choosing Network Monitoring Tools

There are three routes, and the table sets them side by side. These are Signisys’ working descriptions, not a standard. Each row ends with a question for the supplier, because the supplier’s answer matters more than the label.

Routes combine. For example, a firm can run a tool itself in head office and hand its branches to a managed service. When you weigh the options, decide the route first, because the nine questions that follow read differently for each one.

Questions to Ask a Supplier About Network Monitoring Tools

Put the same nine questions to every supplier, and get the answers in writing so you can set them side by side. The nine questions come in three groups of three.

Size, Device Makes and Branch Reach

Questions 1 to 3 test whether the supplier understands a firm that spreads across sites. They carry the greatest weight when you shop for network monitoring tools for multiple sites, as every extra branch adds links, devices and readings.

1. How do you count size (sites, devices, interfaces), and what changes in that count as we add some? Ask for the answer in writing.
2. Which makes of device do you cover, and how does discovery find a new one on the network?
3. How do you reach a branch with a weak or shared link?

For question 1, hold the supplier to your own numbers from fact 1. Give the supplier today’s count and the 18-month count, and ask which of them each answer applies to. For question 2, list the device makes in your estate and ask the supplier to mark each one as covered or not covered. A person must then check the covered ones against the supplier’s documentation.

Question 3 matters at branches. Some run on a software-defined WAN, where central policy steers traffic across the available lines. Ask how the supplier reads each line beneath it, and how readings reach you when the branch link is the thing that has failed.

Cloud Links, Thresholds and Alert Routing

Questions 4 to 6 test how readings become a decision. They link to the work of setting monitoring up, which the eight set-up steps cover.

1. Which collection methods do you support (device polling, traffic records, streaming and synthetic tests), and how are cloud links covered?
2. How do you record a baseline per site, and how do you set thresholds from it?
3. Where does an alert go at night, and what happens if the first person does not answer?

For question 4, name your cloud links, such as a private line into a cloud region or a mixed own-and-provider setup. Then ask the supplier to say which collection method covers each link. A baseline, for question 5, is the record of what a site’s links read when nothing is wrong. Ask whether the supplier keeps one per site or one for the whole estate.

Question 6 deserves the longest answer. Ask for the route in steps: who gets the alert, by what channel, after what wait without an answer, and who comes next. Then compare that route with your fact 4.

Integration, History and Where the Data Sits

Questions 7 to 9 test what happens around the tool: your other systems, your records and your data.

1. Which ticketing and chat tools do you connect to, and is the interface documented?
2. How long do you keep history, and can we report uptime to a customer or an auditor?
3. Where is our monitoring data stored, who at your end can see it, and what support hours do you offer in India and the GCC?

For question 8, the UK’s National Cyber Security Centre (NCSC) recommends storing important logs for at least 6 months, as the NCSC’s note on keeping log data (2021) explains. That note is written for cyber security professionals and covers security logs. It says the period may vary by log source, so treat 6 months as a starting point for your own retention period. Then ask the supplier whether history can be exported as a report for a customer or an auditor.

Question 9 holds three questions in one, so split it into three lines in your comparison sheet. Check which rules apply to your firm in each country where you have sites, and let your own legal or compliance contact confirm the answer.

Decision Rules for Network Monitoring Tools

Five rules turn the nine answers into a choice. Each one starts from a fact about your firm and names the questions to weight.

Apply the rules in order of how much your firm cares. If two rules point to different suppliers, a decision for a person follows: the person who owns fact 2, the day-to-day owner, makes the final call and writes down why.

Run It Yourself or Use a Managed Service: Where Your Team Fits

Three questions about your own team decide this. They are for a person to answer honestly, not for a supplier.

• Team size: can two people cover the monitoring on leave and on a bad day? If not, the managed route from the table deserves a closer look.
• Night cover: does a named person answer alerts at night in every country where you have sites? If not, a managed service or a shared rota is a decision to make now.
• Upkeep: does your team want to maintain the tool, its devices list and its rules? If not, ask each supplier of a hosted or managed route which of that work they take on.

Signisys runs network monitoring as a managed service, so this section is not neutral advice. Weigh it as you would any supplier’s answer to the nine questions, and ask us the same nine. The use case page on monitoring across all your sites sets out what that work covers, and our network infrastructure support team runs it.

What This Guide to Network Monitoring Tools Leaves Out

This guide helps you choose. Other subjects have their own articles.

• Cloud application monitoring: see tools for watching cloud applications.
• Scored reviews of a running set-up: see ten scored checks.
• Causes of slowdowns: see why users notice slowdowns first.
• Link design and Wi-Fi coverage are separate subjects.

Bring in a specialist when your estate has links, sites or rules that this guide does not cover.

Network Monitoring Tools FAQ