Мониторинг сервера: аптайм, нагрузка, алерты
Без мониторинга о падении сервера вы узнаёте от посетителей, а о заканчивающемся диске — когда база перестаёт записывать. Хватает нескольких проверок снаружи и десятка метрик изнутри, чтобы видеть проблему раньше пользователей. Разберём, что измерять, где ставить проверки и чем это сделать бесплатно.
Мониторинг отвечает на два вопроса. Первый — работает ли сервис для пользователя прямо сейчас: открывается ли сайт, отвечает ли API, пускает ли сервер по SSH. Второй — почему он работает плохо или скоро перестанет: кончается место, растёт нагрузка, соседи по хосту забирают процессор. На первый отвечают внешние проверки, на второй — метрики с самого сервера. Нужны обе части: одна без другой либо не замечает падения, либо не объясняет его.
Внешние и внутренние проверки
Внешняя проверка идёт к серверу из интернета так же, как пользователь: запрашивает страницу, подключается к порту, проверяет ответ DNS. Она видит то, что внутри сервера не видно: сломанный маршрут у хостера, упавший канал, ошибку DNS, истёкший сертификат. Важное правило — внешний мониторинг не должен жить на том же сервере и в идеале у того же хостера: если упадёт сеть дата-центра, вместе с сайтом упадёт и тот, кто должен был об этом сообщить. Хорошая проверка смотрит не только на код ответа 200, но и на слово или фразу на странице: так ловится и ситуация, когда веб-сервер жив, а вместо сайта отдаётся страница ошибки.
Внутренний мониторинг — агент на сервере, который каждые 10–60 секунд снимает метрики системы и отправляет их на сервер мониторинга. Он показывает причину: на графике видно, что диск заполнился за ночь или что память уходит в swap с каждым часом.
Третий вид проверок легко забыть — проверки «от сервера» (push, heartbeat). Задача по расписанию — резервное копирование, выгрузка, отправка отчёта — после успешного завершения сама отправляет сигнал в мониторинг. Если сигнала не было в положенное время, приходит оповещение. Так узнают о резервных копиях, которые тихо перестали создаваться несколько недель назад. Как выстроить сами копии — в статье Резервные копии VPS.
Что измерять
- Доступность и время ответа — снаружи, по HTTP(S), порту или ping, раз в 1–5 минут из нескольких точек.
- Нагрузка на процессор — загрузка в процентах и load average. В Linux load average считает не только процессы, которые ждут процессор, но и те, что ждут диск или сеть (состояние D). Поэтому высокий load при низкой загрузке процессора обычно значит медленный диск, а не нехватку ядер. Сравнивайте load с числом ядер: 4 на четырёхъядерном сервере — полная загрузка, на восьмиядерном — половина.
- Steal time — доля времени, когда виртуальный процессор готов работать, но гипервизор отдал физическое ядро другой машине. Это метрика именно VPS: она видна в
topкакst. Постоянный steal выше 5–10% — признак перегруженного хоста, и с ним стоит идти в поддержку или менять тариф. - Память — доступная память (available, а не free: Linux занимает свободную память под кэш и отдаёт по требованию) и использование swap. Рост swap и сообщения OOM killer в журнале — сигнал, что памяти не хватает. Как подобрать объём — в статье Сколько памяти и ядер нужно сайту.
- Диск — свободное место и свободные inode по каждому разделу, задержка и очередь ввода-вывода. Место заканчивается чаще всего из-за журналов, резервных копий и образов Docker.
- Сеть — входящий и исходящий трафик, ошибки и потери пакетов. Если тариф с квотой, полезно видеть, сколько уже израсходовано за месяц.
- Службы — работают ли веб-сервер, база, очереди, контейнеры; число ошибок 5xx в журнале веб-сервера.
- Сроки — окончание сертификата TLS и регистрации домена: оповещение за 14–30 дней.
Оповещения без ложных тревог
Мониторинг, который будит по ночам из-за пустяков, через месяц отключают. Несколько правил, которые помогают этого избежать:
- Оповещение — только на то, что требует действия. Графики можно собирать по всему, но писать стоит про недоступность, кончающийся диск, ошибки служб, пропущенную резервную копию.
- Задержка срабатывания. Внешняя проверка должна провалиться 2–3 раза подряд или из нескольких точек одновременно; нагрузка — держаться выше порога 5–15 минут, а не один замер.
- Два уровня. Предупреждение (диск заполнен на 80%) — в рабочий чат, авария (95% или сайт недоступен) — туда, где вы увидите сразу: push-уведомление, мессенджер, SMS.
- Прогноз вместо порога. Для диска полезнее правило «место кончится через 24 часа при текущем росте», чем фиксированный процент: оно срабатывает и на быстром росте журнала, и не будит при медленном.
- Сообщение о восстановлении. Без него непонятно, проблема ещё есть или уже ушла.
Бесплатные инструменты
- Uptime Kuma — самый простой старт: внешние проверки HTTP(S), портов, ping и DNS, проверка слова на странице, push-проверки для заданий по расписанию, страница статуса и десятки каналов оповещений. Ставится в Docker одной командой, лицензия MIT. Держите его на отдельном маленьком сервере, а не на том, который он проверяет.
- Prometheus + node_exporter + Grafana — стандартная связка для метрик: node_exporter отдаёт метрики системы, Prometheus их собирает и хранит, Alertmanager рассылает оповещения по правилам, Grafana рисует графики. Гибко, но настройка займёт вечер-другой.
- Zabbix — классическая система мониторинга с агентами, шаблонами для типовых служб и оповещениями из коробки. Начиная с версии 7.0 распространяется под лицензией AGPLv3. Удобна, когда серверов много и нужен единый интерфейс.
- Netdata — агент, который сразу после установки показывает сотни метрик с секундной детализацией и уже настроенными оповещениями. Хорош для разбора, что происходит на сервере прямо сейчас.
Для одного–трёх серверов практичная схема такая: Uptime Kuma на отдельном VPS для внешних и push-проверок плюс Netdata или node_exporter на каждом сервере для метрик. Серверу мониторинга хватает 1–2 ГБ памяти, но ставить его лучше у другого хостера или хотя бы в другой локации. Тарифы под такую задачу — в подборке VPS для мониторинга; если всё поднимаете в контейнерах, пригодится статья Docker на VPS.
Мониторинг и SLA хостера
Свои данные о доступности — единственный способ проверить обещание хостера. По данным каталога accsly на 3 ноября 2026 года, гарантию доступности указывают 1617 хостеров; у 53% из них это 99,9%, у 17% — 99,99%. В минутах за 30-дневный месяц это выглядит так:
| Аптайм | Допустимый простой за месяц |
|---|---|
| 99% | 7 ч 12 мин |
| 99,5% | 3 ч 36 мин |
| 99,9% | 43 мин |
| 99,95% | 22 мин |
| 99,99% | 4 мин 19 с |
Компенсацию по SLA обычно дают только по запросу клиента и только за простой, который вы можете показать, — журнал внешней проверки с точным временем подойдёт. Учтите и то, что хостер считает доступностью: часто это работа сети и хоста, а не вашего сайта, и плановые работы в простой не входят. Что ещё стоит прочитать в условиях до покупки — в статье Как читать тарифы хостера: скрытые ограничения.