Чем логи отличаются от метрик и трейсов
Логи — это записи о событиях с текстом и меткой времени: что именно произошло в конкретный момент. Метрики — числовые значения, агрегированные по времени: сколько запросов, какая загрузка процессора, какой процент ошибок. Трейсы — путь одного запроса через все сервисы, разбитый на отрезки (спаны) с длительностью каждого шага. Метрика говорит, что стало плохо, трейс показывает, где именно, лог объясняет почему.
Краткое содержимое статьи:
Что фиксирует каждый из трёх сигналов
Метрика — это счётчик, датчик или гистограмма. Она дешёвая в хранении, потому что данные схлопываются в агрегаты: за минуту вместо миллиона запросов остаётся несколько чисел. Отсюда и главное ограничение: по метрике нельзя восстановить отдельный запрос. Зато по ней удобно строить пороги — статические (диск заполнен больше 90%) и динамические, когда система сама определяет нормальный коридор значений по историческому поведению.
Лог хранит подробности: стек ошибки, параметры вызова, идентификатор пользователя. Формат бывает разный — plain text, syslog, JSON; структурированный лог удобнее, так как поля индексируются и по ним работает фильтрация. Логи обычно категоризуют по уровням критичности (DEBUG, INFO, WARN, ERROR, FATAL), и это первый фильтр при разборе инцидента. Платят за детальность объёмом: логи растут быстрее всех остальных сигналов.
Трейс появляется там, где запрос проходит через несколько сервисов. У него есть сквозной идентификатор (trace ID), который передаётся между вызовами, а каждый участок пути становится спаном с временем начала, длительностью и статусом. Именно трассировка отвечает на вопрос «на каком шаге бизнес-операции ушло 4 секунды из 5» — по метрикам это видно лишь суммарно, а по логам приходится сшивать записи вручную.
| Признак | Метрики | Логи | Трейсы |
|---|---|---|---|
| Единица данных | число за интервал | событие с текстом | спан внутри запроса |
| Основной вопрос | что и насколько | почему | где именно |
| Объём хранения | минимальный | максимальный | средний, часто с семплированием |
| Типичное применение | пороги, KPI, доступность сервиса | разбор ошибок, аудит | поиск узких мест в цепочке вызовов |
Как понять, какой сигнал нужен прямо сейчас
Практический порядок обычно такой: сработало уведомление по метрике → открывается трейс проблемного запроса → в спане с ошибкой ищется соответствующая запись в логе. Такой маршрут работает, когда все три источника собираются в одном месте и связаны идентификаторами. Если логи лежат в одной системе, метрики в другой, а трассировка вообще не внедрена, время на диагностику растёт в разы — приходится вручную сопоставлять временные метки.
Поэтому три сигнала редко используют по отдельности. Отечественные разработчики предлагают решения этого класса — например, платформа наблюдаемости ит-инфраструктуры объединяет мониторинг логов, метрик и трейсов в едином интерфейсе, а карта хостов показывает все объекты наблюдения сразу, с фильтрацией и группировкой по тегам и данными об агентах, логах и проблемах. Объектами могут быть Kubernetes, Docker, виртуальные машины, серверное и сетевое оборудование, базы данных, рабочие станции на Linux и Windows, системы на базе «1С». Подробнее можно узнать на сайте разработчика.
Что делать, если метрики в норме, а пользователи жалуются
Классическая ситуация: средняя длительность ответа выглядит приличной, ошибок по счётчикам нет, но часть клиентов не может завершить операцию. Средние значения маскируют хвосты — смотреть надо перцентили (95-й, 99-й), а не среднее. Дальше подключается трассировка: полный путь конкретного запроса покажет, на каком внешнем вызове или запросе к базе теряется время. Логи уровня WARN на этом же участке часто содержат причину — таймаут, повтор, деградацию соединения.
Обратный случай тоже встречается: логов много, ошибки видны, но неясен масштаб. Тогда из логов выводят метрику (количество событий определённого типа в минуту) и вешают на неё порог. Так качественные показатели переводятся в операционные, пригодные для алертинга и оценки доступности сервиса.
Вопросы и ответы
Можно ли обойтись одними логами?
В монолите на одном сервере — часто да, особенно если нагрузка предсказуема. Как только появляются несколько сервисов и контейнеров, поиск причины по логам превращается в перебор, и без метрик с трассировкой время реакции заметно растёт.
Зачем нужны трейсы, если есть APM-графики по каждому сервису?
Графики показывают состояние сервиса в целом, а трейс — конкретную цепочку вызовов с распределением времени по шагам. Узкое место бизнес-операции нередко находится не в самом медленном сервисе, а в количестве обращений к быстрому.
Логи и трейсы дублируют друг друга?
Нет: трейс отвечает за структуру и тайминг запроса, лог — за содержание события. Их связывают по trace ID, и тогда из спана можно сразу перейти к нужным записям, не листая весь поток логов.
An Engaging Blog Post
I AM BACK AGAIN
The content is really great
That was amazing