Логи, метрики и трассы: чем они отличаются и что когда нужно

MAATRIX

Рано или поздно в любой растущей инфраструктуре наступает момент, когда «просто смотреть логи» перестаёт работать: сервис падает раз в сутки без видимой причины, запрос иногда выполняется секунду, а иногда десять, и непонятно, с чего начинать разбор. Это почти всегда сигнал, что пора разделить три разных инструмента — логи, метрики и трассировку (трассы) — вместо того чтобы пытаться получить из одного из них ответы, для которых он не предназначен. Разберём, чем они принципиально отличаются, на какой вопрос отвечает каждый и как они работают вместе на практике.

Логи: что именно произошло

Лог — это детальная текстовая запись о конкретном событии, произошедшем в системе, с меткой времени. Каждая строка — отдельный факт: пользователь с таким-то ID выполнил вход, запрос к базе завершился с такой-то ошибкой, воркер получил задачу из очереди. Логи пишутся в хронологическом порядке и обычно выглядят примерно так:

2026-08-29T14:32:07.412Z [ERROR] payment-service: failed to charge card, gateway_timeout after 30000ms, order_id=48213, user_id=9921
2026-08-29T14:32:07.418Z [INFO]  payment-service: retry scheduled, attempt=2, order_id=48213
2026-08-29T14:32:09.883Z [ERROR] payment-service: retry failed, connection refused, order_id=48213

Ключевое свойство лога — он даёт богатый контекст об одном конкретном событии: какие именно параметры были переданы, какой именно текст ошибки вернул внешний сервис, какой ID заказа затронут. Если вопрос звучит как «что именно случилось с заказом 48213 в 14:32» — ответ почти всегда в логах, и нигде больше. Ни метрика, ни трасса не расскажут вам текст сообщения об ошибке от платёжного шлюза.

Слабое место логов — они плохо подходят для быстрого понимания общей картины за период. Если за час сервис записал 40 тысяч строк лога, вручную их не просмотреть, а даже агрегированный поиск по ключевым словам (grep ERROR) даёт лишь список инцидентов, но не показывает тренд: становится ли хуже, сколько именно процентов запросов ошибаются, растёт ли доля ошибок во времени. Для этого нужен другой инструмент. Подробнее о том, как читать логи и находить в них причину конкретного сбоя, — в статье как читать логи и находить причину сбоя.

Метрики: как обстоят дела прямо сейчас и в динамике

Метрика — это число, которое измеряется и агрегируется регулярно, через равные промежутки времени: загрузка CPU каждые 15 секунд, число запросов в секунду каждую минуту, процент использования памяти, количество ошибок 5xx за последнюю минуту. В отличие от лога, метрика не хранит контекст конкретного события — она хранит только числовой ряд во времени:

timestamp                cpu_percent  requests_per_sec  errors_5xx_per_min
2026-08-29T14:30:00Z      42.1         318                2
2026-08-29T14:31:00Z      44.7         325                3
2026-08-29T14:32:00Z      71.3         290                47
2026-08-29T14:33:00Z      68.9         301                52

Метрики — то, на чём строятся графики и алерты. Если вопрос звучит как «как сейчас обстоят дела в целом» или «растёт ли нагрузка на сервер в последние две недели» — это метрики, и только они дают возможность увидеть тренд на большом окне времени без необходимости читать тысячи отдельных событий. Именно поэтому важность отслеживания именно тренда, а не разового значения, разобрана в статье три сигнала, по которым видно проблему до падения: метрика памяти, которая медленно ползёт вверх на протяжении дней, видна на графике за секунды, а через логи её пришлось бы вычислять вручную.

Обратная сторона метрик — они обезличены. Метрика errors_5xx_per_min = 52 говорит, что что-то не так, но не говорит, у каких именно пользователей, с какими параметрами и по какой конкретно причине. Метрика ничего не знает про заказ 48213 — она знает только агрегированное число ошибок за минуту. Типичный стек для сбора и визуализации метрик на сервере — Prometheus как хранилище временных рядов и Grafana как слой дашбордов и алертов; их связка разобрана в статье Prometheus и Grafana: связка, настройка.

Трассы: где именно в цепочке запроса тратится время

Трасса (трейс, distributed trace) — это хронология прохождения одного конкретного запроса через несколько компонентов системы. Если у вас монолит на одном сервере, трассировка почти не нужна — весь путь запроса виден в одном логе. Но как только появляется несколько взаимодействующих сервисов — фронтенд обращается к API, API — к сервису авторизации, тот — к базе данных, а затем ещё к внешнему платёжному шлюзу — становится непонятно, на каком именно шаге запрос, который выполнился за 4 секунды вместо ожидаемых 200 мс, потерял эти секунды.

Трасса решает именно эту задачу: она разбивает один запрос на цепочку «спанов» (spans), каждый из которых — это время, проведённое в одном конкретном компоненте, с указанием, кто кого вызвал:

trace_id=7f3a91: POST /api/checkout — 4128ms total
├─ span: api-gateway routing            —   12ms
├─ span: auth-service verify_token      —   45ms
├─ span: order-service create_order     —   89ms
│  └─ span: postgres INSERT order       —   34ms
├─ span: payment-service charge         — 3920ms  ← вот где потеряно время
│  └─ span: external gateway call       — 3890ms
└─ span: notification-service enqueue   —   18ms

Из этой трассы сразу видно: проблема не в вашем коде и не в базе данных — 3890 мс из 4128 потрачены на вызов внешнего платёжного шлюза. Без трассировки эту цепочку пришлось бы восстанавливать вручную по логам пяти разных сервисов, сверяя метки времени и ID запроса, что медленно и подвержено ошибкам, если ID запроса вообще прокидывается между сервисами. Один из самых распространённых инструментов для такой трассировки — Jaeger; его установка и практическая настройка подробно разобраны в статье Jaeger: трассировка запросов, настройка.

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

Наглядное сравнение трёх столпов observability

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

Как три инструмента дополняют друг друга на практике

Реальный сценарий диагностики почти всегда идёт в одном и том же порядке — не потому что так «принято», а потому что каждый следующий шаг сужает область поиска, которую предыдущий инструмент оставил слишком широкой.

Шаг 1. Метрика показывает аномалию. Алерт в Grafana срабатывает: p95-задержка эндпоинта /api/checkout выросла с обычных 200 мс до 4 секунд за последние 10 минут, при этом трафик не изменился. Это ровно тот тип сигнала, который разобран в статье про три сигнала проблемы, — рост задержки при стабильном трафике почти никогда не бывает случайностью. Но метрика говорит только «что-то не так», не говоря, в каком именно компоненте.

Шаг 2. Трассировка находит конкретный этап. Открываем несколько трасс за последние 10 минут для эндпоинта /api/checkout в Jaeger и видим общую закономерность: во всех медленных трассах узкое место — не база данных и не собственный код, а спан external gateway call внутри payment-service. Теперь область поиска сузилась с «всей системы» до «одного конкретного внешнего вызова в одном конкретном сервисе».

Шаг 3. Логи этого компонента дают детальный контекст. Идём в логи payment-service за то же время и видим то, что не может показать ни метрика, ни трасса — конкретный текст ошибки:

2026-08-29T14:32:07.412Z [ERROR] payment-service: gateway_timeout, endpoint=https://payments.example-gateway.com/v2/charge, response_code=none, retries_exhausted=true
2026-08-29T14:35:12.009Z [WARN]  payment-service: gateway TLS handshake slow, 2800ms, possible upstream cert rotation

Теперь у вас есть полная картина: внешний платёжный шлюз начал отвечать медленно (возможно, из-за ротации TLS-сертификата на их стороне), это видно по логам конкретного сервиса, найденного через трассу, обнаруженную по аномалии в метрике. Ни один из трёх инструментов по отдельности не довёл бы вас от «непонятно, что происходит» до «конкретная причина» за разумное время — метрика без трассы не указала бы на компонент, трасса без логов не дала бы текст ошибки, а логи без метрики и трассы потребовали бы вручную перелопатить логи всех сервисов в поисках нужного временного окна.

Практический план внедрения для небольшой инфраструктуры

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

1. Начните с базовых логов. Централизованный сбор логов приложения и системных логов в одно место, где их можно искать — это минимум, без которого разбирать инциденты приходится через ssh на каждый сервер по очереди. Даже простое решение вроде Grafana Loki или Graylog закрывает большую часть повседневных вопросов «что случилось».

1. Добавьте ключевые метрики. Не нужно с первого дня собирать сотни показателей — начните с 5-10 действительно важных: загрузка CPU, память, место на диске, задержка ответа основных эндпоинтов, доля ошибок 5xx. Prometheus + Grafana с несколькими алертами по порогу и по тренду закрывают вопрос «как обстоят дела» и дают время среагировать до того, как что-то упадёт.

1. Добавляйте трассировку по мере роста реальной сложности. Пока у вас один сервис, обращающийся к одной базе данных, трассировка почти ничего не добавляет к тому, что уже видно в логах и метриках, — весь путь запроса умещается в паре строк лога. Внедрять её имеет смысл в тот момент, когда появляется реальная цепочка из нескольких взаимодействующих компонентов (несколько микросервисов, очередь, внешние API), и диагностика «где именно тормозит» логами и метриками уже перестаёт получаться за разумное время. На этом этапе внедрение вроде Jaeger окупается почти сразу же на первом сложном инциденте.

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

Где физически размещать стек наблюдаемости

Логи, метрики (особенно с длительным ретеншеном) и трейсы съедают заметный объём диска и оперативной памяти, и это стоит учитывать при выборе сервера под задачу. Если Prometheus, Grafana, Loki или Jaeger крутятся на том же сервере, что и продакшен-нагрузка, есть риск, что именно в момент инцидента, когда система и так под давлением, стек наблюдаемости начнёт конкурировать с приложением за CPU и I/O — и это худший момент, чтобы это выяснить. Практичный подход для небольшой команды — вынести весь стек наблюдаемости на отдельный VPS: он не обязан быть мощным (2-4 ГБ RAM обычно достаточно для старта с логами и базовыми метриками), но он должен быть физически отделён от того, что мониторит, чтобы падение основного сервера не забирало с собой и возможность понять, что именно произошло.

Частые вопросы