Grafana / Prometheus
Learning about an outage from an alert rather than from a customer's phone call.
Prometheus collects measurements — response times, error rates, memory, disk space, queues — and Grafana turns them into curves and alert thresholds. Together they answer a simple question an SMB always asks too late: is it working right now, and how long has it been degrading? The difference isn't cosmetic. Without measurement, a service goes down and a customer tells you; with it, the degradation shows while it's still fixable.
My take on monitoring: the dashboard isn't the point, the alert is.
Many installations I take over display twenty beautiful curves nobody looks at, and send no signal when the disk hits 95%. I do the opposite:
I start from the list of outages that actually cost you something — the site stops answering, orders stop going out, the disk is about to fill — and install only what's needed to detect them. Three accurate alerts beat thirty curves, and an alert that fires for nothing eventually gets muted, which amounts to monitoring nothing at all.
- →A service whose downtime has a direct cost: orders, bookings, production
- →Multi-machine infrastructure where the source of a slowdown isn't obvious by eye
- →Need for history: knowing whether today's slowness is new or has been there for weeks
- →An availability commitment to hold, or to demonstrate
- ×Static brochure site: an external uptime probe is enough and costs a few euros
- ×Nobody to receive the alerts: monitoring is an on-call arrangement, not a decorative screen
- ×The need is to search log contents rather than numeric measurements: that calls for a log stack
- →Elasticsearch / ELKFor investigating logs rather than numeric measurement: complementary, not competingView page
- →External uptime probeFor a brochure site, knowing it answers from outside is often enough
- →Hosted monitoring offeringsWhen monitoring must survive an outage of your infrastructure, for a volume-based subscription
- →CloudflareTraffic and availability figures seen from the edge, with nothing to installView page
- 01
Start from the outages that cost, not the metrics available: the alert list is written before the first curve
- 02
A few indicators per service — availability, latency, error rate, saturation — rather than a wall of graphs
- 03
Thresholds set from real observation after a few weeks, not from defaults
- 04
Alerts routed to a named recipient, with what they should look at first
- 05
Dashboards reduced to what gets consulted during an incident; the rest is scenery
+ Related services
Offerings associated with this techHow is this different from a log stack like ELK?
Metrics answer 'is it fine, and since when'; logs answer 'what exactly happened'. Prometheus stores numeric series, very compact, on which thresholds are set. A log stack stores text and serves the investigation. You almost always start with metrics, because they raise the alert; you open the logs afterwards, to understand.Self-host or use a hosted offering?
Self-hosted, the software is free and the running cost is a small machine and its disk, which grows with retention. Hosted, the vendor offers a free tier that suits a small scope, then billing by volume. The real criterion isn't price: it's whether your monitoring has to survive an outage of your own infrastructure.What does setting up monitoring cost?
What weighs is the number of services to instrument, whether the application exposes its own metrics, the number of environments and the level of on-call aimed for — being notified during office hours or at three in the morning are not the same arrangement. The amount is set in the quote, after a free initial scoping session that puts the scope in writing before any commitment.Does the application have to be modified to be monitored?
Not to start with. System, web server and database metrics are obtained without touching the code, and already cover most outages. Instrumenting the application itself — business processing times, queues, functional errors — comes later, when you want to see what's degrading before the server notices.How long should metrics be kept?
Long enough to compare an anomaly against normal: a few weeks is enough for day-to-day operations, a year if the goal is to demonstrate a trend or size capacity. Retention is the main disk cost, so it's an explicit trade-off rather than a default left running.
A project involving Grafana / Prometheus?
Describe your context: I'll suggest the right level of investment.
First callLet's talk aboutyour project.
Describe your need in a few lines. Reply within 24h to plan next steps, detailed quote within 48h.
- 24h response
- NDA on request