Сайт недоступен несколько минут, а мониторинг показывает норму

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

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

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

Почему мониторинг показывает норму во время короткого сбоя

Сначала разделите три ситуации: проверка не встретила неисправность; проверка встретила её, но система не признала инцидент; инцидент возник, но сообщение не дошло. У каждой ситуации свои доказательства и способ исправления.

Как интервал проверки влияет на обнаружение

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

Ниже приведён расчёт по этой модели. Это не статистика клиентских сайтов и не обещание конкретного сервиса.

Для двухминутного отказа при пятиминутном интервале модель даёт 40% вероятности обнаружения и 60% вероятности пропуска. Даже когда проверка попала в отказ, сообщение может не появиться из-за правил подтверждения. Условие двух неудачных плановых проверок с минутным шагом, например, не выполнится при одном непрерывном отказе на 30 секунд в этой модели.

На практике запросы имеют длительность, точки могут опаздывать, а сбои бывают периодическими. Поэтому значения 100% в таблице относятся только к указанным условиям. Проверка раз в минуту не гарантирует минутную доставку уведомления.

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

Как определить границы длительности отказа

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

Если мгновенные проверки были успешны в 12:00 и 12:03, а в 12:01 и 12:02 дали ошибку, длительность этого непрерывного отказа находится примерно между одной и тремя минутами. Показать в отчёте ровно две минуты можно как принятую оценку по измерениям, но нельзя выдавать её за установленную фактическую длительность.

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

Что сохранить при очередной жалобе

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

1. Уточните действие. Какую страницу открывали, что нажали, какой результат ожидали и что произошло вместо него. Жалобы на вход, каталог и оплату нельзя автоматически объединять в один сбой.
2. Зафиксируйте время и условия. Дата, часовой пояс, приблизительное начало и окончание, регион, оператор, устройство и наличие авторизации. Снимок ошибки полезен вместе с адресом страницы.
3. Выгрузите исходные проверки. Нужны результаты до, во время и после эпизода, включая неудачные попытки, повторы и пропущенные запуски.
4. Сохраните журналы. Возьмите интервал с запасом по обе стороны события, включая файлы до и после ротации. В панели хостинга проверьте, что выгружен журнал нужного домена и HTTPS.
5. Отметьте изменения. Обновление, перезапуск, резервное копирование, импорт, очистка кеша, изменение DNS или защиты. Это кандидаты для сопоставления, а не заранее назначенные причины.

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

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

Для расследования недостаточно отметок «доступен» и «недоступен». Сохраняйте поля, позволяющие отличить отказ соединения от неправильного ответа и связать внешнее наблюдение с серверной обработкой.

Сетевую ошибку сохраняйте отдельно от HTTP-кода. Если ответ HTTP не получен, нельзя подменять это состояние придуманным кодом 500. В curl значение 000 в таком случае не является ответом сервера: причину уточняют по коду завершения и сообщению самого инструмента.

Некоторые времена curl отсчитываются от начала всей операции. Например, time_starttransfer уже включает предыдущие этапы. Складывать его с временем DNS и соединения нельзя. Для разбора фаз учитывайте накопительный характер измерений, перенаправления и повторное использование соединения.

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

Как сопоставить события по времени

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

Различайте время события, завершения запроса и попадания записи в хранилище. В модели OpenTelemetry для события и его наблюдения предусмотрены разные поля. А строка access-журнала NGINX появляется при завершении обработки: длинный запрос может быть записан позже начала проблемы.

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

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

Когда часть цепочки отсутствует, обозначьте границу вывода. Формулировка «веб-сервер получил запрос и ожидал приложение, но журнал приложения за этот интервал утрачен» полезнее неподтверждённого утверждения о проблеме базы данных.

На каком уровне искать причину

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

У каждого журнала есть границы. DNS-ошибка или разрыв до установления HTTP-соединения не обязаны оставлять запись в журнале обращений веб-сервера. А ответ, сформированный кешем или защитой перед сервером, может не вызвать обращение к приложению.

Даже панель поставщика не всегда содержит все события. Например, Cloudflare Security Analytics использует выборочные данные в стандартном представлении. При расследовании отдельного короткого отказа уточняйте полноту выгрузки, фильтры и доступность исходных записей. Отсутствие события в выборке не доказывает отсутствие самого запроса.

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

Почему средние показатели скрывают проблему

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

Допустим, минутная нагрузка процессора составляла 10%, 10%, 100%, 10% и 10%. Среднее за пять минут равно 28%. На общем графике оно выглядит умеренным, хотя одна минута резко отличается от остальных. Этот расчёт показывает эффект усреднения; сама загрузка процессора ещё не устанавливает причину отказа.

Процентили тоже не заменяют учёт ошибок. Если из 1000 запросов 990 завершились за 200 миллисекунд, а 10 — за 10 секунд, p95 останется около 200 миллисекунд. Поэтому рядом со временем ответа нужны число запросов, доля ошибок и разбивка по важным операциям. Быстрый ошибочный ответ также может выглядеть хорошо на графике задержки.

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

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

Как настроить наблюдение за короткими отказами

Начните с минимального отказа, который важно обнаруживать, и допустимой задержки реакции. Затем подберите проверки, правила подтверждения и срок хранения. Ниже — стартовый профиль для обсуждения с администратором, который нужно проверить на собственном трафике и ресурсах.

Частота имеет цену. Один HTTP-запрос каждые 30 секунд из двух точек создаёт 5760 запросов в сутки. Если проверяется десять адресов, это уже 57 600 запросов без повторов. Браузерный сценарий дополнительно загружает ресурсы и выполняет фоновые обращения. Контроль не должен сам создавать отказ дорогой операции.

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

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

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

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

Как проверить исправление и сам мониторинг

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

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

Испытание выделенного адреса проверяет механизм мониторинга. Его результат нельзя выдавать за подтверждение работоспособности всех операций магазина. Для них нужны собственные контрольные действия.

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

Что короткие отказы означают для бизнеса

Оценивайте воздействие по затронутым действиям и времени. Сколько попыток входа, отправки заявки или оформления не завершилось; были ли повторные обращения; сохранились ли заказы и статусы оплаты. Число технических ошибок нельзя автоматически умножить на средний чек и назвать потерянной выручкой.

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

Ответы на частые вопросы