Мониторинг для одного сервера: Uptime Kuma, Netdata и здравый смысл

Часть 4 из 14 · Серия «Сервер в бою»

Первые три статьи серии объединяет одна неловкая деталь: во всех сценариях мы узнавали о проблеме постфактум. Сервер упал — и нас разбудил клиент. Читали логи — уже по факту аварии. Даже fail2ban из прошлой части молча делает своё дело, не докладывая, что происходит. Всё это — реактивная работа: пожар, выезд, тушение.

Сегодня перевернём подход. Мониторинг — это когда о падении сайта вам сообщает не заказчик в мессенджере, а бот в том же мессенджере, но на двадцать минут раньше и без упрёка в голосе. А в идеале — когда сообщение приходит до падения: «диск заполнен на 90%», «сертификат истекает через неделю». У вас появляется роскошь чинить в спокойном режиме то, что иначе чинилось бы в три ночи.

Но у мониторинга одного маленького VPS есть своя ловушка, противоположная: индустрия предлагает вам Prometheus, Grafana, Zabbix, алерт-менеджеры и дашборды на сорок графиков. Для парка из ста серверов — прекрасно. Для одного VPS — это второй сервер обслуживания ради первого. Поэтому подзаголовок статьи не случаен: инструментов будет два, маленьких, а третьим компонентом пойдёт здравый смысл — он тут главный.

Зачем следить за сервером, который «и так работает»

Возражение честное, отвечу на него честно. Три причины.

Первая: «работает» — это точка, а не линия. Сайт открылся сейчас — вот и всё, что вы знаете. Вы не знаете, что диск заполняется на гигабайт в неделю и через месяц наступит статья номер один. Не знаете, что после последнего обновления память подтекает и OOM killer уже дважды тихо перезапускал PHP-FPM ночью (сайт полежал по три минуты — никто не заметил, но это репетиция большого падения). Мониторинг превращает точку в линию — а по линии видно, куда всё идёт.

Вторая: время обнаружения — половина даунтайма. Типичная авария маленького сайта лежит часами не потому, что её сложно чинить, а потому, что о ней долго никто не знает. Само падение чинится за десять минут (мы это уже умеем) — но сначала должен кто-то заметить. Внешний чекер сжимает «кто-то заметил» с часов до минуты.

Третья: история для диагностики. Помните вопрос из первой статьи — «что изменилось перед падением?» Логи отвечают на «что случилось», а графики — на «как мы к этому шли». Пик памяти в 02:40, рост числа соединений с 02:10, и вот уже картина аварии складывается не из догадок.

Два уровня: снаружи и изнутри

Ключевая мысль, из которой вытекает весь выбор инструментов: мониторинга нужно два, и они не заменяют друг друга.

Взгляд снаружи отвечает на единственный вопрос: «жив ли сайт для посетителя?» Проверка должна идти с другой машины — потому что сервер, который умер, не может сообщить о своей смерти. Это будет Uptime Kuma.

Взгляд изнутри отвечает на вопрос «как себя чувствует сервер?»: память, диск, CPU, процессы. Это метрики с самой машины. Это будет Netdata.

Классическая грабля новичка — поставить всё на один сервер и успокоиться. Внутренний мониторинг на том же VPS честно нарисует вам красивый график ровно до момента, когда сервер ляжет, — и ляжет вместе с ним, унеся и алерты. Правило простое: проверка доступности — всегда снаружи. Дешёвых способов «снаружи» три: второй копеечный VPS у другого провайдера, бесплатный внешний сервис-чекер, или домашний Raspberry Pi. Подойдёт любой.

Uptime Kuma: вышка наблюдения за 10 минут

Uptime Kuma — опенсорсный self-hosted чекер с приятным веб-интерфейсом: пингует ваши сайты с заданным интервалом и поднимает тревогу в Telegram, почту или ещё десятки каналов. Ставится в одну команду через Docker (на той самой другой машине):

docker run -d --restart=always -p 3001:3001 \
  -v uptime-kuma:/app/data --name uptime-kuma \
  louislam/uptime-kuma:2

Открываете http://адрес:3001, создаёте аккаунт — и добавляете мониторы. Вот здесь начинается здравый смысл, потому что что именно проверять — важнее, чем чем.

Не просто «пинг», а осмысленный HTTP-чек. Пинг скажет, что машина жива, — но nginx может отдавать 502 на живой машине, мы это проходили. Поэтому основной монитор — HTTP(s) на реальную страницу сайта, с проверкой кода ответа. А ещё лучше — режим «HTTP с ключевым словом»: проверять, что в ответе присутствует строка, которая есть только на правильно отрендеренной странице (название компании в футере, например). Такой чек ловит даже ситуацию «сервер отдаёт 200, но вместо сайта — белый экран или заглушка».

Сертификат — в тот же монитор. У HTTPS-мониторов Kuma есть галочка «Certificate Expiry Notification» — предупредит за N дней до истечения SSL. Одна галочка закрывает целый класс «внезапных» аварий, особенно если авто-продление certbot однажды молча сломается (а оно умеет — поговорим в двенадцатой статье про cron).

Уведомления — туда, где вы живёте. Для Telegram: создаёте бота через @BotFather, вставляете токен и chat ID в настройки Kuma, жмёте «Test» — в мессенджер падает проверочное сообщение. Всё, канал тревоги готов. Совет из практики: настройте Retries = 1–2, чтобы одиночный сетевой чих между чекером и сервером не будил вас ложной тревогой, — алерт пойдёт только после повторной неудачной проверки.

Интервал — без фанатизма. Раз в 60 секунд — более чем достаточно для сайта-визитки, блога и даже небольшого магазина. Проверка раз в 10 секунд не сделает вас счастливее, а вот в логи (и в статистику fail2ban, если неудачно совпадут звёзды) шума добавит — не забудьте, кстати, внести IP чекера в ignoreip, мы же не хотим забанить собственный мониторинг.

Бонусом Kuma умеет публичные статус-страницы — отдельный URL с зелёными/красными плашками ваших сервисов. Если у вас клиенты, это солидно выглядит и экономит переписку: вместо «а у вас всё работает?» человек сам открывает статус-страницу.

Netdata: приборная панель изнутри

Теперь взгляд изнутри. Netdata ставится на сам боевой VPS одной командой (официальный скрипт с сайта netdata.cloud) и без всякой настройки начинает собирать буквально всё: CPU, память, диск, сеть, процессы, MySQL, nginx — с посекундной детализацией и автоматическими алертами из коробки. Интерфейс — на порту 19999.

И сразу про безопасность, потому что это вторая классическая грабля: не выставляйте порт 19999 в интернет. Приборная панель сервера — подробнейшая разведсводка для атакующего. Правильные варианты: закрыть порт файрволом и ходить через SSH-туннель (ssh -L 19999:localhost:19999 user@сервер — и открываете localhost:19999 у себя), либо спрятать за nginx с basic auth, либо — самое элегантное — дождаться седьмой статьи про WireGuard и пускать к панели только через свой VPN.

Чем Netdata хорош именно для одинокого VPS: нулевая настройка при максимальной детализации. Вы не строите дашборды — вы открываете панель, когда что-то не так, и смотрите. Помните минуту 4 из практикума про 502, где мы подтверждали гипотезу про память? С Netdata это выглядит так: открыли панель, отмотали график RAM на 03:00 — и увидели, как память упирается в потолок, а следом на графике процессов исчезает php-fpm. Диагноз — в двух кликах, причём задним числом, чего free -h не умеет в принципе.

А из коробки он ещё и шлёт алерты: диск заполняется, память на пределе, load зашкаливает. Пороги разумные по умолчанию, но канал доставки надо подключить (тот же Telegram — в конфиге health_alarm_notify.conf).

Здравый смысл: что мониторить, а что — нет

Инструменты поставили за полчаса. Дальше начинается дисциплина, и вот тут тонут чаще, чем в настройке.

Главный враг мониторинга — не отсутствие данных, а усталость от алертов. Если телефон дзинькает по десять раз на дню («CPU 81%!», «load 1.4!»), через неделю вы перестаёте читать уведомления, а через месяц — пропускаете настоящее. Каждый алерт должен проходить один тест: «готов ли я встать ночью ради этого?» Если нет — это не алерт, это график, пусть лежит в панели до планового осмотра.

Ночного пробуждения на одиноком VPS заслуживают ровно четыре вещи:

Всё. Пики CPU — не алерт: сервер и должен иногда работать на полную, это нормально. Load, число процессов, трафик — графики для разбора полётов, не поводы для будильника. Первую неделю после установки Netdata будет слать и лишнее — не терпите, а глушите конкретные надоевшие алерты или поднимайте пороги. Настройка алертов — это не «один раз и навсегда», это прополка: пару минут в неделю первое время.

И последний штрих здравого смысла — мониторинг мониторинга. Кто заметит, что упал сам чекер? У Uptime Kuma для этого есть «Push»-мониторы наоборот: ваш боевой сервер раз в минуту дёргает специальный URL (одной строчкой в cron), и если сигналы перестали приходить — Kuma бьёт тревогу. Получается красивая взаимная страховка: чекер следит за сервером, сервер — за чекером. Для полноты можно добавить и бесплатный внешний сервис, который следит за самим Kuma, но на одном VPS это уже перфекционизм — взаимной страховки достаточно.

Что в итоге

Полчаса установки, вечер прополки алертов — и качество жизни меняется ощутимо. О падениях вы теперь узнаёте за минуту и первым. Два самых частых «внезапных» сценария — переполненный диск и истёкший сертификат — перестали быть внезапными: они предупреждают о себе за дни. А когда что-то всё-таки падает, у вас есть машина времени: графики Netdata показывают, что происходило с сервером в момент аварии, и диагностика из первой статьи ускоряется в разы.

Кстати, про заполняющийся диск. Теперь, когда Netdata заботливо предупредил, что осталось 10%, — возникает вопрос: а куда, собственно, всё делось? Вы ведь ничего не загружали. В следующей статье проведём ревизию VPS и найдём, где прячутся гигабайты: раздувшиеся логи, старые ядра, кэши Docker, забытые дампы базы — и настроим logrotate так, чтобы диск больше никогда не кончался «внезапно».