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

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

Разделите состояние и событие

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

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

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

Согласуйте время и идентификаторы

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

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

Не все ошибки сервер видит одинаково. Браузерный отказ внешнего скрипта или проблема DNS могут не попасть в журнал приложения. Поэтому отсутствие записи — повод проверить весь путь запроса, а не доказательство, что жалоба ошибочна. Частичная недоступность разобрана в отдельном материале.

Отмечайте изменения и фоновые работы

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

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

Собирайте контекст без лишних данных

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

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

Стройте проверяемые гипотезы

Зафиксируйте исходный симптом и диапазон времени. Затем перечислите наблюдения отдельно от предположений. Например: «выросло число ожидающих запросов» — наблюдение; «виновата база» — гипотеза. Для неё нужна следующая проверка: состояние соединений, блокировки или длительность определённых запросов.

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

После сбоя устраните пробел в наблюдении

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

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

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

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