Мониторинг доступности сайта: что проверять кроме ответа 200

Ответ 200 OK означает только одно: конкретный HTTP-запрос получил успешный код. Он не доказывает, что пользователь увидел нужную страницу, что сертификат скоро не истечёт и что сайт одинаково доступен из разных сетей.

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

1. DNS: находится ли адрес сервера

До HTTP клиенту нужно преобразовать домен в IP-адрес. Ошибка DNS делает сайт недоступным, даже если сервер и приложение работают нормально.

dig +short A example.ru
dig +short AAAA example.ru

В ответе ожидаются актуальные адреса сайта. Пустой результат, NXDOMAIN или неожиданный IP — повод проверить зону, делегирование и недавние изменения. Сравнить ответы разных resolver-серверов можно в проверке DNS.

2. Соединение и TLS: можно ли безопасно подключиться

Следующий слой — TCP-соединение с портом 443 и TLS handshake. Здесь проявляются закрытый порт, сетевой timeout, неполная цепочка сертификатов, несовпадение имени и истёкший сертификат.

curl -I --connect-timeout 5 --max-time 15 https://example.ru/

Для отдельной проверки сертификата используйте:

openssl s_client -connect example.ru:443 -servername example.ru </dev/null

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

3. HTTP: тот ли статус вернул нужный URL

Монитор должен проверять конечный пользовательский URL и ожидаемый код ответа. Для главной страницы это часто 200, для health endpoint — тоже 200, а для намеренно перенесённого ресурса ожидаемым результатом может быть редирект.

Важно ограничивать число редиректов и сохранять конечный URL. Цикл редиректов или переход на страницу авторизации может оставить инфраструктуру формально «живой», но нарушить пользовательский сценарий.

4. Содержимое: загрузилась ли правильная страница

Прокси, CDN и приложение способны вернуть 200 вместе со страницей ошибки. Поэтому для критических страниц полезно проверять устойчивый фрагмент текста — например, название продукта или элемент ответа API.

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

5. Время ответа: доступно не значит быстро

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

• время установления соединения;
• ожидание первого байта;
• полное время ответа;
• timeout — верхнюю границу ожидания.

Один медленный запрос ещё не доказывает проблему. Смотрите на повторяемость и сравнивайте результаты из нескольких регионов.

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

Сеть иногда теряет отдельные пакеты, DNS-resolver может кратковременно не ответить, а приложение — перезапускаться во время deploy. Перед уведомлением полезно повторить проверку или подтвердить сбой из другого региона.

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

Минимальный набор для обычного сайта

Начните с пяти сигналов:

1. домен разрешается в ожидаемый адрес;
2. TLS-соединение успешно, сертификат подходит домену;
3. конечный URL возвращает ожидаемый HTTP-код;
4. ответ содержит устойчивый фрагмент страницы;
5. время ответа не превышает выбранный порог.

Затем добавьте контроль срока домена, отдельный health endpoint для API и heartbeat для фоновых задач. Такой набор объясняет причину большинства сбоев значительно лучше, чем одиночная проверка 200 OK.