The production server has been responding slowly for two hours. The team knows because client complaints started coming in. Monitoring shows the CPU is at 95%, but doesn't explain why. Someone spends two hours manually reviewing logs until they find that a database query started taking ten times longer from 14:32, right after a deployment.
That is what happens when you have monitoring but not observability. And it is far more common than it seems in mid-sized companies with their own infrastructure or in the cloud.
The difference that matters
Monitoring
Tells you what is happening: CPU, memory, disk usage metrics, service availability. It alerts you when a value exceeds a predefined threshold. It answers known questions: is the server down? Is there disk space left?
Observability
Lets you understand why it is happening: correlates metrics, logs and traces to answer questions you didn't anticipate. When something fails in a new way, observability is what lets you diagnose it without guessing.
A useful analogy: monitoring is the car's instrument panel showing the engine temperature and alerting you if it exceeds 90°. Observability is the garage's diagnostic system that, when the temperature rises, can tell you exactly which sensor is failing, since when and what conditions triggered it.
Practical summary: monitoring detects that something is wrong. Observability lets you understand what, why and since when — without needing manual intervention to correlate information.
The three pillars of observability
Metrics
Numerical values over time: CPU, memory, latency, error rate, requests per second. These are the foundation of classic monitoring.
Logs
Timestamped event records. Every system action, every error, every request is recorded. They are the forensic history of what happened.
Traces
Tracking a request across all the systems it passes through. They let you see where latency is introduced in distributed or multi-service flows.
The key is not having each pillar in isolation, but being able to correlate them: when a latency alert fires, being able to go directly from the metrics graph to the logs of that exact moment, and from there to the trace of the failed request. Without that correlation, diagnosis is always manual and slow.
Why does this matter for an SME?
Observability is usually associated with large companies with dozens of microservices and dedicated SRE teams. But there are very common scenarios in SMEs where the lack of visibility has a real cost:
Conversion rate drops 30% over the weekend. Without observability, nobody notices until Monday. With correlated logs and metrics, an alert would have fired within minutes showing the checkout page load time had exceeded the abandonment threshold.
A sync process between the ERP and the warehouse starts silently failing. Orders appear to be processed but stock isn't updated. Without centralised logs, the problem is detected days later when the warehouse ships an already out-of-stock item.
A disk is filling with error logs at an unusual rate. Without disk space monitoring with early alerts, the server crashes when the disk hits 100%. With basic monitoring plus log analysis, the alert would have fired days earlier.
The open-source stack: Grafana + Prometheus + Loki
The good news is that you don't need to pay for enterprise tools to have a serious observability system. The combination of Grafana, Prometheus and Loki is the reference open-source stack, used by both startups and large-company infrastructure teams.
Metrics collection and storage system. Connects to your servers, containers, databases and applications through exporters (small agents) and stores metrics in a time-series database. It has its own query language (PromQL) that allows very precise alerts based on metric combinations.
- Exporters available for nginx, PostgreSQL, MySQL, Redis, Node.js, Docker and dozens more
- Alertmanager for routing alerts to email, Slack, PagerDuty or any webhook
- Ideal for infrastructure and application metrics
Log aggregation system designed by Grafana Labs. Unlike solutions like Elasticsearch, Loki doesn't index the full log content — only its labels (metadata) — making it far more economical on resources. Logs are stored compressed and queried with LogQL, a language similar to PromQL.
- Native Grafana integration: correlate logs with metrics on the same dashboard
- Promtail as a log collection agent from files or containers
- Consumes far fewer resources than an ELK stack (Elasticsearch + Logstash + Kibana)
The visualisation layer that ties everything together. Lets you build dashboards with Prometheus metrics and Loki logs on the same screen. When a Prometheus alert fires, you can click directly on the graph point and jump to the Loki logs of that exact moment. This correlation is what turns monitoring into real observability.
- More than 80 compatible data sources (AWS CloudWatch, MySQL, InfluxDB…)
- Own alerting system with configurable notification channels
- Community dashboards ready to use for the most common stacks
Smart alerts: the difference between noise and signal
One of the most common traps when implementing monitoring is setting up too many alerts with fixed thresholds. The result is a team that receives dozens of notifications a day, learns to ignore them, and one day misses the important alert buried in the noise.
Useful alerts have three characteristics:
Alert on symptoms, not causes
An alert that says "CPU at 80%" doesn't always require action — it depends on context. An alert that says "API response time exceeds 2 seconds for more than 5 minutes" is actionable because it indicates real user impact.
Include enough context to act
A good alert includes not just the value that triggered it but also the link to the relevant dashboard, the logs for that period and a description of the expected impact. If the recipient has to investigate on their own what it means, the alert isn't well designed.
Use dynamic thresholds where it makes sense
Prometheus lets you create alerts based on trends or deviations from the historical average, not just absolute values. 70% CPU load may be normal during peak hours and anomalous at 3am. Alerts that distinguish that context generate far fewer false positives.
Practical rule: if an alert fires more than twice a week without requiring action, adjust it or remove it. Alerts that get ignored are worse than having no alerts.
Where to start: a realistic roadmap
- Basic infrastructure monitoring
Start with what's most critical: service availability, disk usage, CPU and memory on your main servers. A Prometheus with Node Exporter and a basic Grafana dashboard gives you visibility over the most common failures. Cost: configuration time (half a day) and the server resources where you deploy it.
- Log centralisation with Loki
Add Loki and Promtail to collect your application and service logs in one place. The first immediate benefit is no longer having to SSH into each server to review logs when something fails.
- Correlation in Grafana
Configure the Prometheus and Loki data sources in Grafana and enable correlation between them. From here on, when a metric fires, you can go directly to the logs of that exact moment without switching tools.
- Actionable alerts
Define no more than five or six initial alerts on the most critical symptoms for your business: main application response time, HTTP 5xx errors, disk space below 20%, downed services. Configure notifications to a Slack channel or team email.
- Iterate and expand
Once the basic stack is stable, extend instrumentation to your applications, add business metrics (orders per hour, active users) and refine alerts based on real incidents as they occur.
Do you need a technical team to maintain this?
The Grafana + Prometheus + Loki stack requires initial configuration and periodic maintenance, but doesn't need a dedicated team. Once installed and stabilised, the usual work is adding new metrics when infrastructure changes and adjusting alerts when false positives appear. For an SME with stable infrastructure, that's a few hours a month.
Grafana Labs also offers a managed cloud version of the full stack (Grafana Cloud) with a generous free tier that may be sufficient for small infrastructures, eliminating the need to manage your own observability server.
At EstructuraBit we deploy and configure observability stacks tailored to each company's infrastructure — from a single server to multi-cloud environments. If you want real visibility into what's happening in your systems, get in touch.
Back to blog