Мониторинг сайта — это не только проверка, открывается ли главная страница. Надёжная схема показывает доступность, время ответа, ошибки HTTP, состояние сертификата и важные пользовательские сценарии. При этом уведомления должны помогать действовать, а не превращаться в шум. Разберём, что контролировать на старте и как настроить алерты так, чтобы команда успела отреагировать.
Что именно нужно проверять
Начните с внешнего запроса: доступен ли URL, какой статус вернул сервер и сколько занял ответ. Затем добавьте проверку ключевого сценария — например, открытие формы, поиск товара или авторизацию в тестовой среде. Внутренние метрики сервера важны, но пользовательский мониторинг первым показывает реальную проблему.
- HTTP-код и время ответа;
- срок действия TLS-сертификата;
- ошибки DNS и доступность домена;
- доступность API и фоновых задач;
- рост 4xx и 5xx в логах;
- нагрузку, память и место на диске.
Важно! Проверка «страница вернула 200» не гарантирует, что сервис работает. Сервер может отдавать заглушку с успешным кодом, пока форма или база данных недоступны.
Чем отличаются метрики, логи и проверки
Метрики — это числовые ряды во времени: задержка, количество запросов, загрузка CPU. Логи содержат события и детали конкретной ошибки. Синтетические проверки имитируют действия пользователя снаружи. Вместе они отвечают на разные вопросы: «насколько плохо», «что произошло» и «видит ли проблему клиент».
Не складывайте всё в один график. Для каждой панели определите аудиторию и действие: дежурному нужен алерт, разработчику — лог и трассировка, владельцу продукта — длительность деградации и число затронутых пользователей.
Базовая схема для небольшого сайта
- Проверять главную страницу и критический URL каждые несколько минут.
- Хранить историю задержек и статусов, а не только последнее значение.
- Отправлять уведомление при нескольких последовательных сбоях.
- Проверять сертификат заранее и разделять предупреждение и аварию.
- Добавить тестовую форму или API-эндпоинт без персональных данных.
Интервал выбирайте по цене простоя и нагрузке на сайт. Слишком частые запросы создают лишний трафик, а слишком редкие задерживают реакцию.
Как настроить пороги
Порог должен быть связан с пользовательским ущербом. Ошибка 500 на одной редкой странице и полный отказ главной — разные события. Для задержки полезно смотреть перцентили, а не только среднее: несколько очень медленных запросов могут потеряться в общей цифре.
Алерт не должен срабатывать из-за одного короткого сетевого сбоя. Используйте окно времени, количество повторов и условие восстановления. После каждого инцидента пересматривайте правило: если команда постоянно игнорирует сигнал, он настроен плохо.
Уведомления и маршрутизация
Критические события отправляйте дежурному каналу, предупреждения — в рабочий чат или почту. В сообщении должны быть URL, время, значение метрики, ссылка на график и инструкция первого действия. Не отправляйте в уведомления токены, cookies и содержимое пользовательских запросов.
Для каждого сервиса назначьте владельца. Если алерт приходит всем, ответственность размывается и реакция замедляется.
Логи как продолжение мониторинга
Когда проверка видит ошибку, откройте логи за тот же интервал и сопоставьте request ID. Статья о поиске причины ошибки по уровням и фильтрам поможет быстро отобрать нужные события. Логи должны иметь время, уровень, сервис и безопасный контекст.
Не храните бесконечный объём. Установите срок ретеншна, ограничьте доступ и убедитесь, что персональные данные маскируются до записи.
Проверка после релиза
После публикации новой версии запустите синтетическую проверку, проверьте основные страницы, фоновые задачи и потребление ресурсов. Если используется контейнер, сопоставьте мониторинг с состоянием сервисов Docker Compose. Зелёный статус pipeline — только начало наблюдения, а не доказательство, что пользовательский сценарий работает.
Интересно! Самый полезный алерт часто не самый громкий: предупреждение о постепенном росте задержки даёт время исправить проблему до полной недоступности.
Что делать при срабатывании
- Подтвердить проблему внешней проверкой и открыть график.
- Определить масштаб: один URL, регион, сервис или весь сайт.
- Проверить последние релизы, инфраструктуру и логи.
- Применить безопасный откат или отключить проблемную функцию.
- Зафиксировать причину, время восстановления и следующий контроль.
Не меняйте несколько независимых параметров одновременно: после этого трудно понять, что помогло.
Минимальный чек-лист
- есть внешняя проверка доступности;
- есть график задержки и ошибок;
- сертификат проверяется заранее;
- алерты имеют владельца и понятный текст;
- логи и история изменений доступны команде;
- проверен сценарий восстановления.
Мониторинг приносит пользу, когда превращает технический сигнал в конкретное действие. Начните с нескольких критических проверок, настройте честные пороги и расширяйте схему после реальных инцидентов.
Как не создать шум
Разделяйте предупреждения и аварии, объединяйте повторяющиеся события и выключайте правила, которые больше не связаны с работающей архитектурой. Раз в месяц просматривайте список алертов вместе с журналом инцидентов. Так мониторинг остаётся живой системой, а не коллекцией забытых графиков.
С чего начать наблюдение
Составьте карту пользовательского пути: открытие главной страницы, вход, поиск, оформление заказа или отправка формы. Для каждого шага определите проверку доступности и ожидаемый результат. Простая внешняя проверка уже покажет, что сайт отвечает и отдаёт правильный код, а не только «не упал» на уровне сервера.
Затем добавьте внутренние метрики. Веб-сервер даст сведения о времени ответа и ошибках, приложение — о сбоях бизнес-операций, база данных — о соединениях и задержках. Не пытайтесь собрать всё сразу: начните с показателей, которые помогают отличить проблему сайта от проблемы внешнего сервиса.
Важно! Алерт должен приводить к действию. Если команда не знает, кто и что делает после сигнала, правило превращается в шум.
Доступность и скорость
Проверяйте не только среднее время ответа. Пользователи видят хвост распределения, поэтому полезны p95 или p99 задержки: они показывают, как ведёт себя медленная часть запросов. Отдельно отслеживайте долю ответов 4xx и 5xx, время загрузки ключевых страниц и доступность критических API.
Для внешних проверок задайте несколько точек наблюдения, если аудитория распределена по регионам. Один неудачный запрос может быть сетевым сбоем, а повторяемая ошибка из разных точек уже похожа на инцидент. Интервал проверки выбирайте с учётом стоимости и допустимого времени простоя.
Логи и контекст
Метрика говорит, что стало хуже, а лог помогает понять почему. Добавляйте идентификатор запроса, имя сервиса, окружение и безопасный набор параметров. Не записывайте пароли, токены и персональные данные без необходимости. Материал о чтении серверных логов поможет настроить уровни сообщений и быстро находить первый сбой.
Связывайте события между системами через единый trace или request ID. Тогда путь запроса можно проследить от браузера до базы данных. Если приложение работает в контейнерах, заранее проверьте ротацию логов и лимиты диска: полный диск способен остановить сервис, даже когда график CPU выглядит нормально. Для базовой настройки окружения пригодится разбор Docker Compose для начинающих.
Алерты в Prometheus и похожих системах
Правило обычно состоит из выражения, порога и времени, в течение которого условие должно сохраняться. Такая задержка снижает количество срабатываний на короткие пики. В уведомлении укажите сервис, окружение, ссылку на график и понятное действие. Для аварийного сигнала полезно сразу показать, какие пользователи затронуты.
После настройки проведите учебный инцидент: искусственно остановите тестовый сервис, дождитесь уведомления и проверьте маршрут эскалации. Запишите, сколько времени прошло до сигнала и до подтверждения. Без такой репетиции команда узнает о пробеле только во время настоящей аварии.
Еженедельная проверка
Раз в неделю просматривайте ошибки, длительные запросы и незакрытые предупреждения. Сверяйте графики с обращениями пользователей и журналом релизов. После изменений в инфраструктуре обновляйте пороги, ссылки и ответственных. Постепенно мониторинг станет частью эксплуатации, а не отдельным проектом, который вспоминают только после сбоя.
Мониторинг для разных типов сайтов
Для визитки достаточно внешней проверки, сертификата и контроля формы. Интернет-магазину нужны тест корзины, оплаты и остатков. Для API важны отдельные проверки авторизации, времени ответа и схемы данных. Контентному сайту полезно контролировать доступность публикаций и ошибки изображений.
Сценарии выбирайте по цене отказа. Не нужно имитировать весь путь пользователя, если один критический запрос уже показывает проблему. Но и одной главной страницы мало, когда деньги теряются на этапе оформления заказа.
Как хранить историю и контекст
Графики должны сохранять данные дольше обычного окна инцидента, чтобы видеть сезонность и постепенное ухудшение. К каждой важной точке добавляйте аннотацию: релиз, изменение конфигурации, миграция или авария у провайдера. Без контекста график превращается в красивую линию, по которой трудно сделать вывод.
Синхронизируйте время на серверах и в системе мониторинга. Несовпадение часовых поясов часто усложняет поиск причины, особенно если событие произошло ночью.
Ошибки в настройке алертов
- уведомлять о каждой единичной ошибке без окна агрегации;
- использовать только абсолютные пороги без учёта обычного уровня;
- не проверять восстановление после сбоя;
- отправлять предупреждение в канал без ответственного;
- оставлять старые правила после изменения архитектуры.
Перед включением правила проведите тестовое срабатывание и убедитесь, что сообщение приходит нужному человеку. После изменения порога сохраните причину в журнале.
Наблюдаемость после изменений
Новая версия может пройти pipeline и всё равно ухудшить задержку или вызвать ошибки только на части данных. Поэтому после релиза включайте усиленное наблюдение на ограниченный период. Сравните метрики с базовой линией и проверьте логи критических операций.
Если обнаружили деградацию, сначала остановите дальнейшее распространение, затем решайте, нужен ли откат. Не ждите, пока алерт станет красным, если пользовательский ущерб уже виден.
Документация и дежурство
Для каждого критического алерта держите короткую инструкцию: что проверить, какой сервис владелец, где логи и как восстановить последнюю стабильную версию. Инструкцию обновляйте после инцидента, пока детали свежи.
Новые сотрудники должны понимать, почему правило существует и как выглядит нормальное состояние. Иначе мониторинг останется личным инструментом автора, а не частью командной эксплуатации.