Network monitoring setup
The client’s firewalls, switches and access points reporting into your RMM or monitoring tool, with alerts that are worth acting on.
The work is in deciding what deserves an alert, what can wait, and what should never wake anyone. Get that wrong and within a few weeks nobody reads the alerts at all.
Level 2 switch has lost its uplink
Port 48 on the core switch has been down for a minute. The Level 2 switch and its six access points are unreachable because of it.
From the comms cupboard to your team
Every alert travels the same path. Each step has its own decisions, and most monitoring problems trace back to one of them.
-
On the client’s network
The equipment
Firewalls, switches and access points report their state over SNMP and, where your tool collects it, send syslog. Polling answers “is it up, how busy is it”. Syslog says what happened the moment it happens.
SNMPv3 with authentication and encryption wherever the device supports it. Where only v2c is available: read-only, a community string that isn’t the default, and answering only the collector.
-
On the client’s network
The collector
A device on site that your tool uses as its probe, where your tool needs one. Polling runs from the inside, so no device’s management interface has to be reachable from the internet.
Cloud-managed equipment such as Meraki is often better read through its management platform than polled box by box. Which way depends on the equipment and on what your tool can take in.
-
Your RMM or monitoring tool
Devices and alerts
Each device added and grouped by site, with the parent and child relationships that let your tool tell a cause from its consequences, and alerts set for outages, link failures and the other events that matter.
-
Your service desk
The right person
Alerts routed by severity and time of day to match your alerting preferences: on-call for an outage, a ticket for something that can wait until morning, and nothing at all for events that only belong in the log.
The one failure a site can’t report itself
When the client’s internet goes down, the collector goes quiet with it. It can’t report a lost connection over the connection it has lost.
So the alert for a whole site going dark has to come from your tool noticing that nothing has arrived. It’s easy to miss because it’s the one alert that isn’t triggered by an event, and it’s the one the client will ask about first. We set it up deliberately and check it fires.
The calls that decide whether anyone reads the alerts
Most of the setup is judgement rather than configuration. These are the questions we answer for every site, with your preferences as the starting point.
- Which ports deserve an alert?
- Uplinks, links between switches, internet connections, and the ports serving servers, storage and the phone system. Not desk ports: a laptop lid closing is not an incident. Alerting on every port is the quickest way to teach a team to ignore all of them.
- How long does down have to last?
- A link that drops for two seconds and comes back belongs in the log. Each alert gets its own wait, long enough to ride out a blip and short enough that a real outage isn’t sitting unread. A port that keeps bouncing is its own alert, because it usually means a failing cable or optic.
- What failed first?
- When an uplink goes, everything behind it goes quiet. With dependencies set, the alert names the uplink and lists the rest as affected, rather than opening a ticket for every device on the floor.
- Is it an outage, or the warning before one?
- Losing one of two internet links, one of two power supplies or one firewall in a pair leaves the client running. That still needs to reach someone, because the second failure is the outage, and a redundant link that fails silently is no longer redundant.
- Who hears about it, and when?
- Your alerting preferences decide where each severity goes: on-call after hours, a ticket during business hours, or a record with no notification. Set in your tool, so the same rules apply across the client’s network.
- Can it be understood at 2am?
- An alert should say which site, which device, what that device does, and what changed: Level 2 switch has lost its uplink rather than Gi1/0/48 down. Devices are named in your tool so alerts read that way.
Then we tune: every alert gets a verdict
The first alerts after monitoring goes live show where the thresholds are wrong. Tuning means going through what fired, one alert at a time, and deciding what each is for. A few examples of how that goes:
| Event | Verdict | Why |
|---|---|---|
| site: nothing heard from the collector | Page | Both internet links are likely down. The site can’t say so itself, so this alert comes from your tool noticing the silence. |
| fw01: WAN1 down, WAN2 carrying traffic | Ticket | The client is still online. Someone needs to chase the carrier before the second link goes. |
| core-sw1: power supply 2 failed | Ticket | Running on one supply. Fix it during business hours, not at 2am. |
| fw01: CPU above 90% | Wait | Alert only if it stays there. A short burst during a backup or update is normal. |
| l2-ap-01 to l2-ap-06: unreachable | Group | A consequence of the uplink failure, listed under it rather than six tickets. |
| l2-sw1: Gi1/0/24 up and down 12 times in an hour | Ticket | A bouncing port usually means a failing cable or optic, and users on it are having a bad day. |
| fw01: admin login, configuration saved | Record | Kept in syslog as change history. Nobody needs a notification. |
| l2-sw1: Gi1/0/12 down (desk port) | Drop | Someone took their laptop home. |
What you’re left with
Devices monitored
The client’s firewalls, switches and access points in your RMM or monitoring tool, polled securely from inside the network and grouped by site.
Alerts in your tool
Alerts for outages, link failures and other key events, tuned to cut noise and routed the way your service desk works. Your team runs them from there.
Monitoring documentation
What’s monitored and how, which alerts are set, their thresholds and waits, and where each one goes. When the client asks what’s being watched, or a new engineer picks up the site, the answer is written down.
Equipment we work with: Fortinet, Palo Alto Networks, Cisco, Meraki, SonicWall, WatchGuard, Sophos, Check Point, Juniper and Huawei.
Hand us the setup, keep the client
Delivered remotely as a white-label project, under your brand or as your named partner. We quote and invoice you at a fixed price for the agreed scope, and the monitoring stays in your tool.
Request a quote for this project