Метрика, лог и трейс отвечают на разные вопросы
Их принято называть тремя столпами и собирать все три сразу. Полезнее понимать, на какой вопрос отвечает каждый — иначе платишь за хранение трёх копий одного.
Метрики, логи и трейсы часто описывают как три обязательных источника. Из этого делают вывод, что нужно собирать всё и в максимальной детализации, а потом удивляются счёту за хранение.
Полезнее держать в голове, на какой вопрос отвечает каждый из трёх.
Метрика: сколько и как меняется
Число во времени. Отвечает на вопросы вида «выросло или нет», «сколько сейчас», «когда началось».
Дешёвая в хранении: агрегат занимает мало и хорошо сжимается, поэтому метрики можно держать годами.
Не отвечает на вопрос «почему». В метрике нет отдельного случая — только распределение.
Лог: что именно произошло в одном случае
Запись о событии. Отвечает на «что случилось у этого пользователя в это время», «какая была ошибка», «с какими параметрами вызвали».
Дорогая в хранении: объём растёт с трафиком, а не с числом показателей. Именно логи обычно съедают бюджет.
Не отвечает на вопрос «нормально ли это». По одной записи нельзя понять, редкость это или обыденность.
Трейс: где ушло время
Путь одного запроса через компоненты с временем на каждом шаге. Отвечает на «какой участок медленный».
Самая дорогая по объёму на единицу пользы, поэтому почти всегда собирается выборочно.
Не отвечает на вопросы про частоту и про содержание — только про структуру задержки.
Как это выглядит на практике
Метрика говорит: с трёх часов дня выросло время отрисовки в верхнем процентиле. Трейс говорит: время уходит на один запрос к внешнему сервису. Лог говорит: этот запрос возвращает ошибку с конкретным текстом, и повторяется он трижды из-за встроенных попыток.
Три вопроса, три источника, один ответ. Ни один из трёх по отдельности этого ответа не даёт.
Почему не надо собирать всё максимально подробно
Потому что стоимость наблюдаемости — это в основном хранение, и оно распределено неравномерно.
Разумная стратегия обычно такая: метрики — надолго и по всему, потому что дешёвы и нужны для истории; логи — коротко и по важному, с отдельным более длинным сроком для ошибок; трейсы — выборочно, с повышением доли при разборе инцидента.
Обратная стратегия — всё подробно и на год — даёт счёт, который через квартал приводит к решению «давайте выключим мониторинг».
Что это значит для фронтенда
Наблюдение в браузере имеет ту же структуру. Метрики загрузки и отзывчивости — постоянно и по всем. Ошибки скриптов с контекстом — это логи, и они нужны с деталями. Трассировка пути пользователя — выборочно.
Разница с серверной стороной в том, что данные приезжают от недоверенного клиента и по каналу, который сам может быть проблемой. Отсюда практическое следствие: сбор с фронтенда обязан быть дешёвым для страницы, иначе он испортит те самые метрики, которые собирает.
Главное, что даёт свой стек
Возможность настроить сроки хранения по каждому из трёх независимо. В тарифах внешних сервисов это обычно один общий срок — и он определяется самым дорогим источником.