Четыре тревоги, которых не было: мониторинг, живший только в документации

5 сентября 2026 года мы решили проверить не сайт, а то, что должно было сообщить нам о его падении. В нашей внутренней документации с 17 января 2026 года стояла строка: четыре правила тревог, проверка каждые 30 секунд. Доля ошибок выше 5 % в течение пяти минут, время ответа (p95) дольше 2 секунд в течение 10 минут, исчерпанный пул соединений с базой, сутки без единого брифа. Звучало как защита от всего, что может случиться с сайтом агентства.

Мы открыли Grafana, где эти правила должны были жить. Правил там было ноль.

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

Что мы нашли 5 сентября

Дефектов оказалось три, и каждый по отдельности делал те четыре правила бесполезными.

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

Правилам не на что было смотреть. Все четыре были написаны на метриках сайта: количество HTTP-запросов, их длительность, ошибки, состояние базы. Эти метрики объявлены в коде, то есть имеют имя и описание. Но страницы сайта не вызывают функцию, которая должна была их записывать. Мы проверили это ещё раз 17 сентября: в хранилище метрик не нашлось ни одного ряда данных ни для запросов, ни для ошибок, ни для базы. Даже если бы кто-то подключил файл с правилами, они сравнивали бы с порогом пустоту.

Доставки тоже не было. Единственным каналом уведомлений в Grafana был стандартный почтовый приёмник с адресом-заглушкой. Он есть в каждой свежей установке и никуда не шлёт.

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

Почему этого никто не заметил

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

Вторая причина в том, как выглядела сама запись. Она была конкретной: названия правил, пороги, интервал проверки. Такой текст не вызывает сомнений, потому что похож на описание уже сделанной работы. На самом деле это был план, записанный в форме отчёта.

И третье: дашборды были. Панели с привычными заголовками о частоте запросов и времени ответа стояли в Grafana, и сам факт их существования создавал ощущение, что мониторинг есть. Графики на этих панелях были пустыми, но пустой график легко прочитать как «сейчас ничего не происходит».

Что мы поставили взамен

В тот же день мы начали с сервера, а не с сайта, потому что именно сервер у нас уже падал. 2 августа 2026 года на общем сервере закончилась память: процессы начали принудительно убиваться, и машину пришлось перезагрузить. Об этом мы узнали не от системы, а постфактум.

Поэтому 5 сентября появились сборщики метрик самого сервера и контейнеров, отдельный дашборд и четыре правила, которые на этот раз существуют в Grafana и шлют сообщения в Telegram владельца:

• средняя нагрузка выше 8 (на восьми ядрах) в течение 10 минут;
• доступной памяти меньше 1 ГБ из 15 в течение 5 минут;
• корневой диск заполнен более чем на 90 % в течение 15 минут;
• любой источник метрик, включая сам сайт, не отвечает 5 минут.

У каждого правила есть подсказка в тексте сообщения: куда смотреть первым и что уже случалось. В правиле о памяти прямо написано, что именно так начинался сбой 2 августа.

Документацию переписали под то, что есть на самом деле, а старую строку о четырёх правилах оставили с пояснением, что их никогда не существовало. Иначе кто-то нашёл бы её в истории и поверил бы снова.

Что показали первые 12 дней

17 сентября все четыре правила были в состоянии «неактивно» и «исправно»: система их вычисляет, ошибок вычисления нет, условие не выполняется.

Чтобы понять, молчат ли правила потому, что всё в порядке, или потому, что не срабатывают, мы посмотрели на сами метрики за 12 дней от запуска правил 5 сентября до 17 сентября.

• Нагрузка в отдельные моменты доходила до 19,04, но самое высокое значение, которое держалось целых 10 минут подряд, было 6,79. Порога 8 оно не достигло.
• Доступной памяти меньше всего было 4,58 ГБ. До порога в 1 ГБ далеко.
• Диск поднимался до 93,05 %, то есть выше порога. Но каждый раз ненадолго: за все 12 дней набралось 16 минутных замеров выше 90 %, а самое высокое значение, державшееся все 15 минут подряд, было 88,13 %.
• Сайт как источник метрик не ответил один раз, и это был единственный минутный замер. Сборщики метрик сервера и контейнеров не пропустили ни одного.

Вывод двойной. Правила молчали обоснованно: ни одно условие не держалось весь свой промежуток времени. Но и настоящего срабатывания ещё не было, так что путь от нарушенного условия до сообщения в телефоне живым случаем пока не подтверждён.

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

Как проверить свой сайт

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

1. Посчитайте правила, которые существуют в системе, а не в документе. В Grafana это раздел Alerting → Alert rules, в Uptime Kuma — список мониторов, в панели хостинга — раздел уведомлений. Выпишите каждое: что проверяет, какой порог, сколько времени должно держаться нарушение. Если список пуст или короче, чем вам рассказывали, начните отсюда.
2. Откройте каждое правило и посмотрите, на что оно смотрит. Если правило считает ошибки сайта, откройте этот же запрос отдельно и убедитесь, что за последнюю неделю в нём вообще есть данные. Правило над пустой метрикой молчит не всегда одинаково: в Grafana у каждого правила есть отдельная настройка на случай отсутствия данных, и от неё зависит, увидите ли вы привычное «в норме» или отдельное состояние «нет данных», которое легко пропустить в списке. В трёх наших серверных правилах там стоит «нет данных», в правиле о недоступной цели — сразу тревога. Поломку пустая метрика не поймает ни в одном из вариантов, поэтому смотрите на данные под запросом, а не на цвет статуса.
3. Проверьте, куда идут уведомления. Посмотрите список каналов доставки: почта, Telegram, SMS. Адрес вроде example@email.com или канал, созданный человеком, который уже не работает с вами, означает, что доставки нет.
4. Отправьте тестовое уведомление и дождитесь его на телефоне. В Grafana кнопка Test есть в настройках каждого канала. Засчитывается только сообщение, которое вы увидели, а не зелёная отметка «отправлено».
5. Задайте себе три вопроса: если сайт начнёт отдавать ошибку 500, кто об этом узнает и когда; если закончится место на диске; если перестанут идти письма с заявками. На каждый должно быть название правила и человек, к которому оно придёт. Ответ «увидим в статистике» означает «никто».

Чего мы не решили

Наши новые правила следят за сервером и за тем, отвечает ли сайт. Они не следят за тем, правильно ли сайт работает.

Ошибки 500 на отдельной странице мы до сих пор не видим, потому что метрики запросов, с которых всё началось, так и остались пустыми. Провал отправки письма тоже не даёт уведомления. 8 сентября 2026 года два письма не ушли, журнал это записал, а нашли мы эти записи вручную, когда сами его открыли. Историю с письмами мы подробно разобрали отдельно: форма говорит «спасибо», а письмо не уходит.

То есть 5 сентября мы закрыли самую грубую часть: падение сервера больше не пройдёт мимо нас. Тихая поломка внутри сайта до сих пор пройдёт. Следующий шаг у нас именно такой: записывать ошибки запросов и неудавшиеся письма и ставить на них правила с тем же каналом доставки.

Если вам нужно, чтобы кто-то настроил такое наблюдение для вашего сайта и проверил, что сообщения действительно доходят, это работа по мониторингу доступности. Реагирование на сами сбои и состояние сервера входит в администрирование сервера.

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