Логи, метрики и трассировки: как собрать данные для расследования сбоя сайта
Логи, метрики и трассировки отвечают на разные вопросы при сбое сайта: что произошло с отдельной операцией, насколько массовой стала проблема и где задержался конкретный запрос. Их полезно связывать с внешней проверкой доступности. Тогда сообщение «сайт не отвечает» становится началом расследования с понятным временем, адресом и последовательностью действий.
Без такой связи команда часто спорит о разных наблюдениях. Маркетолог видит отсутствие заявок, администратор — нормальную загрузку процессора, разработчик — несколько ошибок в журнале. Все могут быть правы: сервер работает, но часть обращений застряла между формой и системой обработки. Задача наблюдаемости — собрать достаточно контекста, чтобы проверить эту гипотезу и выбрать действие.
Ниже разберём минимальную схему для сайта услуг, интернет-магазина и веб-приложения. Основное внимание — составу данных и порядку расследования. Учебный инцидент, названия полей, маршруты и числовые значения в примерах вымышлены; они показывают подход, а не описывают результаты работы конкретного сервиса.
Логи, метрики и трассировки: в чём разница
Лог — запись о событии, метрика — числовое измерение, которое удобно отслеживать во времени, трассировка — связанные участки выполнения одной операции. В введении OpenTelemetry в наблюдаемость эти сигналы рассматриваются как взаимодополняющие данные. Для их получения приложение и его компоненты должны быть соответствующим образом инструментированы: настроены на создание нужных записей и измерений.
Выбирать один «самый правильный» сигнал для всех задач не нужно. Сначала сформулируйте вопрос, который мешает принять решение. Если непонятен масштаб отказа, пригодятся показатели за интервал. Если требуется найти проблемную операцию, нужны её записи. Если операция проходит несколько компонентов, важны связи и длительности между ними.
| Данные | На какой вопрос отвечают | Пример для сайта | Чего сами по себе не доказывают |
|---|---|---|---|
| Логи | Что зафиксировал компонент в конкретный момент | Отправка заявки завершилась тайм-аутом обращения к CRM | Что все посетители столкнулись с такой же ошибкой |
| Метрики | Как меняются объём, задержка, доля ошибок и использование ресурсов | Из 200 попыток отправки за пять минут 30 завершились ошибкой | Какая именно строка программы стала причиной |
| Трассировки | Через какие операции прошёл запрос и сколько они заняли | Приём заявки занял 80 мс, ожидание внешнего API — 4 секунды | Что сохранённая выборка представляет абсолютно все запросы |
| Внешние проверки | Доступен ли выбранный адрес или сценарий из точки проверки | Контрольная страница перестала возвращать ожидаемый результат | Как устроен отказ внутри приложения |
Практический результат появляется при переходах между этими данными. Из уведомления открывают нужный временной интервал, по метрикам выделяют проблемный маршрут, по журналу находят пример, а по трассировке проверяют участок ожидания. Если каждую систему приходится искать заново, часть пользы от собранной информации теряется.
Какие логи действительно помогают расследованию
Запись «произошла ошибка» почти бесполезна без контекста. Для начала достаточно согласовать небольшой набор полей: время события с часовым поясом, сервис и окружение, версия приложения, название операции, результат, длительность и идентификатор запроса. Уровень важности помогает фильтровать поток, но не заменяет описание события.
Структурированный формат удобен тем, что нужное поле можно искать отдельно. Разработчику не приходится угадывать, означает ли число в конце строки длительность, код ответа или номер заказа. Вот условная запись о неудачной попытке передать заявку в интеграцию; названия полей здесь выбраны для примера:
{
"event_time": "2026-11-01T10:14:32.481Z",
"service": "lead-api",
"environment": "production",
"release": "release-example-12",
"event": "crm_delivery_failed",
"request_id": "demo-request-42",
"route": "/api/leads",
"duration_ms": 4002,
"outcome": "timeout"
}В такой записи нет содержимого обращения или контактных данных клиента. Для поиска технической причины достаточно типа операции и результата. Если связь с бизнес-записью необходима, используйте разрешённый внутренний идентификатор и заранее определите, кто сможет раскрыть связанный с ним контекст.
Различайте журнал веб-сервера, журнал приложения и журнал фонового обработчика. Первый может подтвердить, что запрос принят и какой HTTP-ответ отправлен. Второй объясняет ветку обработки. Третий показывает судьбу задачи после завершения HTTP-запроса. Запись об успешном приёме формы не равна подтверждению, что письмо отправлено или CRM приняла данные.
Полезный критерий детализации — следующий вопрос расследования. Если по записи нельзя понять операцию, добавьте её название. Если неизвестно, затронута ли новая версия, добавьте версию. Если уже можно принять решение, не включайте подробный отладочный вывод постоянно только ради большего объёма информации.
Какие метрики показывают масштаб проблемы
Для начала соберите небольшую панель по критичным действиям: число попыток, число неуспехов, распределение длительности и признаки нехватки ресурсов. В главе Google SRE о мониторинге выделены задержка, трафик, ошибки и насыщение. Этот набор помогает задавать вопросы о состоянии сервиса, но конкретные показатели нужно выбирать под устройство вашего сайта.
Например, для формы полезнее знать долю неуспешных отправок, чем суммарное число ответов всех страниц. Из 200 попыток 30 неудачны: доля ошибок составляет 15%. Если считать вместе с десятками тысяч запросов картинок, проблема формы почти исчезнет на общем графике, хотя для покупателей она останется существенной.
- Объём: сколько операций завершилось за выбранный интервал и какой тип действий учитывается.
- Результат: сколько операций выполнили установленное условие успеха, а сколько завершились ошибкой или тайм-аутом.
- Длительность: как распределяется ожидание для конкретного маршрута; успешные и неуспешные операции полезно рассматривать раздельно.
- Ограничение ресурса: очередь, занятые соединения, свободное место или другой показатель, который действительно связан с обработкой.
Не делайте идентификатор каждого посетителя или запроса меткой временного ряда. В рекомендациях Prometheus по инструментированию отдельно обсуждается стоимость множества комбинаций меток. Для общей метрики выбирайте ограниченные категории: шаблон маршрута, тип операции, класс результата. Подробности конкретного случая оставляйте в журналах и трассировках.
У панели должны быть подписаны окно, единицы измерения и источник данных. «Ошибок: 12» без периода мало что говорит. «12 из 80 завершённых отправок за последние пять минут» позволяет оценить масштаб. Отдельно проверяйте полноту: пропавшие измерения нельзя автоматически считать нулевыми ошибками.
Что даёт трассировка запроса
Трассировка становится особенно полезной, когда действие проходит несколько компонентов: веб-приложение, базу данных, кеш, очередь и внешний API. Каждая измеренная операция представлена участком трассы — span. Участки связаны контекстом, поэтому можно увидеть последовательность и вложенность работ.
Представим получение расчёта доставки. Общий запрос занял 2,8 секунды. Из них 70 мс ушло на подготовку, 2,6 секунды — на обращение к службе доставки, остальное — на обработку ответа. Такой разбор направляет проверку на зависимость и настройки ожидания. Он ещё не доказывает вину поставщика: задержка могла возникнуть в сети, очереди соединений или на стороне вашего клиента API.
Не складывайте все длительности без учёта структуры. Если два обращения выполнялись параллельно, их сумма может быть больше общего времени операции. Для диагностики важно понять, что задерживало завершение пользовательского действия, какие ожидания перекрывались и где отсутствует измеренный участок.
Трасса не появляется из одного заголовка с идентификатором. Нужны создание участков, передача контекста, экспорт и сохранение данных. При разрыве на одной интеграции часть пути останется неизвестной. Такой пробел следует назвать прямо, а не достраивать недостающую последовательность по совпадению времени.
Для небольшого сайта достаточно начать с одной важной операции и её главной зависимости. Если форма обрабатывается в одном приложении, хорошие структурированные логи и длительности этапов уже могут существенно упростить работу. Полную распределённую трассировку разумно добавлять там, где она отвечает на повторяющийся нерешённый вопрос.
Пример расследования: страницы открываются, заявки задерживаются
Рассмотрим условный сайт услуг. Главная страница доступна, но сотрудники замечают, что новые обращения приходят с задержкой. Внешняя HTTP-проверка страницы формы даёт сигнал о замедлении ответа. Это наблюдение за страницей: работу отправки и доставки заявки проверяют отдельно. Задача команды — определить, где задерживается действие, и восстановить ожидаемый результат без поспешного удаления очереди или повторной отправки всех заявок.
| Шаг | Наблюдение в учебном примере | Следующий вопрос |
|---|---|---|
| Уточнить внешний симптом | Проверяемый адрес отвечает медленнее начиная с 10:10 UTC | С каким действием связан этот адрес и что именно измерено? |
| Посмотреть метрики операции | Приём обращений успешен, но доля тайм-аутов передачи выросла | Данные приняты и сохранены или потеряны до записи? |
| Найти связанные логи | Есть запись о создании заявки и отдельная ошибка доставки | Где находится задача и предусмотрен ли безопасный повтор? |
| Проверить трассу | Главное ожидание приходится на соединение с CRM | Проблема во внешнем ответе, сети или пуле соединений? |
| Сопоставить изменения | Перед началом симптомов менялась настройка клиента интеграции | Воспроизводится ли зависимость на контролируемом тесте? |
| Подтвердить восстановление | Новые обращения проходят, накопленные задачи обработаны | Нет ли пропусков, дублей и повторного роста задержки? |
Время релиза и начало сбоя рядом — полезная гипотеза, но не доказательство причины. Проверьте различия конфигурации, фактические ошибки соединения и поведение после согласованного изменения. Если одновременно снизилась нагрузка или восстановилась внешняя система, один успешный тест после отката недостаточен для окончательного вывода.
Записывайте, что установлено, а что пока предполагается. Например: «Приём обращений подтверждён журналом приложения; доставка части заявок не подтверждена; ожидание соединения превышает лимит». Такая формулировка точнее, чем «всё сломалось из-за CRM», и помогает распределить проверку между ответственными.
После восстановления проверьте пользовательский результат, а не только отсутствие новых ошибок. Форма должна принимать данные, обращение — сохраняться и доходить до нужного этапа обработки. Отдельно разберите накопившиеся задачи: состояние текущего трафика и последствия уже случившегося отказа — разные части работы.
Как собрать минимальную схему наблюдаемости сайта
Начните с одного процесса, по которому можно провести расследование от внешнего симптома до внутреннего результата. Для сайта услуг это приём обращения, для магазина — создание заказа, для личного кабинета — получение пользователем нужной информации. Не требуется сразу подключать все компоненты компании.
- Опишите результат. Зафиксируйте, что означает успешное действие и в каком месте оно подтверждается. Ответ формы, сохранённая заявка и доставка в CRM могут быть тремя разными этапами.
- Нарисуйте короткий путь обработки. Перечислите вход, приложение, обязательные зависимости и фоновые шаги. Для каждого укажите владельца и доступные данные.
- Согласуйте общие поля. Используйте понятные имена окружения, сервиса и версии, единый подход к времени и идентификаторам. Это позволит сопоставлять события без ручной догадки.
- Настройте переходы. Сохраните поиски по маршруту и времени, ссылку на нужную панель, фильтр ошибок и способ найти связанную трассу при её наличии.
- Проведите учебное расследование. На согласованном стенде создайте известный отказ и проверьте, хватает ли собранного контекста для объяснения результата.
Договоритесь, кто поддерживает эту схему после изменений. Если команда переименовала маршрут, перенесла обработку в очередь или заменила интеграцию, прежние графики могут продолжать выглядеть исправными, но больше не отражать полный путь. Проверка наблюдаемости должна входить в приёмку значимых изменений процесса.
Для каждой панели полезно записать одно ожидаемое решение. Например: «Если растут ошибки создания заявки, проверить этот журнал и состояние этой зависимости». Если по показателю нельзя выбрать действие или уточнить гипотезу, возможно, его место в подробной диагностике, а не на первом экране дежурного.
Что достаточно небольшому сайту, а что нужно сложному приложению
Объём настройки зависит от сложности пути и доступных прав. На обычном хостинге владелец иногда не может поставить отдельный агент или получить системные метрики. Это не означает, что расследование невозможно: начните с доступных журналов, внешнего контроля и записи результатов операций в самом приложении.
| Проект | Разумная первая очередь | Когда расширять |
|---|---|---|
| Сайт услуг с одной формой | Внешняя проверка, журналы ошибок и понятные события приёма и доставки обращения | Когда отказы повторяются, но имеющихся записей недостаточно для локализации |
| Магазин с несколькими интеграциями | Показатели ключевых операций, журналы по этапам, идентификаторы и трассировка важных зависимостей | Когда нужно объяснять задержки отдельных вариантов заказа или фоновых процессов |
| Приложение из нескольких сервисов | Общие правила контекста, централизованный поиск, распределённые трассы и контроль доставки телеметрии | По конкретным пробелам покрытия и стоимости расследований |
Это ориентир для планирования, а не обязательный комплект программ. Две аккуратно связанные системы могут быть полезнее пяти разрозненных. Проверять выбор стоит на знакомом инциденте: найдёт ли другой специалист нужную операцию и сможет ли объяснить, каких данных ему не хватает?
Как ограничить объём данных и сохранить нужные подробности
Стоимость наблюдаемости складывается из хранения, передачи, обработки и времени команды. Установите сроки хранения для разных сигналов, исходя из реальных задач. Если обращения о проблемах обычно приходят через несколько дней, история, исчезающая раньше, не поможет расследовать эти случаи. Универсального срока для всех сайтов нет.
Для трассировок можно применять выборочное сохранение. Документация OpenTelemetry по sampling различает решение в начале обработки и отбор с учётом уже собранных участков. При настройке важно понимать, какие запросы могли не попасть в хранилище. Отсутствие трассы по конкретному идентификатору не подтверждает, что операция не происходила.
Не переносите долю ошибок из специально отобранных неудачных трасс на весь трафик. Если сохраняются преимущественно ошибки и медленные операции, такая коллекция подходит для поиска примеров, но не является полной картиной частоты проблем. Для масштаба используйте соответствующие счётчики с ясными правилами учёта.
Доступ и состав журналов проектируйте заранее. OWASP рекомендует исключать из логов секреты и защищать сами журналы. Пароли, токены и содержимое авторизационных заголовков не нужны для объяснения технического результата. Определите разрешённые поля, маскирование, роли доступа и удаление данных; не открывайте диагностические файлы в публичной папке сайта.
При временном увеличении детализации задайте срок возврата обычного режима и проверьте результат на безопасном примере. Отладочная настройка, оставленная после ночного инцидента, способна незаметно изменить объём хранения и состав записываемой информации.
Почему нужно проверять поступление самих данных
Между приложением и панелью есть отдельный путь: создание события, буферизация, передача, обработка и сохранение. Ошибка на этом пути может скрыть рабочие события или доставить их с задержкой. Поэтому при пустом графике сначала выясните, когда поступило последнее измерение и продолжает ли работать сбор.
Например, OpenTelemetry Collector публикует собственную телеметрию для наблюдения за очередями, приёмом и экспортом. Неудачная отправка ещё не всегда означает потерю: данные могут ожидать повторной попытки. Для расследования нужно отличать временную задержку, исчерпание буфера и окончательное отбрасывание записей.
В рабочей памятке укажите, как проверить свежесть каждого источника. Храните отдельно время события и, когда это необходимо, время его поступления. Иначе запись, дошедшая позже, может создать ложное впечатление нового сбоя. При сравнении машин учитывайте синхронизацию часов и не считайте порядок строк в общей выдаче безусловным порядком выполнения.
Как принять настройку и понять, что она полезна
Попросите специалиста, который не настраивал систему, разобрать согласованный учебный случай по короткой инструкции. Заранее известная причина позволяет проверить, где данных достаточно, а где приходится угадывать. Испытание проводите на стенде или в отдельно согласованном безопасном сценарии.
- Внешний симптом связан с конкретным адресом, временем и ожидаемым результатом.
- На панели видны объём операций, ошибки и длительность за подходящий интервал.
- Из журнала понятны операция, окружение, версия и результат обработки.
- Для нужного запроса можно найти связанные события или явно установить границу доступного контекста.
- Трассировка, если она используется, показывает важные зависимости и не подменяет отсутствующие участки догадками.
- Свежесть данных, правила выборки и срок хранения известны тому, кто расследует инцидент.
- После восстановления проверяется конечное действие пользователя, включая отложенную обработку.
По итогам составьте небольшой список пробелов с владельцами. Формулируйте их предметно: «не видна длительность ожидания соединения» или «не связываются приём заявки и фоновая доставка». Это удобнее для следующего улучшения, чем задача «сделать наблюдаемость лучше» без критерия готовности.
Вопросы о логах, метриках и трассировках
Можно ли обойтись только логами?
Для некоторых небольших проектов — да, если журналы содержат нужный контекст, доступны при сбое и позволяют проверить результат операции. По мере роста нагрузки становится важнее быстро оценивать масштаб и находить характерные примеры. Тогда добавляют метрики и трассировки для конкретных нерешённых задач.
Почему серверные показатели нормальные, а сайт работает плохо?
Загрузка процессора и память описывают только часть состояния. Ошибка настройки, ожидание внешней системы или неверный результат приложения могут возникнуть без перегрузки. Сопоставляйте ресурсы с наблюдаемым пользовательским действием и данными именно его обработки.
OpenTelemetry сам хранит всю историю?
В описанной схеме инструменты OpenTelemetry создают, собирают и передают телеметрию. Хранилище и интерфейс поиска выбираются отдельно. До внедрения определите, куда попадут данные, кто получит доступ, сколько они будут храниться и как команда найдёт нужную операцию.
Нужен ли внешний мониторинг, если есть внутренняя диагностика?
Он добавляет отдельное наблюдение выбранного адреса или сценария снаружи. Внутренние данные объясняют обработку, но сами могут стать недоступными вместе с приложением. Сопоставление этих уровней помогает понять, виден ли отказ пользователю и в какой части пути искать причину.
Подключите SiteGuard для внешнего HTTP-контроля доступности важных страниц. Для поиска внутренних причин сбоя используйте логи, метрики и трассировки приложения.