Мониторинг серверов и VDS из облака

Что проверяем на сервере

Один сервер — это несколько мониторов разных типов: хост пингуется, порт SSH открыт, база отвечает на запрос, диск не заполнен. Каждый тип проверки настраивается отдельно, у каждого своя страница с деталями. Здесь — сводка: что ловит проверка, с каким минимальным интервалом работает и сколько стоит.

Ping-мониторинг сервера · TCP-порты · Почтовые и файловые серверы · MySQL и PostgreSQL · Ресурсы сервера · Heartbeat для cron и бэкапов · DNS-записи · SSL-сертификат

Сценарии: VDS, VPS и выделенный сервер

VDS с сайтом. Четыре монитора: HTTP-проверка самого сайта с ключевой фразой, ping хоста, TCP-порт 22 и скрипт ресурсов. Так по одному уведомлению видно, где проблема: сайт отдаёт 502 при живом хосте — упал веб-сервер или PHP; молчит и ping — проблема у хостера или в сети; диск на 95 % — сайт ещё жив, но скоро перестанет писать логи и сессии.

VPS под базу данных без HTTP. Снаружи проверять нечего, кроме порта, поэтому подключаем монитор MySQL или PostgreSQL: реальное подключение с логином и контрольный запрос, например SELECT COUNT(*) FROM orders WHERE created_at > NOW() - INTERVAL 1 HOUR с минимальным числом строк. Пароль хранится зашифрованным и не уходит партнёрским точкам — проверки с учётными данными выполняют только точки notifar.io.

Выделенный сервер с несколькими службами. Один хост — десяток мониторов: ping, порты 22 и 3389, SMTP на 25-м с проверкой приёма письма, IMAP на 993-м, база, ресурсы. Мониторы помечаются тегами (до 10 на монитор), поэтому список в кабинете фильтруется по имени сервера, а на время работ мониторы ставятся на паузу или закрываются окном обслуживания.

VPN, роутер, шлюз. Ping с порогами задержки и потерь плюс TCP-порт службы — OpenVPN по TCP, RDP, SSH на шлюзе. Уведомление приходит, когда офис ещё не заметил, что VPN отвалился.

Бэкапы и cron. Скрипт бэкапа в конце дёргает ссылку heartbeat; если сигнал не пришёл в срок плюс допустимое опоздание — уведомление. Так о несделанном бэкапе узнают до того, как он понадобится.

Внешний мониторинг: зачем, если есть Zabbix

Zabbix, Prometheus и Nagios стоят внутри вашей сети и видят её изнутри. Когда падает канал до хостера, отваливается BGP-анонс или провайдер режет трафик из части регионов, внутренняя система либо ничего не замечает, либо не может доставить уведомление — оно уходит через тот же канал, который лёг. Внешний мониторинг сервера закрывает ровно этот случай: проверки приходят из Москвы, Казани, Хельсинки, Мадрида и Милана, а уведомление уходит с нашей стороны.

Сбой подтверждают несколько точек — число задаётся в настройках монитора. Одна точка не достучалась, остальные видят сервер — инцидент не открывается, и ночной звонок из-за сбоя на трассе между Мадридом и вашим хостером не случится. Если сомневаетесь, нужна ли внешняя проверка при уже настроенном Zabbix, — сравнение по пунктам есть на страницах Нотифарио или Zabbix, Prometheus и Nagios. Короткий ответ: не вместо, а рядом.

Мониторинг хостинга: доказать простой отчётом

Хостер пишет «на нашей стороне всё работало», а клиенты жаловались полдня. Мониторинг хостинга с независимых точек даёт аргумент: каждый сбой записан как инцидент — время начала, какие точки подтвердили, код или текст ошибки, длительность, момент восстановления. Uptime за 7, 30 и 90 дней считается по каждому монитору, график времени ответа строится по точкам, и видно, что тормозит именно хостинг, а не одна сеть.

Для клиентов и руководства историю можно показать на публичной статус-странице с инцидентами за 90 дней или вставить в отчёт SVG-бейдж с uptime за 30 дней. Если хостер требует IP-адреса точек для белого списка в файрволе — их выдаёт поддержка по запросу; User-Agent робота — notifar.io monitor, подробности на странице о роботе.

Ресурсы сервера без агента: CPU, RAM, диск

Снаружи не видно, что диск заполнен на 98 %, а load average втрое выше числа ядер. Для этого на сервер кладётся короткий скрипт на bash или PHP, который по запросу отдаёт JSON с процентами CPU, RAM, диска (по каждой точке монтирования), load average и вашими собственными метриками. Доступ закрыт секретным заголовком, пороги задаются в мониторе — например, «диск не выше 90 %». Никакого демона: скрипт отдаёт ответ через ваш веб-сервер по обычному HTTPS. Подробно — на странице мониторинга ресурсов сервера, скрипт и формат ответа — в документации.

Уведомления в Telegram, MAX, SMS и звонком

Мониторинг серверов с уведомлениями в Telegram — основной сценарий: бот @notifar_bot пишет в личку или в групповой чат дежурных, в сообщении — какой монитор, с каких точек, причина и длительность. Тот же набор доступен в MAX и по email. Для ночи и выходных — SMS за 7 ₽ и звонок за 15 ₽, робот озвучивает текст; звонков не больше 3 в сутки на номер. Тихие часы задаются на каждый контакт по времени и дням недели, а контакты — на каждый монитор: например, ночью звонок получает только дежурный и только по критичным серверам.

Для автоматики есть webhook: POST с JSON и подписью HMAC в заголовке X-Notifar-Signature на события down и up. Типичный приём — скрипт на соседнем сервере получает событие down по порту 3306 и перезапускает MySQL, а событие up закрывает тикет.

Мониторинг Linux-сервера: что можно снаружи и изнутри

Снаружи Linux-сервер проверяется без единой установки: ping, порты, SMTP и IMAP, FTP, MySQL и PostgreSQL, HTTP, DNS и SSL — всё это удалённые запросы с наших точек. Изнутри — скрипт ресурсов (bash или PHP) и heartbeat-сигналы из cron: одна строка с curl в конце задания. Windows-сервер проверяется только снаружи — скрипт ресурсов для него не предусмотрен.

Если у вас есть свой Linux-VDS, его можно сделать точкой мониторинга: агент ставится одной командой, а за проверки, выполненные вашей точкой, начисляются бонусы или даётся скидка 50 % на мониторинг собственных серверов — условия в партнёрской программе. Партнёрские точки не получают учётных данных чужих мониторов. Цены на мониторинг всех типов проверок собраны на странице тарифов; API для массового добавления серверов описан в документации.

Вопросы