Network Monitoring Guide

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

Monitoring is a question you intend to act on

A monitor asks a question on a timer and keeps the answer. The question should be one you will act on. CPU graphs nobody reads are not operations. A full disk, a down peer, a link at the threshold you set, and a power supply that failed are questions with owners. Assign the owner when you add the check, not when it pages someone at night.

SNMP, streaming telemetry, and flow records answer different questions. SNMP polling reads a value. A trap or a notification says a device wanted you to know something. Flow says who talked, in summary, not the packet contents. Do not collect flows in the hope they replace a capture, and do not poll SNMP in the hope it explains an application. Pick the tool that matches the question.

SNMPv3 can authenticate and encrypt the poll. Community strings in v2c are passwords that are often still set to a guessable default. If you must use a community, use one that is not public or private, restrict who can ask, and treat the string as a secret. Do not put it in the ticket. The lookup page on this site can explain an OID you name. It does not log into your routers.

Storage grows with the interval and the retention. A flow record kept for a year at full detail is a disk array. Sampling exists so you can keep a year of a summary. Write the sampling rate and the retention in the same sentence. A retention of seven days will not answer a question about last quarter. Decide which questions are that old and store those on purpose.

What a polling plan costs

50 devices, 20 values each, every 60 seconds, is about 60000 polls an hour before retries and before walks that return more than one value. That is the load you are about to ask the network and the monitoring station to carry. A shorter interval feels more precise and it can be the outage if the devices or the station cannot answer. Five minutes is enough for a link that changes slowly. One minute is reasonable for a link you are actively worried about. Ten seconds on a thousand devices is a second monitoring project, not a checkbox. Write the interval next to the reason. If you cannot name the decision the extra samples change, lengthen the interval.

200 devices, 30 values each, every 60 seconds, is about 360000 polls an hour before retries and before walks that return more than one value. That is the load you are about to ask the network and the monitoring station to carry. A shorter interval feels more precise and it can be the outage if the devices or the station cannot answer. Five minutes is enough for a link that changes slowly. One minute is reasonable for a link you are actively worried about. Ten seconds on a thousand devices is a second monitoring project, not a checkbox. Write the interval next to the reason. If you cannot name the decision the extra samples change, lengthen the interval.

200 devices, 30 values each, every 300 seconds, is about 72000 polls an hour before retries and before walks that return more than one value. That is the load you are about to ask the network and the monitoring station to carry. A shorter interval feels more precise and it can be the outage if the devices or the station cannot answer. Five minutes is enough for a link that changes slowly. One minute is reasonable for a link you are actively worried about. Ten seconds on a thousand devices is a second monitoring project, not a checkbox. Write the interval next to the reason. If you cannot name the decision the extra samples change, lengthen the interval.

1000 devices, 15 values each, every 300 seconds, is about 180000 polls an hour before retries and before walks that return more than one value. That is the load you are about to ask the network and the monitoring station to carry. A shorter interval feels more precise and it can be the outage if the devices or the station cannot answer. Five minutes is enough for a link that changes slowly. One minute is reasonable for a link you are actively worried about. Ten seconds on a thousand devices is a second monitoring project, not a checkbox. Write the interval next to the reason. If you cannot name the decision the extra samples change, lengthen the interval.

Flow records and what they are not

A flow is a summary of a conversation: addresses, ports, sizes, times. It is useful for who filled a link and for whether a prefix is talking to a prefix. It is not a capture. You cannot reconstruct a page from it, and you should not try. That limit is a virtue. You can keep flows when you could not keep packets.

Sampling means you keep one in N. A one-in-1000 sample can show a link filler and can miss a small flow. Do not use a sampled flow to prove a single user's transaction happened. Use it to explain a saturated interface. If you need the single transaction, that is an application log or a short capture, with the rules from the packet guide.

Exporters send flows to a collector. The exporter's address and the collector's address belong in the diagram. An exporter sending to a collector that was decommissioned is a silent failure. Alert on the absence of flows from a device that should send them. Absence is the signal. A dashboard that stays green because it shows yesterday's data is not a dashboard.

Retention and access are a privacy question. Flows show who talked to whom from your network. Limit who can query them, and keep them only as long as the operational question requires. A year of unsampled flows for curiosity is a liability. A month of sampled flows for capacity is a tool.

Paging and thresholds

Page a human only when a human must act. A link down at a branch during the day is a page if the branch cannot work. A CPU spike that cleared itself is not a page. Write the action in the alert text. An alert that says problem is a puzzle. An alert that says the uplink to closet B is down, the rollback is not a reboot, look at the patch and the trunk, is an alert.

Thresholds come from the capacity guide. A link paged at 95 percent of the contracted rate for fifteen minutes matches a plan. A link paged at 50 percent because the default was 50 percent will train people to ignore pages. Defaults are not thresholds. Set them from the busy hour you measured.

Maintenance windows silence alerts on purpose, for the devices in the window, for the duration of the window. A silence that lasts until someone remembers to turn it off is an outage you will not see. Put an expiry on the silence. The change ticket should name the silence and the person who lifts it.

Test the page. An alert that has never paged will not page when you need it, because the address or the on-call rotation is wrong. Send a test to the rotation you actually use. Then fix the rotation, not the diagram.

A link that paged, and the question it should have asked

An alert says the branch circuit is high. The graph shows 900 megabits per second on a 1 gigabit service for twenty minutes, in the outbound direction, at 13:00. The capacity note says the busy hour is usually 400 megabits inbound at 09:00. This is not the busy hour you planned. It is a new transfer. Flow records, if you have them, should show which inside prefix is speaking. A single branch server copying to a cloud prefix is a backup window aimed at noon. The action is to move the window or to accept a larger circuit, not to retune the alert so it stops speaking.

If flows show many inside hosts each sending a little, the alert is the real busy hour arriving early and the forecast was wrong. Update the forecast. Do not delete the alert. If flows show one host sending to many destinations on unusual ports, the action is the security on-call and the host owner, and the monitoring page has done its job by pointing. It does not need to contain a theory about the host. The packet guide is the next step only if a short, authorised capture is required.

The SNMP poll that fed the graph was every minute, which was enough to see a twenty-minute event. A five-minute poll would also have seen it. A poll every ten seconds would not have changed the decision. Leave the interval. Check that the alert named the direction and the contracted rate. An alert that said utilisation high without the rate would have wasted the first ten minutes. Fix the text now, while the incident is still memorable.

Afterward, write the retention that let you see the event. If the flow collector only keeps a day, you were lucky the page happened today. If the question you will be asked next month needs a month of samples, keep the summary that long and no longer. The incident is also a storage decision. Make it while the numbers are in front of you.

Adding one check

Name the question, the owner, the interval, and the action. Then add the check. Then confirm the value matches a login to the device or a command you trust. A green check that does not match the device is worse than no check. It will be trusted.

Restrict who can poll. Management plane access is the hardening guide's subject. A monitor that can ask every device is a monitor that must be treated as an admin system. Its credentials are admin credentials. Store them as such.

Review the noisiest alerts monthly. Delete or retune the ones nobody acts on. A system that pages constantly is a system people mute. Muting is how real outages hide. The work of monitoring is the deletion as much as the addition.

Write the question and the action.
Choose poll, trap, or flow, and write why.
Set the interval and the retention.
Keep secrets out of the ticket.
Confirm the first value against the device.
Send a test page to the real rotation.
Expire the maintenance silence with the change window.

Mistakes that make monitoring lie

Community strings of public and private left in place.

A ten-second poll on every value of every device.

Paging on a default threshold nobody chose.

Keeping full flows forever because disk was cheap once.

A silence with no expiry.

A green dashboard fed by yesterday's file.

Using a flow sample to accuse a person of a single act.

Storing the SNMP secret in the ticket.

Monitoring checks before you rely on a page

Confirm this before you call the change done: Each alert has an owner and an action written in the text. The interval matches a decision, not a desire for more graphs. SNMPv3 or a restricted community is in use, and the secret is not in the ticket. The poll source is allowed only from the monitoring station. A test page reached the current on-call. Flow sampling and retention are written in one sentence. Absence of expected flows alerts. Maintenance silence expires. The noisiest alert from last month was tuned or removed. The first value was checked against the device itself. The alert text includes the direction and the contracted rate. A noon spike was compared with the planned busy hour before the threshold was raised. And flow retention matches the oldest question you still intend to ask. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.

Companion: System: SLA and Uptime Explained.