Метрики — это числовые показатели, агрегированные по времени: загрузка CPU, количество запросов в секунду, доля ошибок. Логи — текстовые или структурированные записи о конкретных событиях с отметкой времени и уровнем критичности. Трейсы — цепочки вызовов, показывающие путь одного пользовательского запроса через все сервисы и время, потраченное на каждом участке. Метрика говорит «что-то сломалось», лог объясняет «что именно», трейс показывает «где в цепочке».
Три сигнала и три разных вопроса
Метрики дёшевы в хранении, потому что данные схлопываются в числовые ряды: вместо миллиона событий хранится одно значение за интервал. Отсюда их сильная сторона — пороги и алертинг. Статические пороги («нагрузка выше 90%») работают на предсказуемых системах; динамические, построенные на базовой линии поведения, лучше ловят аномалии там, где нагрузка меняется по расписанию. К метрикам привязывают операционные показатели, качественные KPI и расчёт доступности сервиса.
Логи не агрегируются — в этом их ценность и их проблема. Запись содержит стек ошибки, идентификатор пользователя, параметры запроса. Категоризация по уровням (DEBUG, INFO, WARN, ERROR, FATAL) позволяет отсеять шум, а структурированный формат JSON — искать по полям, а не регулярными выражениями по тексту. Практически всегда логов на порядки больше, чем метрик, и растут они быстрее нагрузки.
Трейсы связывают разрозненные события общим trace ID. Каждый участок работы — спан — фиксирует начало, конец и родителя. Так становится видно, что из 800 мс ответа 700 ушло на один запрос к базе, а не на «медленный бэкенд вообще». В монолите трейсинг даёт меньше пользы; в микросервисах или при интеграциях с внешними API он часто оказывается единственным способом найти узкое место бизнес-операции.
Сравнение по ключевым параметрам
| Параметр | Метрики | Логи | Трейсы |
|---|---|---|---|
| Тип данных | Числовой временной ряд | Событие с текстом и полями | Дерево спанов с trace ID |
| Отвечает на вопрос | Есть ли проблема и насколько она масштабна | Что именно произошло в конкретный момент | На каком сервисе и вызове теряется время |
| Агрегация | Да, по интервалу (обычно 10–60 с) | Нет, каждая запись хранится отдельно | Частичная, через семплирование |
| Объём хранения | Наименьший | Наибольший | Средний, зависит от процента семплирования |
| Типичный срок хранения (ориентир) | Месяцы и годы | Дни и недели | Дни |
| Основной инструмент работы | Пороги, уведомления, дашборды | Поиск и фильтрация по полям | Диаграмма спанов, waterfall |
| Риск роста стоимости | Высокая кардинальность меток | Избыточный уровень логирования | Трассировка 100% трафика |
Разделение условное: одни и те же события можно превратить в метрику через подсчёт, а из трейса извлечь лог. Но смешивать источники в одном интерфейсе выгоднее, чем держать три отдельные системы — иначе при инциденте инженер вручную сопоставляет время в трёх вкладках. По этой причине три типа данных всё чаще собирают вместе, дополняя картой хостов с фильтрацией и группировкой по тегам; так устроена, например, платформа наблюдаемости ит-инфраструктуры, где объектами мониторинга выступают Kubernetes, Docker, виртуальные машины, базы данных, сетевое и серверное оборудование, рабочие станции и системы на базе «1С».
Как пользоваться связкой на практике
Рабочий сценарий разбора инцидента выглядит так: метрика доступности пробивает порог и запускает уведомление → трейс показывает, какой шаг цепочки вырос по времени → лог этого сервиса даёт текст исключения. Обратный порядок тоже встречается: заявка от пользователя приводит к логу, а метрика подтверждает, единичный это случай или массовый.
Чтобы связка работала, нужен сквозной идентификатор. Если trace ID не попадает в строку лога, соединять придётся по времени, а это ненадёжно при высокой нагрузке. Поддержка нескольких форматов логирования на стороне системы сбора избавляет от переписывания приложений под единый стандарт — но приводить критичные поля к общему виду всё равно приходится.
Типичные ошибки
- Заменять метрики логами. Считать долю ошибок полнотекстовым поиском по логам — значит нагружать хранилище и получать отчёт с задержкой; для алертинга нужен предварительно посчитанный ряд.
- Добавлять в метки метрик идентификаторы пользователей или запросов. Кардинальность взрывается, база временных рядов деградирует, дашборды перестают открываться.
- Держать уровень DEBUG в промышленной среде. Полезные ERROR тонут в шуме, диск заканчивается в самый неподходящий момент, а retention приходится резать до суток.
- Трассировать весь трафик без семплирования. Накладные расходы на инструментирование начинают влиять на время ответа самого сервиса, а хранилище растёт быстрее, чем даёт пользы.
- Настраивать пороги «на глаз» один раз. Статические значения без пересмотра дают ложные срабатывания при сезонной нагрузке, дежурная смена привыкает игнорировать уведомления и пропускает настоящую аварию.
- Считать лицензии только по серверам. Схемы лицензирования обычно привязаны к числу контролируемых хостов и АРМ, и забытые рабочие станции меняют итоговый расчёт.