What monitoring setup includes
You can start small, with metrics and alerts for one server, and add the rest as you grow.
Server metrics
The base layer, without which nothing else makes sense.
- ✓CPU, memory, disks, network
- ✓disk space with a fill-up forecast
- ✓service restarts and kernel errors
- ✓node_exporter on every server
Application metrics
They show what the user experiences, not just the server.
- ✓API response time and error rate
- ✓queues, background jobs, cache
- ✓PostgreSQL, MySQL, Redis
- ✓business metrics: orders, sign-ups, payments
Log collection
All logs in one place with search, instead of SSH into every server.
- ✓collected in Loki or ELK
- ✓search and filters in Grafana
- ✓retention sized to the budget
- ✓alerts on errors in logs
External checks
A server can be running while the site is unreachable for customers.
- ✓site and API availability
- ✓SSL certificate and domain expiry
- ✓key user flows: login, payment
- ✓a status page for customers
Alerts
A good alert says what broke and what to do. A bad one teaches people to ignore alerts.
- ✓Telegram, Slack, email
- ✓thresholds based on real load, no false alarms
- ✓grouping: one outage, one message
- ✓a link to the graph and a runbook in the alert
Dashboards
A screen that tells you in a minute whether everything is fine.
- ✓all services on one screen
- ✓separate panels for developers and management
- ✓months of history for capacity planning
- ✓dashboards stored in Git
Kubernetes monitoring
A cluster has its own metrics: pods, nodes, resources.
- ✓kube-prometheus-stack or VictoriaMetrics Operator
- ✓pod restarts and out-of-memory kills
- ✓requests and limits usage
- ✓node and storage health
Retention and cost
Monitoring shouldn't cost as much as another production environment.
- ✓VictoriaMetrics for long-term metric storage
- ✓collecting the metrics you need, not everything
- ✓retention for metrics and logs
- ✓a separate server, so an outage doesn't take monitoring down too
Monitoring setup pricing
Before starting I give an estimate in hours, and work begins once you agree.
| Format | Price | What's included |
|---|---|---|
| Monitoring audit | from $230 | what is collected, which outages would go unnoticed, alert noise; a report with a plan |
| Setup | $35/hour | metrics, logs, external checks, alerts and dashboards |
| Support | $250/month | alert response, threshold tuning, monitoring stack updates |
Example estimates
| Task | Estimate |
|---|---|
| Metrics and Telegram alerts for 1-3 servers | 4-6 hours |
| Log collection in Loki with search in Grafana | 3-6 hours |
| Site availability and certificate expiry checks | 1-2 hours |
| Cleaning up noisy alerts: drop false ones, add the missing ones | 2-4 hours |
How the setup goes
- 1
What matters to the business
We work out which outages cost money: an unreachable site, stopped payments, a lagging queue. That's where we start.
- 2
What already exists
I check which metrics and logs are already collected and who receives alerts. Often part of the work is already done.
- 3
Basic monitoring
Server metrics, external checks and the first alerts. Usually this is the first day of work.
- 4
Applications and logs
I add application metrics, log collection and dashboards for the team.
- 5
Threshold tuning
For a couple of weeks I watch the alerts and remove noise until every alert is a reason to act.
When you need monitoring
Customers report the outage
The site was down for an hour, and you found out from the support chat. An external check and an alert cut that to minutes.
So many alerts nobody reads them
Nobody opens a channel with a hundred notifications a day, and the important alert gets lost. I rework thresholds and grouping.
Finding the cause takes hours
Logs on different servers, no graphs, every incident investigated from scratch. With everything in one place, the cause is visible right away.
The disk filled up suddenly
Not really: it grew for weeks. A fill-up forecast warns you days ahead.
Prometheus, Zabbix or cloud monitoring
Three approaches people usually choose between:
| Prometheus and Grafana | Zabbix | Cloud monitoring | |
|---|---|---|---|
| Strength | services, containers, Kubernetes | hardware, network, office infrastructure | nothing to install |
| Configuration | in code, in Git | mostly through the web UI | in the provider console |
| Logs | Loki in the same Grafana | limited | a separate paid service |
| Cost | free, needs a server | free, needs a server | pay per volume of metrics and logs |
For web services and Kubernetes I use Prometheus or VictoriaMetrics with Grafana. If you already run Zabbix and it works for you, there's no need to replace it: Grafana can display its data too.
Which alerts you need first
A minimal set that catches most real outages:
- The site or API doesn't respond from outside for more than 1-2 minutes.
- The 5xx error rate is above normal.
- A disk will fill up within days at the current rate: in Prometheus that's
predict_linear. - A service keeps restarting, or the kernel killed a process for lack of memory.
- An SSL certificate expires in 14 days.
- A backup hasn't run for more than a day.
Everything else is added once it's clear what actually breaks in your project. Starting with a hundred rules from a ready-made pack is a sure path to noise.
Technologies
- Metrics
- PrometheusVictoriaMetricsAlertmanagernode_exporter
- Logs
- LokiELK
- Visualization
- Grafana
- External checks
- Blackbox exporter
- Kubernetes
- kube-prometheus-stackVictoriaMetrics Operator
- Notifications
- TelegramSlackemail
Case studies
IPTV service: subscribers reported the outages
There was no monitoring: a failed stream, database or API was discovered from subscriber complaints.
Set up Prometheus and Grafana for streams, the database and the API with Telegram alerts, and added checks for the daily backups.
ML platform: alerts in the team chat
After moving to the cloud, the team needed to see the state of all services and learn about failures where they already talk.
Collected metrics in VictoriaMetrics, set up dashboards and sent alerts to the team's work chat.
Why work with me
Open stack
Prometheus, Grafana and Loki are free. You pay only for the server they run on.
Everything in code
Alert rules and dashboards live in Git. They can be reviewed, rolled back and moved.
I get these alerts too
On support, alerts come to me as well, so noisy rules bother me as much as they bother you.
A developer's view
I wrote code for many years and know which metrics help find a bug in the application and which just take up space.
Frequently asked questions
How much does monitoring setup cost? +
Metrics and Telegram alerts for 1-3 servers usually take 4-6 hours at $35/hour. An audit of existing monitoring starts at $230, and support with alert response is $250 a month.
Zabbix or Prometheus: which to choose? +
For servers running web services and for Kubernetes, Prometheus or VictoriaMetrics with Grafana is more convenient: configuration in code and ready-made exporters for almost everything. Zabbix is stronger at monitoring network hardware and office infrastructure.
Where will the monitoring run? +
On a separate small server or in your cloud, but not on the same server as the project: otherwise monitoring disappears when that server goes down.
How big a server does monitoring need? +
For a few servers a VPS with 2 cores and 4 GB of RAM is enough. Logs take the most space, and their retention is chosen to fit the budget.
Who will respond to alerts? +
You can keep alerts with your team, and I'll write a runbook for each. Or take support, and I'll respond to them.
Can alerts go to Telegram? +
Yes, it's the most common option. Also Slack, email and any service that accepts webhooks.
Send a request
Tell me how many servers you have, what runs on them and how you learn about outages today. I'll suggest the minimal set to start with.