Как узнать, что сайт упал, раньше клиентов: полное руководство по мониторингу

Сайт лёг в 02:14. Вы узнали об этом в 09:40, когда клиент написал в поддержку: «У вас ничего не открывается». Семь с половиной часов магазин не принимал заказы, реклама продолжала тратить бюджет, а поисковый робот, зашедший ночью, получил ошибку вместо страницы.

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

Почему «сайт открывается» ещё ничего не значит

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

• Кеш браузера и CDN. Вы видите копию страницы, сохранённую вчера, а сервер за ней уже не отвечает.

• DNS. У вас домен ещё записан в кеше провайдера, а у части пользователей запись уже пропала или указывает не туда.

• Сертификат. SSL истёк ночью. Браузер показывает страшное предупреждение, и до сайта доходит меньшинство.

• Отдельные страницы. Главная живая, а корзина или оплата отдают 500. Для магазина это хуже, чем полное падение: реклама приводит людей, а купить они не могут.

• Фоновые задачи. Сайт работает, но cron, который выгружает заказы в 1С или шлёт письма, молча умер неделю назад.

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

Внешний и внутренний мониторинг: в чём разница

Внутренний мониторинг живёт на вашем сервере: Prometheus, Zabbix, Netdata, графики нагрузки, логи. Он отвечает на вопрос «почему сломалось»: кончилась память, база упёрлась в диск, процесс ушёл в бесконечный цикл.

Внешний мониторинг стучится в сайт снаружи, как обычный посетитель. Он отвечает на вопрос «сломалось ли вообще» и видит то, что изнутри не видно: проблемы DNS, сети хостера, сертификата, балансировщика, Cloudflare.

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

Простое правило: внешний мониторинг будит человека, внутренний помогает ему понять, что чинить.

Семь проверок, которые закрывают почти все сбои

1. HTTP-проверка: сайт отвечает и отвечает правильно

Базовая проверка: раз в минуту отправляем запрос на страницу и смотрим на код ответа. Всё из диапазона 200–399 считаем успехом, 4xx и 5xx считаем сбоем, отсутствие ответа за отведённое время считаем таймаутом.

Но одного кода мало. Классическая ловушка: сервер отдаёт 200 OK, а внутри страница «Ошибка подключения к базе данных» или пустой шаблон. Поэтому к HTTP-проверке добавляют проверку ключевого слова: на странице должна быть строка, которая появляется только при нормальной работе. Например, «Добавить в корзину» на карточке товара или название компании в подвале. И наоборот, можно ловить строки, которых быть не должно: «Fatal error», «Warning: mysqli», «Service Unavailable».

Проверьте вручную, что отвечает ваш сайт:

curl -sS -o /dev/null -w "код: %{http_code}, время: %{time_total} с\n" https://example.ru/

2. Время ответа: сайт не упал, но тормозит

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

Чтобы понять, на каком этапе теряется время, разложите запрос на части:

curl -sS -o /dev/null https://example.ru/ -w "DNS: %{time_namelookup} с
Соединение: %{time_connect} с
TLS: %{time_appconnect} с
Первый байт: %{time_starttransfer} с
Всего: %{time_total} с
"

Если большая часть уходит до первого байта, тормозит бэкенд или база. Если на TLS, проблема в настройках сертификата или сервера. Если на DNS, смотрите на DNS-хостинг.

3. SSL-сертификат: самый обидный сбой

Обидный, потому что он полностью предсказуем: дата окончания известна заранее. Сертификаты Let's Encrypt живут 90 дней и продлеваются автоматически, но автопродление ломается постоянно: сменили сервер и забыли перенести certbot, закрыли 80-й порт, поменяли DNS, переехали на другой хостинг.

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

Посмотреть дату окончания из консоли:

echo | openssl s_client -connect example.ru:443 -servername example.ru 2>/dev/null \
  | openssl x509 -noout -subject -enddate

4. Срок регистрации домена

Домен оплачивается раз в год, и письма регистратора часто уходят на почту бывшего сотрудника или фрилансера, который когда-то покупал домен. Если не продлить вовремя, сайт отключится, а через некоторое время домен может перехватить кто-то другой. Для бизнеса это одна из самых дорогих ошибок, а предотвратить её можно одной проверкой: за 30 и за 7 дней до окончания приходит напоминание.

5. DNS-записи

DNS ломается редко, но громко: неудачная правка в панели регистратора, истёкший DNS-хостинг, перенос домена. Особенно опасны две вещи:

• MX-записи. Сайт работает, а почта на домене перестала приходить. Заметят через день, когда клиенты скажут, что вы не отвечаете.

• Подмена A-записи или NS. Домен начинает указывать на чужой сервер. Это может быть ошибка, а может быть атака.

DNS-проверка регулярно запрашивает запись и сравнивает с ожидаемым значением. Вручную это делается так:

dig +short A example.ru
dig +short MX example.ru
dig +short NS example.ru

6. Порты и ping: всё, что не сайт

Не всё в инфраструктуре отвечает по HTTP. База данных, Redis, почтовый сервер, SSH, игровой сервер: для них подходит проверка TCP-порта. Монитор открывает соединение и сразу закрывает его. Если порт не отвечает, значит сервис лёг или его закрыл файрвол.

Ping проверяет, что сам сервер жив в сети. Он полезен для VPS и офисного оборудования, но есть нюанс: многие хостеры и файрволы режут ICMP. Если ping не проходит, а сайт работает, лучше проверять открытый порт.

nc -zv db.example.ru 5432
ping -c 3 203.0.113.10

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

7. Cron-задачи: мониторинг тишины

Самый недооценённый вид проверки. Бэкапы, выгрузки в 1С, рассылки, обновление курсов валют, очистка старых данных: всё это работает по расписанию, и когда задача перестаёт запускаться, никто ничего не видит. Ошибки нет, потому что нет и запуска.

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

В crontab это одна строка. Обратите внимание на &&: сигнал уходит, только если бэкап завершился успешно.

0 3 * * * /opt/scripts/backup.sh && curl -fsS -m 10 --retry 3 https://getdevpulse.ru/ping/ВАШ_КОД > /dev/null

Если задача запускается через systemd timer, удобно повесить сигнал на сам сервис:

[Service]
Type=oneshot
ExecStart=/opt/scripts/backup.sh
ExecStartPost=/usr/bin/curl -fsS -m 10 --retry 3 https://getdevpulse.ru/ping/ВАШ_КОД

Хороший приём: проверять в скрипте сам результат, а не только факт запуска. Например, бэкап размером 0 байт не должен считаться успехом:

#!/usr/bin/env bash
set -euo pipefail

file="/backups/db-$(date +%F).sql.gz"
pg_dump --no-owner shop | gzip > "$file"

if [ "$(stat -c %s "$file")" -lt 1048576 ]; then
  echo "Бэкап подозрительно маленький: $file" >&2
  exit 1
fi

curl -fsS -m 10 --retry 3 https://getdevpulse.ru/ping/ВАШ_КОД > /dev/null

Страница здоровья: что проверять на самом деле

Проверять главную страницу удобно, но она часто отдаётся из кеша и не задевает базу. Надёжнее сделать отдельный адрес, например /health, который проверяет критичные зависимости и отвечает 200 только если всё в порядке.

Несколько правил хорошего health-эндпоинта:

• Он должен быть быстрым: простой запрос select 1 в базу, а не тяжёлая выборка.

• Он должен проверять только то, без чего сайт действительно не работает. Если упал сервис рекомендаций, а магазин продаёт, это не повод отвечать 503.

• Он не должен раскрывать детали: версии, адреса баз, текст ошибок. Наружу достаточно кода ответа и короткого статуса.

• Его не нужно кешировать ни на CDN, ни в браузере.

Пример на Node.js с Express и PostgreSQL:

import express from 'express';
import postgres from 'postgres';

const sql = postgres(process.env.DATABASE_URL!);
const app = express();

app.get('/health', async (_req, res) => {
  res.set('cache-control', 'no-store');
  try {
    await Promise.race([
      sql`select 1`,
      new Promise((_, reject) => setTimeout(() => reject(new Error('timeout')), 2000))
    ]);
    res.status(200).json({ status: 'ok' });
  } catch {
    res.status(503).json({ status: 'degraded' });
  }
});

app.listen(3000);

То же на Python с FastAPI:

import asyncio
import asyncpg
from fastapi import FastAPI, Response

app = FastAPI()

@app.on_event("startup")
async def startup():
    app.state.pool = await asyncpg.create_pool(dsn="postgresql://shop@localhost/shop")

@app.get("/health")
async def health(response: Response):
    response.headers["Cache-Control"] = "no-store"
    try:
        async with app.state.pool.acquire() as conn:
            await asyncio.wait_for(conn.fetchval("select 1"), timeout=2)
        return {"status": "ok"}
    except Exception:
        response.status_code = 503
        return {"status": "degraded"}

И не забудьте отключить кеш для этого адреса в nginx, если перед приложением стоит кеширующий прокси:

location = /health {
    proxy_pass http://127.0.0.1:3000;
    proxy_no_cache 1;
    proxy_cache_bypass 1;
    add_header Cache-Control "no-store" always;
    access_log off;
}

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

Как часто проверять и сколько ждать ответа

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

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

Ложные тревоги: как не начать игнорировать уведомления

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

Откуда они берутся:

• Короткий сбой сети между мониторингом и сайтом, который ваши пользователи даже не заметили.

• Слишком маленький таймаут: сайт ответил за 4 секунды при таймауте в 3.

• Защита от ботов (Cloudflare, DDoS-Guard, Qrator), которая начинает показывать мониторингу капчу.

• Плановые работы, о которых мониторинг не знал.

Что с этим делать:

1. Подтверждать сбой перед тревогой. Одна неудачная проверка ещё не повод будить человека. Правильная схема: после неудачи сразу перепроверить, затем выждать 15–30 секунд и проверить ещё раз. Тревога уходит, только если сайт не ответил несколько раз подряд.

2. Ставить реалистичный таймаут. Посмотрите на обычное время ответа и умножьте его на три-пять.

3. Добавить мониторинг в белый список защиты от ботов, если она блокирует проверки.

4. Включать режим обслуживания на время плановых работ, чтобы мониторинг не поднимал тревогу, пока вы обновляете сервер.

Куда отправлять уведомления

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

• Telegram подходит для большинства команд: быстро, бесплатно, можно отправлять в общий чат.

• MAX и ВКонтакте подходят командам, которые уже живут там, и как запасной канал.

• Discord удобен, если команда разработки работает в нём.

• Почта хороша как второй канал и для несрочного: сертификат истекает через 14 дней, домен через месяц.

Несколько практических советов:

• Отправляйте тревоги минимум в два канала. Если Telegram недоступен, письмо всё равно придёт.

• Заведите отдельный чат для тревог и не смешивайте его с рабочим. В рабочем чате уведомление утонет за пять минут.

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

• Уведомление о восстановлении так же важно, как о падении. Оно показывает, сколько длился сбой, и закрывает вопрос.

Сколько простоя допустимо: считаем аптайм

Аптайм в процентах выглядит красиво, но в минутах он нагляднее. Вот сколько сайт может лежать при разных уровнях доступности:

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

И ещё одно: хостер обещает 99,9% своему серверу, а не вашему сайту. Ваш код, база, сертификат, DNS и cron в его аптайм не входят.

Что значат ошибки, которые вы увидите

Когда приходит тревога, текст ошибки уже подсказывает, где искать. Короткий словарь:

Первые 15 минут после падения

Когда пришла тревога, важно не метаться, а идти по короткому списку. Его стоит распечатать или закрепить в чате тревог.

1. Подтвердите проблему. Откройте сайт с телефона через мобильный интернет, а не через рабочий Wi-Fi. Так вы исключите проблемы своей сети и кеша.

2. Сообщите, что занимаетесь. Одно сообщение в чат: «Смотрю, сайт лежит». Это остановит панику и параллельные попытки чинить одно и то же.

3. Вспомните, что менялось. Большинство падений случается после изменений: деплой, обновление плагина, правка конфига, перенос DNS. Если что-то выкатывали в последний час, откат часто быстрее поиска причины.

4. Проверьте ресурсы сервера. Диск, память, процессы. Переполненный диск остаётся одной из самых частых причин внезапных падений.

5. Предупредите клиентов. Если сбой затягивается, опубликуйте сообщение на странице статуса или в соцсетях. Люди спокойнее относятся к проблеме, о которой их предупредили, чем к молчанию.

6. После восстановления запишите, что случилось. Пока детали свежие.

Полезные команды для первичной диагностики на Linux-сервере:

df -h
free -m
uptime
systemctl status nginx
journalctl -u nginx --since "30 min ago" --no-pager | tail -50
docker ps --format "table {{.Names}}\t{{.Status}}"

Разбор после сбоя: зачем и как

Разбор нужен не для поиска виноватых, а чтобы тот же сбой не повторился. Достаточно короткой записи по шаблону:

• Что произошло и как это выглядело для пользователей.

• Хронология: когда началось, когда узнали, когда починили. Разница между «началось» и «узнали» показывает качество мониторинга.

• Причина. Настоящая, а не «сервер упал». Почему упал?

• Что сделали, чтобы восстановить работу.

• Что сделаем, чтобы не повторилось, с ответственным и сроком.

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

Страница статуса: меньше вопросов в поддержку

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

Для B2B-сервисов страница статуса ещё и вопрос доверия: клиенты видят, что вы не скрываете проблемы и быстро их решаете. Разместите на ней свой домен, например status.example.ru, и дайте ссылку в подвале сайта и в письмах поддержки.

Готовый план: настройка мониторинга за один вечер

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

1. Поставьте HTTP-проверку на главную страницу с интервалом в одну минуту.

2. Добавьте проверки на две-три самые важные страницы: корзину, оформление заказа, личный кабинет. Для каждой укажите ключевое слово, которое есть на странице при нормальной работе.

3. Если есть API, поставьте проверку на его health-эндпоинт.

4. Включите слежение за SSL-сертификатом и сроком регистрации домена.

5. Добавьте DNS-проверку MX-записи, если на домене работает почта.

6. Подключите heartbeat к каждой важной cron-задаче: бэкапы, выгрузки, рассылки.

7. Подключите два канала уведомлений: мессенджер для срочного и почту как запасной.

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

9. Сделайте страницу статуса и поставьте на неё ссылку.

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

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

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

Нужен ли мониторинг маленькому сайту?

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

Хостер же сам следит за серверами?

Хостер следит за своим оборудованием. Ваш сайт может лежать при полностью исправном сервере: из-за ошибки в коде, переполненной базы, истёкшего сертификата или сломанного плагина.

Можно ли сделать мониторинг самому на cron и curl?

Можно, но у самодельного решения есть проблема: оно обычно живёт на том же сервере, что и сайт, и падает вместе с ним. Мониторинг должен находиться снаружи, в другой сети.

Не создают ли проверки нагрузку на сайт?

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

Как мониторить сайт за защитой от DDoS?

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

Коротко

• Проверять нужно не только «открывается ли сайт», но и ключевые страницы, SSL, домен, DNS, порты и фоновые задачи.

• Мониторинг должен находиться снаружи вашей инфраструктуры.

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

• Тревоги отправляйте минимум в два канала и заранее договоритесь, кто реагирует.

• После каждого сбоя записывайте причину и что сделаете, чтобы он не повторился.

Всё, о чём шла речь в статье, умеет DevPulse: проверки сайтов, ключевых слов, портов, ping и DNS, слежение за SSL и доменами, heartbeat для cron, подтверждение сбоя перед тревогой, уведомления в Telegram, MAX, ВКонтакте, Discord и на почту, а также страницы статуса, на тарифах Pro и Business даже на своём домене. До 10 мониторов с проверкой раз в минуту бесплатно, без карты. Начните здесь, первый монитор настраивается за минуту.