独立站监控体系：可用性、性能、错误与证书的告警阈值
1. Мониторинг доступности: проверка раз в 5 минут, срабатывает только при серии неудач
Мониторинг доступности — самый базовый уровень: открывается ли сайт вообще. Многие настраивают оповещение по одной неудачной проверке, и тогда одно колебание сети будит человека, а через неделю все отключают оповещения. Правильно — считать сбоем только серию неудачных проверок: 2 подряд — жёлтое сообщение в чат, 3 подряд — SMS и звонок. Интервал проверки — 5 минут, минимум 3 точки по миру (например, восточное побережье США, Европа, Азиатско-Тихоокеанский регион), чтобы избежать ложных срабатываний с одной точки.
Что мониторить — не только главную страницу. Главная может жить за счёт кэша, а страница товара или форма заявки уже недоступны. Мониторьте минимум три URL: главную, страницу товара и эндпоинт отправки формы заявки. Падение любого из них — сбой доступности. Инструмента хватит бесплатной версии UptimeRobot: 50 мониторов, интервал 5 минут, несколько точек по миру.
| Объект мониторинга | Интервал проверки | Жёлтый порог | Красный порог | Способ оповещения |
|---|---|---|---|---|
| HTTP-статус главной | 5 минут | 2 подряд не 200 | 3 подряд не 200 | Чат → SMS и звонок |
| Страница товара | 5 минут | 2 подряд не 200 | 3 подряд не 200 | Чат → SMS и звонок |
| Эндпоинт формы заявки | 10 минут | 2 подряд 5xx | 3 подряд 5xx | Чат → SMS и звонок |
| TCP-порт 22/3306 | 5 минут | Недоступен | — | Сообщение в чат (только в рабочее время) |
| SSL-сертификат | 24 часа | Осталось 30 дней | Осталось 15 дней | Письмо → WeCom |
Пример из практики: один зарубежный сайт мониторил главную через UptimeRobot с оповещением после 3 неудач подряд. Однажды ночью сингапурская точка дала 3 неудачи подряд, а точки в США и Европе работали нормально — проблема была в локальной сети Сингапура, а не в сайте. Если бы оповещение шло по одной проверке, дежурный проснулся бы в 2 часа ночи, увидел, что сайт в порядке, и в следующий раз уже не поверил бы. Несколько точек плюс серия неудач сводят ложные срабатывания к минимуму.
Доступность и аварийное восстановление RTO/RPO— это единый комплекс: сработало оповещение о доступности — действуем по регламенту восстановления. Как определить сбой узла CDN, см.Глобальное ускорение CDN.
2. Мониторинг производительности: следите за LCP, а не за общей оценкой
Главная ошибка в мониторинге производительности — гнаться за общей оценкой. Баллы Google PageSpeed сильно колеблются: одна и та же страница утром показывает 85, а днём — 65. Оповещать о таких скачках бессмысленно. Следить нужно за тремя ключевыми метриками Core Web Vitals, и в первую очередь за LCP ( Largest Contentful Paint) — она напрямую влияет на восприятие пользователя и позиции в SEO.
Для оповещений о производительности используйте не один порог, а длительность. Если LCP иногда превышает 2,5 секунды — возможно, у кого-то плохая связь. Но если превышение держится больше 10 минут — это реальная проблема. Жёлтый порог: LCP выше 2,5 секунды в течение 10 минут. Красный порог: LCP выше 4 секунд в течение 15 минут. Из инструментов — BrowserStack SpeedCurve или открытые данные Chrome User Experience Report, смотрите тренды по месяцам.
| Показатель | Критерий | Жёлтый порог | Красный порог | Пояснение |
|---|---|---|---|---|
| LCP Largest Contentful Paint | ≤2,5 секунды | >2,5 секунды в течение 10 минут | >4 секунд в течение 15 минут | Самая важная метрика, напрямую влияет на SEO и конверсию |
| INP Interaction to Next Paint | ≤ 200 миллисекунд | >200 миллисекунд в течение 10 минут | >500 миллисекунд в течение 15 минут | Следите за зависаниями при отправке форм |
| CLS Cumulative Layout Shift | ≤ 0,1 | >0,1 в течение 10 минут | >0,25 в течение 15 минут | Вызывают реклама или ленивая загрузка изображений |
| TTFB Time to First Byte | ≤600 миллисекунд | >600 миллисекунд в течение 10 минут | >1,5 секунды в течение 15 минут | Медленный бэкенд или проблемы с базой данных |
| Доля ошибок по всему сайту | <1% | >1% в течение 5 минут | >5% в течение 10 минут | 5xx и 4xx считайте отдельно |
Пример из практики: однажды утром на сайте LCP вырос с 1,8 до 3,5 секунды и через 20 минут сам восстановился. В логах нашли медленный запрос к базе — плагин запустил задание по расписанию и прогнал полное сканирование таблицы. Без оповещения пользователи в эти 20 минут не смогли бы отправить заявку — таймаут и потерянный заказ. Ценность мониторинга производительности в том, что он ловит такие кратковременные ухудшения. Как оптимизировать Core Web Vitals, читайте в статье Пороги Core Web Vitals и приоритеты оптимизации.
3. Ошибки и логи: смотрите на 5xx и 4xx отдельно
Мониторинг ошибок делится на две категории: 5xx — ошибки сервера, о них нужно оповещать; 4xx — ошибки клиента, и большинство из них можно игнорировать. Если считать их вместе, то либо оповещений слишком много, либо реальные проблемы тонут в шуме. Доля 5xx выше 1% в течение 5 минут — жёлтый уровень, выше 5% в течение 10 минут — красный. Из 4xx следите только за резким ростом 404 — это значит, что где-то отвалились внешние ссылки или при редизайне забыли настроить 301.
Для отслеживания ошибок используйте инструменты вроде Sentry: он автоматически собирает ошибки JS на фронтенде и исключения на бэкенде и группирует их. Интернет-магазину не нужно разбирать каждую ошибку, но стоит следить за частотой топ-3 ошибок. Если какая-то ошибка вдруг превращается из одной в неделю в десять в час — значит, релиз принёс баг. Как анализировать логи, читайте в статье анализе логов AI-краулеров.
| Тип ошибки | Нормальный базовый уровень | Жёлтый порог | Красный порог | Что делать |
|---|---|---|---|---|
| 5xx ошибки сервера | <0.5% | >1% в течение 5 минут | >5% в течение 10 минут | Проверьте логи бэкенда, откатите релиз или расширьте ресурсы |
| 404 страница не найдена | <1% | Рост в 3 раза в течение 1 часа | Рост в 10 раз | Проверьте внешние ссылки и карту 301-редиректов |
| Ошибки JS на фронтенде | <10 раз в день | >50 раз в день | >200 раз в день | Разбирайте по группам в Sentry |
| Ошибка отправки формы заявки | <1% | >3% в течение 10 минут | >10% | Проверить SMTP и синхронизацию с CRM |
| Не удалось подключиться к базе данных | 0 раз | Один раз | 3 раза подряд | Проверить статус MySQL |
Пример из жизни: после выпуска новой версии сайта число JS-ошибок в Sentry выросло с 3 до 200 в день. В коде нашли скрипт рекламного блока, который падал в Safari и ломал отправку форм. Без оповещения заявки от пользователей Safari просто терялись бы. Мониторинг частоты ошибок в Sentry позволяет заметить такие регрессии в течение 24 часов после релиза.
Четыре. Мониторинг сертификатов и бэкапов: две вещи, о которых забывают чаще всего
证书过期是独立站最常见的”低级事故”。90%的证书过期不是技术问题，是忘了续。监控要设两层：剩余30天发邮件提醒，剩余15天发企业微信告警。不要等到只剩3天才提醒——那时候域名注册商邮箱可能也进垃圾箱了，或者DNS解析出问题来不及修。工具用UptimeRobot的证书监控或者自定义脚本每天探测。
Сами задачи резервного копирования тоже нужно контролировать. Скрипт бэкапа упал, вы об этом не знаете, а когда случится беда, окажется, что последняя копия сделана две недели назад. Три правила оповещения: код возврата задачи бэкапа не равен 0; размер файла бэкапа резко упал на 30% по сравнению с прошлым днём (возможно, нет связи с базой); возраст последнего бэкапа превышает 24 часа. Подробнее о стратегии резервного копирования —Бэкап и восстановление сайта.
| Объект мониторинга | Частота проверки | Жёлтый порог | Красный порог | Способ оповещения |
|---|---|---|---|---|
| Сколько дней осталось до истечения SSL-сертификата | Ежедневно | Осталось 30 дней | Осталось 15 дней | Письмо → WeCom |
| Код возврата задачи бэкапа | После каждого запуска | Не 0 | — | Сразу в WeCom |
| Размер файла бэкапа | Ежедневно | На 30% меньше, чем вчера | На 70% меньше, чем вчера | WeCom |
| Возраст файла бэкапа | Ежедневно | >24 часа | >48 часов | WeCom |
| Загрузка диска | Каждый час | >80% | >90% | WeCom |
| CPU/память | Каждые 5 минут | >80% в течение 10 минут | >95% в течение 10 минут | WeCom |
Контринтуитивное напоминание: не используйте один канал оповещений. Письма попадают в спам, в WeCom можно не заметить сообщение в отпуске, а SMS и звонок — последняя линия обороны. Важные оповещения (сайт недоступен, сертификат скоро истекает) обязательно отправляйте по SMS и звонком, обычные — в группу WeCom. Настройте эскалацию: если красное оповещение не обработали за 15 минут, оно автоматически уходит техническому руководителю. Чек-лист ежедневного осмотра —Шесть задач на месяц в период обслуживания сайта.
Когда система мониторинга настроена, раз в месяц пересматривайте оповещения: сколько жёлтых и красных сработало за месяц, сколько из них ложных. Если доля ложных превышает 30%, пороги нужно ужесточить или скорректировать. Цель мониторинга — не покрыть все возможные случаи, а разбудить человека в нужный момент, когда действительно что-то сломалось. Для этого придётся сознательно убрать правила, которые срабатывают впустую каждый день.
FAQ: частые вопросы
独立站监控用什么工具，免费方案够吗？
Что делать, если команда перестала реагировать на алерты?
С каким интервалом проверять доступность?
Как настроить пороги для мониторинга SSL-сертификата?
За каким показателем следить в мониторинге производительности и стоит ли смотреть на PageSpeed?
Как отслеживать сбои задач резервного копирования?
В заключение
Самая частая ошибка в мониторинге — не отсутствие мониторинга, а его избыток, из-за которого никто не смотрит на алерты. Сразу после настройки хочется следить за всем: CPU, память, диск, сеть, каждый URL, каждая ошибка. Через неделю алертов так много, что команда перестаёт реагировать, и настоящий красный алерт тонет в жёлтом шуме. Ценность мониторинга в том, чтобы «разбудить человека в критический момент», а не в широте охвата.
Три шага к внедрению. Первый: по четырём направлениям (доступность, производительность, ошибки, сертификаты) задайте по два порога — жёлтый и красный. Жёлтый отправляется только в чат и не будит, красный — SMS и звонок. Второй: запустите комбинацию бесплатных инструментов — UptimeRobot плюс Sentry плюс скрипт для сертификатов, стоимость 0 рублей в месяц. Третий: раз в месяц пересматривайте алерты и удаляйте правила с долей ложных срабатываний выше 30%. Мониторинг — живая система, а не разовая настройка: её нужно постоянно подрезать.
Фраза, которую стоит запомнить: цель мониторинга — не охватить все возможные сбои, а разбудить человека в нужный момент. Когда алертов так много, что команда их отключила, это опаснее, чем отсутствие мониторинга.