A monitoring stack for small ISPs and hosting companies

Small ISPs and hosting companies rarely lack monitoring tools; what they lack is coverage of the things that cause customer-visible outages. This article sets out what to monitor, how to structure a stack a small team can run, and how to turn alerts into an on-call process people can sustain.

The building blocks

A workable stack has four layers. It helps to keep them distinct in your design, even if one product covers several.

1. Collection: SNMP polling, streaming telemetry where devices support it, agents or exporters on servers, and active checks such as HTTP, DNS and ping probes.
2. Storage and dashboards: a time-series store and a way to visualise it. Common open-source choices include Prometheus, Grafana, Zabbix and LibreNMS.
3. Alerting: rules that evaluate the data, plus routing, grouping, silencing and escalation to the right person.
4. External viewpoints: checks run from outside your network, because internal monitoring cannot see that you have disappeared from the internet.

Pick tools your team can maintain. A small stack that covers every device is worth more than a larger one with half the network missing.

Routing: BGP sessions, prefix visibility and RPKI

For a network operator, routing is where the most damaging failures start, and many of them are invisible to ordinary host checks.

• BGP session state: alert when any eBGP session leaves the Established state, and track flaps over time. Separate transit, peering and customer sessions so priorities are clear.
• Prefix counts: monitor received and accepted prefixes per session. A sudden drop from a transit provider, or a customer approaching its max-prefix limit, is worth knowing about before the session tears down.
• Prefix visibility: check from outside that each of your prefixes is visible with the expected origin AS. Public route collectors, looking glasses or a BGP monitoring service can alert you to withdrawals, unexpected origins or more-specific announcements of your space.
• RPKI status: confirm that every prefix you announce, including customer and BYOIP prefixes, is RPKI-valid. Recheck after any change to ROAs, a new announcement or a new upstream. If you run route origin validation, monitor your validators and the freshness of their data.

Interfaces, servers and services

The basics still catch most problems, provided they are measured in the right way.

• Interface errors and discards: CRC errors, input errors and output drops, alerting on the rate of change rather than raw counters.
• Optical levels: receive and transmit power on transceivers that report it, with thresholds set inside the vendor alarm values so you get warning before a link fails.
• Utilisation: per-link traffic with headroom alerts on upstream and core links, plus long-term trends for capacity planning.
• Server health: disk space and growth rate, memory, load, RAID and hardware status, and resource contention on hypervisors.
• Service checks: test the service, not just the host. Resolve a name against your resolvers, fetch a page through the load balancer, send a test message through the mail relay.

Reputation and certificates

These checks catch avoidable outages that often surface only when customers complain.

• Blacklist status: check your IPv4 ranges regularly against major DNS-based blocklists such as Spamhaus, especially mail servers and customer-facing pools. A listing can block a customer’s mail long before anyone opens a ticket, and early warning gives you time to find the cause before requesting removal.
• Certificate expiry: track every TLS certificate you serve, on customer portals, control panels, mail and API endpoints, with alerts well before expiry. Monitor the automated renewal job itself, not just the certificates it produces.
• Domains: the registrations for your own operational domains deserve the same expiry checks.

Alerting and on-call

Alerts are only useful if someone acts on them. Design them for the person who will be woken up.

• Make every alert actionable: if the usual response is to ignore it, turn it into a dashboard item or delete it.
• Use severity levels: page for customer-impacting or imminent failures; send everything else to a queue reviewed in working hours.
• Suppress dependent alerts: when a site uplink fails, one page is enough, not one for every device behind it.
• Plan maintenance: silence affected checks during planned work and make sure they come back afterwards.
• Link a runbook: each paging alert should point to a short note on what it means, how to verify it and the first steps to take.

For on-call itself, keep a published rota with a named primary and secondary, a clear escalation path and a short handover note at the end of each shift. Review pages weekly: which alerts fired, which were noise and which problems were missed entirely.

After significant incidents, hold a short blameless review and feed the findings back into checks and runbooks. A small team should also be honest about coverage: if nobody can respond overnight, either reduce what is promised to customers or arrange external cover.

How TACS can help

TACS provides remote monitoring as part of Infrastructure management, and can set up checks for BGP sessions, RPKI status and blacklist listings alongside server monitoring. If a range is already listed, our Blacklist delisting service handles removal, and an IP security audit shows the reputation of address space before you put it into service.