It is three o'clock in the morning. Your database server has run out of disk space, your e-commerce transactions are starting to fail and customers are abandoning their shopping carts. Nobody notices until nine in the morning, when the support team arrives at the office and finds dozens of accumulated tickets. By then, the losses are already real: unprocessed sales, damaged reputation and a breached SLA that may translate into contractual penalties.
This scenario is not hypothetical: it is the reality of thousands of companies that operate IT infrastructure without 24/7 monitoring. Critical problems do not wait for working hours. Disks fill up at four in the morning, SSL certificates expire on weekends, DDoS attacks are launched on public holidays and power supplies fail when least expected. Without continuous surveillance that detects anomalies in real time and notifies the right people, every incident is a ticking time bomb that is only discovered after it has already gone off.
In this article we examine what it truly means to monitor infrastructure continuously, what elements need to be watched, what tools are available, how alerting and escalation work, and why an increasing number of companies outsource this critical function to specialist providers like EasyDataHost.
What to Monitor: The Five Pillars
Effective monitoring is not about watching a single indicator. To obtain a complete picture of infrastructure health, you need to cover five fundamental areas:
- dns Servers: CPU usage, RAM, disk space, disk I/O, system load and hardware temperature. A server that consumes 95% of its RAM for hours will eventually trigger an OOM killer that terminates critical processes without warning.
- web Services: status and response time of HTTP/HTTPS, databases (MySQL, PostgreSQL, MongoDB), mail servers (SMTP, IMAP), message queues (RabbitMQ, Redis) and any service that supports the business. A service that responds but with 10-second latencies is as problematic as one that is down.
- lan Network: bandwidth utilisation, latency, packet loss, interface status, switch and router errors. Network problems are often the hardest to diagnose without historical monitoring data.
- shield Security: intrusion attempts, port scans, brute-force login failures, unexpected changes to critical files and the status of firmware. Early detection of suspicious activity is the first line of defence.
- thermostat Physical environment: temperature, humidity, power supply status and UPS. In a data centre, a cooling system failure can cause a general outage within minutes if not detected in time.
Monitoring Types: Reactive vs Proactive
Reactive monitoring is limited to generating alerts when something has already failed: a service is down, a disk is full, a certificate has expired. It is the bare minimum, but insufficient for a mature operation. By the time you receive the alert, the damage is done and users are already affected.
Proactive monitoring goes one step further: it analyses historical trends, detects degradation patterns and generates predictive alerts. If a disk is growing at a rate that will fill it in 72 hours, the alert fires now, not when there is no space left. If database latency has increased by 300% over the past week, it is investigated before users are affected. This approach turns monitoring from a firefighting system into a capacity planning tool.
Another key distinction is between black-box and white-box monitoring. Black-box monitoring checks the service from the outside as a user would (an HTTP request, a ping, a connection attempt). White-box monitoring accesses internal system metrics (kernel counters, application metrics, structured logs). A complete strategy combines both perspectives: black-box to detect what the user perceives, white-box to understand why it is happening.
Key concept:
Reactive monitoring tells you that something has failed. Proactive monitoring tells you that something is going to fail. The difference between the two is the difference between fighting fires and preventing them.
Popular Monitoring Tools
The monitoring tools ecosystem is vast. Solutions fall into two main categories: open source and commercial. The choice depends on infrastructure size, team expertise and available budget:
- monitoring CheckMK: an enterprise monitoring platform based on agents, with auto-discovery, smart thresholds, dashboards and a powerful alerting pipeline. It is the tool EasyDataHost uses for its Monitoring as a Service offering.
- monitoring Zabbix: a mature open-source solution with support for SNMP, agents, IPMI and JMX. Highly flexible, capable of monitoring thousands of nodes, but with a significant learning curve for advanced configurations.
- monitoring Prometheus + Grafana: the standard combination in the cloud-native and Kubernetes ecosystem. Prometheus collects metrics using a pull model, Grafana visualises them. Excellent for containerised environments, but less suited to traditional infrastructure without instrumentation.
- monitoring Nagios: the veteran of monitoring. Still widely used but its architecture has fallen behind more modern solutions. CheckMK was born precisely as a Nagios extension that overcame its limitations.
- monitoring Datadog and PRTG: commercial SaaS solutions with quick setup and visual dashboards. Ideal for teams that want immediate results without investing in monitoring infrastructure management, but with per-host costs that scale quickly.
CheckMK in Depth
CheckMK deserves a dedicated section because it is the tool that underpins EasyDataHost's monitoring service. It is a complete platform that covers the entire cycle: service discovery, metric collection, threshold evaluation, alert generation and dashboard visualisation.
The CheckMK agent is installed on each monitored server and collects hundreds of metrics without manual configuration. The auto-discovery function automatically detects the services running on each host (databases, web servers, critical processes, network interfaces) and begins monitoring them with predefined thresholds that can be adjusted later. This drastically reduces deployment time: instead of manually configuring each check, the system discovers what needs to be monitored and starts doing so.
CheckMK's smart thresholds distinguish between three states: OK, WARNING and CRITICAL. Unlike a simple fixed threshold, CheckMK can calculate dynamic thresholds based on the historical behaviour of each metric, reducing false positives. The alerting pipeline allows granular rules to be defined: who receives the notification, through which channel (email, SMS, Telegram, PagerDuty), at what time and with what escalation policy if there is no response.
Learn more about how EasyDataHost uses CheckMK in our Monitoring as a Service page.
What to Monitor by Service Type
The following table summarises the key metrics, recommended thresholds and alert levels for the most common infrastructure services:
| Service | Key Metrics | WARNING Threshold | CRITICAL Threshold |
|---|---|---|---|
| Web server | HTTP status, latency, active connections | Latency > 2s | Service down or 5xx > 5% |
| Database | Queries/s, slow queries, connections, replication lag | Slow queries > 10/min | Replication lag > 60s or connections exhausted |
| Backup | Job status, duration, size, last execution | Duration > 2x normal | Job failed or no execution in 24h |
| Storage | Free space, IOPS, latency, RAID/Ceph status | Disk > 80% used | Disk > 95% or degraded disk |
| Network | Bandwidth, latency, packet loss, interface errors | Packet loss > 0.1% | Interface down or loss > 1% |
| Virtual machines | CPU, RAM, disk, VM status, snapshots | CPU > 85% sustained 15 min | VM unresponsive or RAM > 95% |
Alerting and Escalation: Getting the Alert to the Right Person
There is no point in detecting a problem if the notification gets lost in a full inbox or reaches the wrong person. A well-designed alerting system has several layers:
- notifications_active Notification channels: email for informational alerts, SMS and phone calls for critical alerts outside working hours, Telegram or Slack for on-call teams, and platforms such as PagerDuty or Opsgenie for advanced incident management.
- group On-call rotations: rotating shifts that ensure someone is always available to respond. Without clear rotations, night-time alerts are ignored or cause burnout for the same individual.
- escalator_warning Escalation policies: if the first-line responder does not acknowledge within 15 minutes, the alert escalates to the next level. If nobody has acknowledged the incident within 30 minutes, it escalates to management. Without escalation, a critical alert can go unattended for hours.
- menu_book Runbooks: documents that describe step by step how to respond to each type of alert. A well-written runbook enables an on-call engineer to resolve an incident at 3 AM without needing a senior. They reduce MTTR (Mean Time To Resolve) dramatically.
SLA and Monitoring: Two Sides of the Same Coin
A service level agreement (SLA) commits to an availability percentage (99.9%, 99.95%, 99.99%). But an SLA without monitoring is worthless: if you cannot measure actual uptime, you cannot prove that you are meeting it or detect when you are breaching it.
Monitoring is the tool that turns an SLA into something measurable and actionable. Every minute of undetected downtime is a minute that counts against your availability. The sooner you detect an incident, the smaller its impact on the SLA. This connects directly with the concepts of RPO and RTO: the incident detection time is the first component of RTO, and reducing it from 30 minutes to 30 seconds can make the difference between meeting and breaching the agreement.
Furthermore, historical monitoring data makes it possible to generate availability reports that demonstrate SLA compliance to clients and auditors. Without this data, any customer claim becomes a subjective discussion without evidence.
Monitoring as a Service: Outsource the Oversight
Building and operating an in-house 24/7 monitoring infrastructure requires on-call staff, rotations, tools, dedicated servers and deep knowledge of each monitored technology. For many companies, maintaining their own NOC (Network Operations Centre) is neither economically viable nor strategically sensible.
The alternative is Monitoring as a Service (MaaS): outsourcing monitoring to a specialist provider that already has the infrastructure, the tools and the human team operating 24 hours a day, 365 days a year. The provider monitors your infrastructure, manages the alerts, executes first-response runbooks and escalates to your team only when necessary.
The advantages are clear: 24/7 coverage without hiring a night-shift team, experience accumulated across thousands of different infrastructures, and your team can focus on what truly adds value to the business instead of watching dashboards at 3 AM. EasyDataHost offers this service powered by CheckMK as part of its managed services catalogue.
Common Monitoring Mistakes
Implementing monitoring does not automatically guarantee that it will be useful. These are the mistakes we see most frequently in companies that already have monitoring tools deployed:
- warning Monitoring everything without criteria (alert fatigue): when everything generates alerts, nothing is urgent. Teams begin ignoring notifications due to saturation and the one truly critical incident gets lost among hundreds of irrelevant warnings. The solution is to prioritise: only alert on what requires immediate human action.
- warning Monitoring nothing: the opposite extreme. Companies that trust their servers to "run on their own" and only discover problems when a customer calls to complain. In the age of SLAs and guaranteed availability, this is unsustainable.
- warning No runbooks: the alert arrives, but nobody knows what to do. The on-call engineer wastes 30 minutes searching for documentation or waiting for a senior to answer the phone. Every critical alert must have a documented response procedure.
- warning Ignoring trends: looking only at the current state without analysing historical trends is like driving while watching only the speedometer without paying attention to the fuel gauge. Trend metrics predict future problems and allow you to act before they occur.
Practical rule:
If an alert fires more than three times without requiring human action, it is not an alert: it is noise. Adjust the threshold, downgrade it to informational or remove it.
EasyDataHost Monitoring as a Service
EasyDataHost's Monitoring as a Service is built on CheckMK and operated by a team of engineers available 24 hours a day, 7 days a week. We deploy CheckMK agents on every server, configure the checks and thresholds specific to your infrastructure and take care of the entire alerting and first-response chain.
- check_circle CheckMK enterprise: auto-discovery, smart thresholds and custom dashboards tailored to your infrastructure.
- check_circle Real-time alerts: notifications via email, SMS and Telegram with automatic escalation if there is no response.
- check_circle 24/7 team: on-call engineers who respond to critical alerts at any time, including nights, weekends and public holidays.
- check_circle Monthly reports: availability reports, capacity trends and proactive recommendations to prevent future incidents.
Conclusion
24/7 monitoring is not a luxury or a nice-to-have: it is a fundamental component of any serious production infrastructure. Without it, incidents are discovered late, SLAs are breached, trends go unnoticed and teams operate blindly.
- arrow_right Monitor the five pillars: servers, services, network, security and physical environment.
- arrow_right Combine reactive and proactive monitoring, black-box and white-box.
- arrow_right Set up alerting with escalation, runbooks and clear on-call rotations.
- arrow_right Monitoring is the foundation that underpins SLA compliance.
- arrow_right EasyDataHost MaaS provides 24/7 monitoring powered by CheckMK without the need to build your own NOC.
If you want to ensure continuous oversight of your infrastructure without the complexity of running it in-house, contact our team to design a monitoring plan tailored to your needs.