Most organizations have monitoring. Rather fewer have monitoring that would tell them, promptly and to the right person, that something a user cares about has stopped working. The gap between those two states is not usually a tooling problem, and buying a better product rarely closes it.
This page covers what infrastructure monitoring is for, what to instrument, how to decide what deserves an alert, and how the operational side of it actually runs.
What monitoring is actually for
There are three distinct jobs, and conflating them produces systems that do none of them well.
Detection. Knowing that something has failed, quickly, without a user reporting it. This is the job with the hard time constraint.
Diagnosis. Working out why, once you know. This needs depth and history rather than speed, and the data required is usually different from the data that raised the alert.
Planning. Understanding trends so that capacity and lifecycle decisions are forecasts rather than reactions. This needs long retention and nobody being woken up.
A system tuned for detection and asked to do diagnosis frustrates everybody. A system that collects everything for diagnosis and alerts on much of it produces noise that destroys detection. Deciding which of the three a given signal serves is most of the design.
Instrument what indicates failure, not what is easy
The default failure mode is to collect what the agent offers. That produces exhaustive host metrics and no answer to whether the service works.
A more useful order is to start from the service and work down. Can a user complete the transaction that matters? Is the application responding within the time it should? Are its dependencies answering? Then, beneath that, the host and platform metrics that explain why not.
Synthetic checks that exercise a real path are worth more than their cost for this reason. A host can be entirely healthy by every local measure while the service it exists to provide is unreachable because of a certificate, a DNS record or a firewall rule, and only something that traverses the whole path will notice.
The four signals worth having everywhere
- Availability. Is it answering, from where the user is, over the path the user takes.
- Latency. How long it takes, expressed as a distribution rather than a mean, because averages conceal exactly the tail that generates complaints.
- Saturation. How close a resource is to its limit: processor, memory, disk, network, connection pools and file handles. This is the family that predicts rather than reports.
- Errors. Rate and type, which is usually the earliest signal that a deployment has gone wrong.
Storage capacity deserves a specific mention because it is the most reliably predictable failure in infrastructure and still a common cause of outages. A disk filling is visible weeks ahead in the trend and only becomes an incident when nobody looked.
Alerting is a decision about who gets woken
An alert should mean that a human needs to do something now. Everything else is a dashboard, a report or a ticket.
Applied honestly this removes most of what typically alerts. A processor at ninety percent for five minutes is not actionable. A processor at ninety percent for an hour on a host serving a customer-facing service might be. A failed backup job is a ticket for the morning; a failed backup job three nights running is an alert.
The test to apply to every alert is simple: what would the person receiving this actually do? If the answer is look at it and go back to sleep, it is not an alert. Alert fatigue is not a personal failing, it is the predictable result of pages that do not require action, and it ends with the one that mattered being skimmed alongside the rest.
Escalation has to be decided in advance
The route from a signal to a person is the part that is improvised during an incident if it was not agreed before one. It needs a named first responder for each period, a defined time after which it escalates, a second person it escalates to, and a documented path to whoever can authorize a decision that costs money or takes a service down.
It also needs a way to suppress during planned work. Nothing trains a team to ignore alerts faster than a maintenance window that pages continuously.
This is not security monitoring
The two are frequently merged in procurement and should not be merged in operation. Infrastructure monitoring asks whether the service is working. Security monitoring asks whether something hostile is happening. They watch different data, at different thresholds, with different responses and different people.
A processor at full utilization is an infrastructure signal about capacity and a possible security signal about something unauthorized running. The same number, two questions. Running them as one function means one of the two gets the attention. LABUSA runs security operations as Managed Cybersecurity Services, alongside rather than inside this service, and the two share data deliberately.
Logging: decide retention before you need it
Logs are where diagnosis happens and where cost accumulates quietly. Three decisions matter: what is collected, how long it is kept, and whether it is searchable in the time an incident allows.
Unbounded retention is expensive and rarely deliberate. Short retention is cheap and discovers its limit at the worst moment, when the question is when did this start and the answer is beyond the window. Tiering, with recent data searchable and older data archived, is usually the workable compromise, and it should be chosen rather than defaulted.
Trends are the output nobody asks for
The reporting that earns a managed service its keep is rarely the incident count. It is utilization against headroom with a projection, the support status of the estate, patch compliance over time, and the measured result of recovery exercises.
Those four turn infrastructure from a thing that occasionally breaks into a thing with a forecast, which is what makes it possible to fund work before rather than after. Designing Infrastructure for High Availability depends on exactly this data.
Where monitoring sits in a recognized framework
It helps to be clear that detection is a named discipline rather than a tooling preference. The NIST Cybersecurity Framework organizes outcomes under six functions, GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, and RECOVER, and treats detection as a first-class capability with its own outcomes rather than a by-product of having bought something. See The NIST Cybersecurity Framework (CSF) 2.0.
The framework is a security instrument and the point transfers directly to infrastructure: the questions of what you are able to detect, how quickly, and what happens next are separable from the question of which product is installed. An organization that can answer those three has a detection capability. One that can only name its monitoring vendor does not yet.
Cloud providers make a related argument from the reliability side. AWS lists among its reliability design principles that systems should recover automatically from failure and that recovery procedures should be tested, both of which presuppose that failure is detected accurately enough to act on automatically. See the AWS Well-Architected reliability design principles. Automated recovery built on noisy detection is worse than manual recovery, because it acts confidently on a wrong signal.
What good looks like after six months
A monitoring capability that is working has a few observable properties, and none of them is the size of the dashboard.
- Users stop being the detection mechanism. The proportion of incidents first reported by a person rather than by a system falls, and somebody is tracking that proportion.
- Alert volume is small enough to read. Every page in the last month can be reviewed in one sitting, and each one had an action.
- Capacity work is scheduled. Storage and compute additions happen on a plan derived from the trend rather than in response to a threshold.
- Post-incident reviews change the instrumentation. Each incident that was detected late results in a new check, and somebody can point at the ones added.
Those four are worth reviewing quarterly, because monitoring decays in a specific way: checks accumulate, thresholds are loosened after a noisy night and never tightened, and the coverage that mattered a year ago no longer matches what the estate runs.
Monitoring the monitoring
A monitoring system that fails silently is worse than none, because it converts absence of alerts into evidence of health. The system needs its own external check, its notification path needs periodic testing, and somebody needs to notice when a host stops reporting rather than only when it reports something bad.
The absence of data is itself a signal, and configuring it as one is the single cheapest improvement available to most estates.
Hybrid estates need one view
Where infrastructure spans private and public environments, the monitoring has to span them too. Two consoles means somebody correlating by hand during an incident, which is precisely when nobody has the time. Hybrid Cloud Infrastructure covers what else has to be common across the boundary.
How LABUSA operates it
Monitoring is part of the managed service rather than a product sold beside it. Instrumentation is chosen against what would indicate service failure, alert thresholds are agreed with the customer rather than shipped as defaults, and escalation is written down before it is needed.
The reporting produced is the trend set above, because that is what makes the next budget conversation a forecast rather than an argument. The operations service monitoring belongs to sets out the wider scope.