Мониторинг нагрузки и доступности сайта: как вовремя узнать о проблеме

Сайт может выглядеть совершенно нормально, но при этом уже перестать выполнять важные задачи: не отправлять заявки, не обновлять цены, не принимать оплату или не передавать данные в CRM.

Самое неприятное в таких ситуациях — проблема часто обнаруживается не системой, а человеком. Например, клиент пытается оформить заказ и пишет менеджеру: «У вас сайт не работает».

Для бизнеса это означает не просто технический сбой. Это потерянная заявка, сорванный заказ, недовольный клиент и иногда — несколько дней работы в режиме «срочно всё починить».

Поэтому мы в 2ДИТ считаем, что мониторинг сайта должен отвечать не только на вопрос «открывается ли сайт?», но и на гораздо более важный: «всё ли в порядке с тем, что сайт должен делать?»

Рассказываем, что именно мы проверяем, как отличаем серьёзную проблему от случайного сбоя и какую информацию видит клиент.

Сайт открывается — но всё равно может не работать полноценно

Самый простой способ проверить сайт — раз в несколько минут открыть его главную страницу и посмотреть, отвечает ли сервер.

Это полезная проверка. Если сайт вообще перестал открываться, важно узнать об этом как можно быстрее. Но у неё есть очевидное ограничение: она проверяет только сам факт доступности страницы.

Представим интернет-магазин: главная открывается, каталог загружается, фотографии на месте. На первый взгляд всё хорошо. Но при этом обмен с 1С остановился три дня назад, поэтому цены и остатки давно не обновлялись.

Или другая ситуация: форма заявки на сайте перестала отправлять письма. Посетитель её заполняет, нажимает кнопку — получает сообщение об успешной отправке и уходит. А заявка до менеджера так и не доходит.

Есть и другие сценарии:

• закончилась свободная память на сервере;

• перестала работать интеграция с CRM;

• не проходит онлайн-оплата;

• истёк ключ внешнего сервиса;

• остановилась отправка писем;

• на сайте перестала работать капча и формы начали получать поток спама.

При этом главная страница во всех этих случаях может продолжать прекрасно открываться.

Поэтому хороший мониторинг должен проверять не только доступность сайта, но и его ключевые функции и связи с другими системами.

Проверяем не только сайт, но и его важные функции

Поэтому на сайтах, которые мы ведём, мы заводим служебный адрес — «health-ручку». Это закрытая токеном страница, которую сайт отдаёт не человеку, а нашему мониторингу. По ней сайт сам отчитывается о себе изнутри: жива ли база, сколько осталось места, работает ли обмен с CRM, отвечает ли платёжный шлюз, не застряла ли очередь писем.

Выглядит ответ примерно так — и раз в десять минут мы читаем его целиком, а не только код ответа:

GET /health?token=•••HTTP 200 · 340 мс

"status": "degraded",
"checks": [
  { "проверка": "База данных",       "status": "ok",   "состояние": "отклик 12 мс" },
  { "проверка": "Место на диске",    "status": "ok",   "состояние": "занято 61%" },
  { "проверка": "Почта заявок",      "status": "ok",   "состояние": "очередь пуста" },
  { "проверка": "Обмен с 1С",        "status": "fail", "состояние": "нет выгрузки 3 дня" },
  { "проверка": "Капча на формах",   "status": "ok",   "состояние": "ключ активен" }
]

Набор проверок у каждого проекта свой: у интернет-магазина это склад и оплата, у медиа — импорт новостей, у сервиса с личным кабинетом — очереди и внешние API. Ручку пишем под ваш сайт: она знает, что для него значит «работает», а мы просто читаем её ответ.

Если у сайта такой ручки нет — ничего страшного, мониторинг всё равно работает в простом режиме: проверяем, что сайт открывается и отдаёт нормальный ответ. Ручку можно добавить потом, отдельной небольшой задачей.

Мониторинг не должен превращаться в спам

Мониторинг, который постоянно присылает ложные тревоги, со временем перестают воспринимать всерьёз.

Представьте: несколько раз в неделю приходит сообщение «сайт недоступен». Вы открываете его вручную — всё работает. Через какое-то время такие уведомления начинают просто пролистывать.

Сигнал тревоги имеет ценность ровно до тех пор, пока на него реагируют. Поэтому мы потратили больше времени на то, чтобы мониторинг молчал в правильные моменты, чем на сами проверки.

Что мы сделали, чтобы ложных тревог не было:

• Три попытки внутри одной проверки. Одна неудача — это ещё не событие: интернет иногда просто моргает.

• Подтверждение на нескольких прогонах. Тревога уходит людям, только если картина повторилась.

• Разные пороги для разных бед. Сайт отвечает ошибкой — это почти всегда правда, ждём недолго. Обрыв соединения или таймаут — типичная «моргалка», ждём дольше.

• Пишем и о выздоровлении. Сообщение «упал» без парного «поднялся» оставляет человека в тревоге, поэтому второе приходит обязательно.

Не каждая проблема требует срочного вмешательства

Между зелёным и красным есть жёлтый, и это не придирка. Несколько примеров, которые мы специально научились отличать:

• Сертификат отдан не полностью. Браузеры такое достраивают сами — люди ничего не замечают, сайт работает. Будить кого-то ночью незачем, но и молчать нельзя: часть мобильных приложений и платёжных сервисов на этом спотыкается. Это жёлтая отметка и задача в план, а не авария.

• Истёкший или чужой сертификат — уже красное: браузер показывает предупреждение на весь экран, и посетители уходят.

• Сайт закрыт паролем. Тестовые стенды мы намеренно прячем за паролем. Сервер отвечает «сюда нельзя» — значит, он жив. Считать это падением было бы глупо, и мы не считаем.

• Домен на кириллице. Такие адреса нужно приводить к техническому виду перед запросом, иначе сервер ответит ошибкой на пустом месте — и мониторинг будет «ронять» совершенно здоровый сайт.

Такие мелочи не видны в рекламе сервисов мониторинга, но именно из них состоит разница между системой, которой доверяют, и очередным источником шума.

Есть проблемы, которые лучше увидеть заранее

Вторая половина работы — не про «упало», а про «скоро упадёт». Аварии редко случаются внезапно: у них почти всегда есть предыстория, которую видно за недели.

• Место на диске. Раз в сутки собираем, сколько занимает каждый сайт. Заполненный диск — одна из самых обидных аварий: сайт перестаёт принимать файлы и писать в базу, при этом «вроде работает». Растущий график виден заранее, и вопрос решается уборкой логов или расширением тарифа — спокойно, в рабочее время.

• Сроки домена и хостинга. Даты окончания мы забираем из официальных реестров, а не полагаемся на письма регистратора, которые уходят в спам или на почту уволившегося сотрудника. Раз в день собираем одну общую сводку: что заканчивается в ближайшее время.

• Версии CMS и шаблона. Отдельно следим, на каких версиях живут сайты: отставание на пару лет — это не «неаккуратно», это открытая дверь.

Незаметная деталь: реестры доменов не любят частых обращений и начинают отвечать отказом. Поэтому опрос идёт по ночам, с паузами между запросами. Мониторинг не должен создавать проблемы там, где их не было.

Что происходит, когда мониторинг находит проблему

Мы проверяем сайты регулярно — базовые проверки выполняются каждые 10 минут.

Если сайт действительно перестал отвечать или обнаружена проблема в одной из критичных проверок, уведомление отправляется ответственным сотрудникам.

При этом разные ситуации обрабатываются по-разному.

Такой подход позволяет разделять аварию, требующую реакции, и замечание, которое можно спокойно исправить в рабочем порядке.

Что из этого видите вы

Нам важно, чтобы история работы сайта была понятна не только техническому специалисту. Поэтому для каждого проекта собирается история проверок и формируется страница доступности.

На ней можно посмотреть, насколько стабильно работал сайт за определённый период, и при необходимости разобраться, что происходило в конкретный день.

День считается «плохим», если в нём была хотя бы одна неудачная проверка — так же, как это показывают публичные страницы состояния крупных сервисов. Рядом с календарём хранится история: какая именно проверка падала в этот день. Через месяц не придётся вспоминать, что случилось семнадцатого.

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

Какой профит в итоге получает бизнес

Для бизнеса мониторинг — это прежде всего не про серверы, базы данных и технические показатели.

Он про несколько гораздо более практичных вещей.

Как подключается мониторинг

Базовый мониторинг доступности можно подключить практически к любому сайту. От вас нужен только адрес проекта.

Если нужно контролировать не только доступность, но и ключевые функции, мы дополнительно определяем, что именно должно считаться нормальной работой сайта. Для одного проекта это будет обмен с 1С и онлайн-оплата, для другого — CRM, личный кабинет и несколько внешних сервисов.

После этого мониторинг работает автоматически: регулярно проверяет сайт, фиксирует результаты, уведомляет о проблемах и сохраняет историю. При этом сам сайт не нужно переделывать под какую-то конкретную технологию. Мы подстраиваем мониторинг под существующий проект.

В результате у вас появляется не просто проверка «сайт открывается или нет», а постоянный контроль его работоспособности.

И чем важнее сайт для бизнеса — продажи, заявки, личный кабинет, онлайн-оплата, интеграции — тем больше смысла в том, чтобы узнать о проблеме раньше клиента.