Как работает мониторинг доступности в Пруфене: путь от проверки до уведомления

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

Весь путь одной схемой

От момента проверки до сообщения в мессенджере — шесть шагов. Ниже схема целиком, дальше разберём каждый шаг подробно.

▼

▼

▼

▼

▼

Шаг 1. Проверка по расписанию из 13 точек

Всё начинается с расписания. Вы выбираете интервал — минимальный 2 минуты, — и в каждый тик проверку выполняют все точки мониторинга сразу: 11 в России от Мурманска до Владивостока, Минск и Испания. Точки стартуют практически одновременно; окно между первой и последней локацией обычно составляет 20–30 секунд.

Отсюда следует важная вещь, которую стоит понимать про любой мониторинг: время обнаружения инцидента равно выбранному интервалу. Никакой сервис не узнаёт о падении «мгновенно» — он узнаёт при очередной проверке. Поставили 2 минуты — узнаете максимум через 2 минуты, поставили 15 — через 15. Поэтому интервал стоит выбирать не по принципу «поменьше — покруче», а по цене минуты простоя конкретной страницы: для оформления заказа логичны минимальные 2 минуты, для блога — 10–15.

Сам запрос бывает трёх видов, и это разные вопросы к сайту. GET скачивает страницу целиком — так же, как её открывает браузер посетителя, — и заодно измеряет время ответа. HEAD запрашивает только заголовки: быстрее и дешевле, отвечает на вопрос «сервер жив и отдаёт нужный код». PING работает на сетевом уровне и проверяет отклик хоста; о его особенностях мы писали в статье про ping. Всего типов проверок 17 — от SSL и домена до товарных фидов, — но за «сайт жив или нет» отвечают именно эти три.

Шаг 2. Почему одна упавшая точка — ещё не авария

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

Поэтому решение принимается по доле точек. В настройках порогов задаются два независимых значения:

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

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

Шаг 3. Что именно попадает в инцидент

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

Причина в записи — не догадка, а факт: 502, 503, таймаут соединения, ошибка TLS. Она сразу указывает на сломанный слой: у нас есть отдельные разборы 502, 503 и таймаутов — по коду из уведомления вы попадаете сразу в нужный сценарий, не тратя время на «а что вообще сломалось». Именно поэтому в плане действий при падении первые минуты уходят не на диагностику, а на подтверждение масштаба — эта работа уже сделана за вас: подробнее в статье «Сайт упал: первые 10 минут».

Шаг 4. Пауза перед уведомлением

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

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

Шаг 5. Уведомление уходит во все ваши каналы

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

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

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

Шаг 6. Закрытие инцидента и что остаётся после

Как только доля точек, снова видящих сайт, дошла до порога восстановления, инцидент закрывается, и вы получаете сообщение «сайт снова работает» с точной длительностью простоя. Эта цифра — не «примерно полчаса», а конкретные минуты, посчитанные от первой неуспешной проверки до восстановления.

Дальше начинается то, ради чего мониторинг ведёт историю. Закрытые инциденты складываются в статистику: реальный аптайм за месяц (а не тот, что обещан в тарифе хостинга), повторяющиеся паттерны — «каждый вторник в 3:40», — и доказательная база для разговора с хостером. Как считать аптайм и что означают «три девятки», мы разбирали в статье про uptime, а как сверять его с обещаниями провайдера — в материале про SLA хостинга.

Что из этого настраивается под вас

Частые вопросы

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

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

Мониторинг проверяет сайт — не создаёт ли он нагрузку? Одна проверка — это один HTTP-запрос от каждой точки: несопоставимо меньше, чем создаёт один живой посетитель, открывающий страницу со всеми картинками и скриптами. Если у вас настроены анти-бот правила или строгие лимиты, адреса точек стоит внести в белый список, чтобы защита не блокировала проверки, — такой сценарий мы разбирали отдельно.

Чем это отличается от мониторинга, установленного на сам сервер? Точкой обзора. Система внутри вашей инфраструктуры знает про CPU и память, но при падении дата-центра падает вместе с сайтом и молчит. Внешний мониторинг смотрит на сайт снаружи, глазами посетителя, и не зависит от вашей площадки — сравнение обоих подходов есть в статьях про Zabbix и аналоги UptimeRobot.