Мониторинг нужен, чтобы о проблеме с сервером вы узнавали раньше клиентов: в три часа ночи от уведомления в Telegram, а не в девять утра от возмущённого письма. Для одного сайта хватит бесплатной проверки раз в минуту, для парка серверов понадобятся метрики, графики и правила оповещений. Ниже — что именно мониторить, какие инструменты выбрать под свою задачу (от бесплатных проверок до Prometheus, Grafana и Zabbix), как их поставить и как не утонуть в ложных тревогах.
Что мониторить: четыре уровня
| Уровень | Что проверяем | Что ловит |
|---|---|---|
| Доступность снаружи | Открывается ли сайт, отвечает ли порт, не истекает ли SSL-сертификат и домен | Падение сервера, проблемы сети и DNS, истёкший сертификат |
| Ресурсы сервера | Процессор, память, диск, сеть | Заканчивается место, утечка памяти, перегрузка — до того, как сайт упадёт |
| Сервисы | Nginx, PHP-FPM, база, очереди, бэкапы | Упавшую службу при живом сервере, остановившийся бэкап |
| Приложение | Время ответа, доля ошибок 5xx, бизнес-метрики | Медленные страницы, сломанное оформление заказа |
Начинать стоит с первого уровня: он закрывает самое важное — «сайт лежит, а вы не знаете». Остальные добавляются по мере роста проекта.
Главное правило: мониторинг живёт не на том же сервере
Если проверка доступности запущена на сервере, который она проверяет, то при падении сервера упадёт и она — и никого не предупредит. Внешний мониторинг должен работать из другого места: со стороннего сервиса или с отдельного недорогого VPS, лучше в другой стране и у другого дата-центра. Тогда он заметит и падение сервера, и проблему с сетью площадки.
Уровень 1. Проверка доступности
Готовые сервисы
Самый быстрый старт — внешний сервис проверок: указываете адрес сайта, он раз в несколько минут его открывает и пишет вам при сбое. У многих сервисов есть бесплатные тарифы, но условия (число проверок, интервал, разрешено ли коммерческое использование) периодически меняются — смотрите актуальные на сайте сервиса.
У нашего провайдера тоже есть мониторинг доступности: бесплатный тариф — до 10 проверок раз в 15 минут, платный — до 50 проверок каждую минуту за $5 в месяц (на момент публикации). Его особенность: уведомление о сбое уходит в техподдержку провайдера, чтобы она могла вмешаться. Если хотите получать оповещения сами — в Telegram или на почту, — добавьте к нему собственную проверку из следующего раздела.
Свой мониторинг: Uptime Kuma
Uptime Kuma — бесплатная программа с открытым кодом и удобным веб-интерфейсом. Она проверяет сайты по HTTP(S), порты, ping, DNS и срок SSL-сертификата и шлёт уведомления в Telegram, на почту и в десятки других каналов. Версия 2.0 вышла в октябре 2025 года.
Ставится на отдельный VPS одной командой (нужен Docker — как его установить, в статье «Docker на VPS»):
docker run -d --name uptime-kuma --restart=unless-stopped \ -p 127.0.0.1:3001:3001 -v uptime-kuma:/app/data \ louislam/uptime-kuma:2
Порт привязан к 127.0.0.1, чтобы панель не торчала в интернет без шифрования. Откройте её через Nginx с HTTPS (сертификат — по инструкции «SSL на VPS»):
server {
listen 443 ssl;
server_name status.example.com;
# ssl_certificate ... — добавит certbot
location / {
proxy_pass http://127.0.0.1:3001;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
}
}
Заголовки Upgrade и Connection нужны: интерфейс работает через WebSocket и без них не обновляется. При первом входе Kuma попросит создать администратора.
Что добавить в первую очередь:
- HTTP(S) главной страницы с интервалом 60 секунд и проверкой ключевого слова — тогда «сайт отдаёт 200, но вместо страницы ошибка базы» тоже будет пойман.
- Тяжёлую страницу (каталог, поиск) с порогом времени ответа.
- Срок SSL-сертификата — с 2025 года Let's Encrypt не присылает писем об истечении, так что это единственный способ узнать заранее.
- Порт SSH или базы на других ваших серверах, если они не отдают веб-страниц.
Уведомления настраиваются в разделе Settings → Notifications: для Telegram нужен токен бота от @BotFather и ID чата.
Уровень 2. Метрики сервера
Проверка доступности скажет, что сайт упал. Метрики скажут, почему — и часто предупредят заранее: диск заполнен на 90%, память растёт третий день подряд.
Простые варианты: Netdata и Beszel
Если нужны графики «здесь и сейчас» без сложной настройки, есть лёгкие инструменты. Netdata ставится одним скриптом и сразу показывает сотни метрик с секундной детализацией. Beszel — минималистичный: центральная панель и маленький агент на каждом сервере, графики CPU, памяти, диска, сети и Docker-контейнеров, оповещения при превышении порогов. Для пары-тройки серверов этого часто достаточно.
Стандарт индустрии: Prometheus + Grafana
Связка, на которой работает мониторинг в большинстве компаний:
- node_exporter — маленький агент на каждом сервере, отдаёт метрики системы на порту 9100;
- Prometheus — раз в 15–30 секунд собирает метрики со всех агентов и хранит их;
- Alertmanager — рассылает оповещения по правилам (в том числе в Telegram);
- Grafana — графики и дашборды.
На каждом наблюдаемом сервере ставится агент. В Debian и Ubuntu он есть в репозитории:
apt install prometheus-node-exporter ufw allow from 203.0.113.5 to any port 9100 proto tcp
Вторая строка открывает порт метрик только для IP сервера мониторинга (подставьте свой). Метрики раскрывают многое о системе, держать их открытыми для всех не стоит.
На сервере мониторинга Prometheus читает список целей из prometheus.yml:
scrape_configs:
- job_name: node
scrape_interval: 30s
static_configs:
- targets: ['198.51.100.10:9100', '198.51.100.11:9100']
rule_files:
- alerts.yml
И правила оповещений в alerts.yml — три, с которых стоит начать:
groups:
- name: basic
rules:
- alert: InstanceDown
expr: up == 0
for: 2m
- alert: DiskAlmostFull
expr: node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"}
/ node_filesystem_size_bytes{fstype!~"tmpfs|overlay"} < 0.15
for: 10m
- alert: MemoryHigh
expr: 1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes > 0.9
for: 10m
Параметр for — сколько условие должно держаться, прежде чем придёт оповещение. Без него любой кратковременный всплеск будет будить вас по ночам.
В Grafana добавьте Prometheus как источник данных и импортируйте готовый дашборд для node_exporter (самый популярный — «Node Exporter Full», ID 1860): за пять минут получите графики по всем серверам без ручной настройки.
Весь стек удобно поднимать через Docker Compose. Сколько он ест: Prometheus и Grafana вместе — обычно 300–700 МБ памяти для нескольких серверов, плюс диск под историю метрик (по умолчанию Prometheus хранит 15 дней).
Для компаний и больших парков: Zabbix
Zabbix — зрелая система «всё в одном»: агенты, шаблоны для сотен типов оборудования и сервисов, оповещения, карты сети, права доступа для команды. Его выбирают, когда серверов десятки, есть сетевое оборудование и нужна единая система с разграничением доступа. Текущая версия с долгосрочной поддержкой — 7.0 LTS (поддержка до 2027–2029 года), 8.0 LTS запланирована на конец 2026 года.
Цена за универсальность — сложность и ресурсы: серверу Zabbix нужна своя база данных, и разворачивать его ради двух VPS избыточно.
Что выбрать
| Инструмент | Что делает | Ресурсы | Кому подходит |
|---|---|---|---|
| Внешний сервис проверок | Доступность | Ничего не ставить | Один-два сайта, быстрый старт |
| Uptime Kuma | Доступность, SSL, порты, уведомления | Минимальные, хватит младшего VPS | Несколько сайтов, нужен контроль и Telegram |
| Netdata, Beszel | Метрики и графики, простые алерты | Небольшие | 2–10 серверов, без сложной настройки |
| Prometheus + Grafana | Метрики, гибкие алерты, дашборды | 300–700 МБ RAM | Разработчики, DevOps, растущие проекты |
| Zabbix | Всё в одном, шаблоны, командная работа | Нужна своя БД, от 2 ГБ RAM | Компании, десятки серверов и оборудование |
Типичный путь: начать с Uptime Kuma, а когда серверов станет больше трёх-четырёх и захочется понимать причины, добавить Prometheus и Grafana на тот же сервер мониторинга.
Как не утонуть в оповещениях
Мониторинг, который присылает двадцать тревог в день, через неделю перестают читать — и пропускают ту единственную настоящую. Несколько правил:
- Оповещайте о том, что требует действия. «Процессор 95% пять секунд» — не повод будить человека. «Диск заполнится через сутки» — повод.
- Задавайте задержку. Сайт недоступен 2–3 проверки подряд, а не одну: единичный сбой сети не должен быть тревогой.
- Разделяйте срочность. Падение сайта — в Telegram со звуком. Растущая память — в отдельный канал, который вы просматриваете днём.
- Проверяйте сам мониторинг. Раз в месяц остановите тестовую службу и убедитесь, что оповещение пришло. Сломанный мониторинг хуже, чем никакого: он создаёт ложное чувство безопасности.
- Следите за бэкапами. Проверка «последней копии больше суток» ловит тихо остановившийся бэкап — одну из самых дорогих поломок. Как устроить хранение копий — в статье «Сервер для бэкапа».
Сервер под мониторинг
Для Uptime Kuma или Beszel хватит самого младшего тарифа. Для Prometheus и Grafana с историей метрик лучше взять с запасом памяти. Главное — разместить сервер мониторинга в другой стране, чем основной: если основной сайт в Финляндии, мониторинг в Нидерландах заметит и падение сервера, и проблемы с сетью финской площадки.
Lite в Нидерландах под Uptime Kuma — $6/мес Start в Финляндии под Prometheus + Grafana — $10/мес
Цены указаны на момент публикации, оплата у провайдера. Lite — 1 vCPU и 1 ГБ памяти, Start — 2 vCPU и 2 ГБ, оба на NVMe. Тот же сервер можно использовать и как резервную площадку для бэкапов.
Минимальный набор для одного сайта
- Внешняя проверка главной страницы раз в минуту с уведомлением в Telegram.
- Проверка срока SSL-сертификата и домена.
- Оповещение о заполнении диска выше 85%.
- Проверка, что бэкап свежий.
- Раз в месяц — тестовая тревога, чтобы убедиться, что всё работает.
Когда оповещение всё-таки пришло, действуйте по порядку из статьи «Что делать, если сайт упал». А если тревоги связаны с ростом нагрузки — загляните в «Пики нагрузки» и «Как ускорить сайт на VPS».
Коротко
- Мониторинг доступности должен работать с другого сервера, лучше в другой стране.
- Для одного-двух сайтов достаточно внешних проверок или Uptime Kuma с уведомлениями в Telegram.
- Чтобы понимать причины сбоев, добавьте метрики: Netdata или Beszel для простоты, Prometheus и Grafana как стандарт.
- Zabbix оправдан для компаний и десятков серверов.
- Оповещайте только о том, что требует действия, с задержкой, и регулярно проверяйте сам мониторинг.