Infrastructure Monitoring: The Three Collection Methods

Every explainer on infrastructure monitoring organises itself by metric: CPU, memory, disk, network. That is the wrong axis. What decides your coverage is how you collect the numbers, not which numbers you pick. Each collection method reaches certain layers and no others, and each fails in its own characteristic way.

What does the term actually cover?

Infrastructure monitoring is the continuous collection of health and resource data from the components a service runs on: hosts, virtual machines, containers, network devices, storage and cloud resources. It turns that data into dashboards and thresholds that fire when a component drifts out of its normal range. Its purpose is to explain why a service is degraded, rather than to notice that it is.

Gartner's market definition puts it as capturing health and resource utilisation wherever the components reside, which is deliberately broad. The breadth is the point. A modern estate spans a colocation rack, three cloud accounts and a managed database, and the tooling has to reach all of it. IBM's overview of the discipline traces how that scope widened once workloads stopped living on machines you owned.

Three ways the data gets collected

There are only three, and almost every product is a packaging of one or two of them.

Agent-based. A process runs on the host and reports outward. It sees everything the operating system sees: process tables, file descriptors, cgroup limits, disk queue depth. Prometheus node exporters and the collectors shipped by commercial platforms all work this way.

Agentless polling. Something asks the component for its own numbers. SNMP over UDP port 161 for switches and appliances, WMI for Windows, and a cloud provider's metrics API for anything you cannot install software on. No installation, less depth, and the target has to be reachable from the poller. The CloudWatch metric documentation is a fair example of what that last category offers, and at what resolution.

External checks. A probe outside the estate sends the request a client would send and judges the reply. It knows nothing about the internals and everything about the result, which is the exact inverse of the first method.

Which layer does each infrastructure monitoring method see?

Not all three reach the same places, and this is the table most explainers leave out.

Layer	Typical signal	Agent	Agentless poll	External check
Network hardware	port errors, interface saturation	no	yes	no
Host or VM	CPU, memory, disk, load	yes	partly	no
Container	cgroup limits, restarts, OOM kills	yes	via the orchestrator API	no
Managed service	connections, IOPS, replica lag	no	yes	no
Application process	threads, heap, queue depth	yes	no	no
DNS and certificates	resolution, expiry, chain validity	no	no	yes
Public path	reachability, status code, latency	no	no	yes

Read it downward and the gaps are obvious. The bottom two rows have exactly one method that covers them, and it is the one most infrastructure monitoring stacks add last or skip entirely.

What the inside view cannot judge

Agents and pollers share an assumption: that the network carrying their reports is working. When it is not, they go quiet, and quiet reads as healthy on most dashboards. We tested a deliberately partitioned host against a collector and the panel showed the last value it had received, not an error.

That failure mode compounds in a single cloud account. Metrics that flow through the same region as the workload they describe tell you nothing during a regional event. The tooling that exists to explain the outage is inside the outage.

External checks avoid this because they start outside. They also fail differently, in ways worth naming. They cannot see a queue backing up, a heap filling or a replica falling behind. They notice nothing until the problem reaches a user-visible path. Neither view is sufficient. The distinction between the two is unpacked further in our comparison of observability and monitoring.

Where to start

Start at the bottom of that table and work up, not the other way round. Reachability and certificate expiry take minutes to cover and catch the failures that produce the loudest customer reaction.

curl -X POST https://uptimeroom.com/api/v1/monitors \
  -H "Authorization: Bearer urm_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "edge",
    "type": "http",
    "target": "https://example.com/",
    "intervalSec": 60,
    "regions": ["london", "sao-paulo"],
    "certWarnDays": 21
  }'

Two regions have to agree before anything is called down, which keeps a single bad network path off the pager. Six regions are available as of September 2026, and their egress addresses are published on the probe IPs page for firewall rules. Add agents afterwards, once you know which hosts matter, using the per-machine checks in our server health check walkthrough as the shortlist.

Common mistakes

Alerting on resource thresholds. A host at 90 percent memory is information. A host at 90 percent memory whose service still answers in 200ms is not an incident. Page on symptoms, graph the resources, and let the four golden signals decide which is which.

Treating absence of data as health. A stopped agent and a healthy host produce the same flat line on most panels. Every collection path needs its own staleness alert.

Assuming the cloud provider's console counts. It reports on its own resources and stops at the boundary of your account. Cross-account and third-party dependencies are outside its remit entirely.

Good infrastructure monitoring is layered on purpose: agents for depth, polling for the boxes you cannot install on, and an outside check for the path a customer travels. The third layer is the cheapest to add and the one that keeps working when the other two lose their network. Ten monitors on the free plan as of September 2026 covers the public edge of a small estate, which is the right place to begin.