Observability для продуктовых команд: что дают логи, метрики и трейсы
Понятный разбор трёх столпов наблюдаемости и почему важна их комбинация - для технических собственников, которые хотят понять, за что они платят.
Я провёл этот разговор не меньше десятка раз. Основатель спрашивает, зачем инженерной команде добавлять ещё один инструмент - Datadog, Grafana, Honeycomb - поверх встроенных дашбордов облачного провайдера. «У нас уже есть логи», - говорит он. «Что это реально добавляет?»
Вопрос справедливый. Ответ не очевиден, пока вы не оказались в инциденте в 3 ночи и не пытались понять, почему функция медленная для одних пользователей, но не для других, имея только строки лога.
Три сигнала, не один
Observability на практике означает три вещи:
Логи - дискретные записи о событиях: «пользователь X запросил страницу Y в момент T, получил статус 200, потратил 340 мс». Самый знакомый сигнал. И самый сложный для агрегации. Если вы хотите узнать «сколько запросов упало за последний час, которые шли через платёжный сервис», вам нужно написать запрос, надеяться, что залогированы нужные поля, и ждать.
Метрики - числовые временные ряды: частота запросов, частота ошибок, перцентили задержек, глубины очередей. Дёшевы для хранения и быстры для запросов. Дашборды и алерты живут здесь. Компромисс: они агрегированы, поэтому вы видите, что задержка выросла в 14:32, но не какие конкретно запросы были затронуты и почему.
Трейсы следят за одним запросом через всю систему - от браузера до балансировщика нагрузки, до API-сервиса, до базы данных и обратно. Трейс показывает, где именно было потрачено время в распределённой цепи вызовов. Это то, что нужно, когда проблема - «чекаут медленный у 2% пользователей» и воспроизвести это локально невозможно.
Почему все три, не один
Каждый сигнал отвечает на разные вопросы. Логи говорят, что произошло в деталях. Метрики говорят, есть ли что-то не так прямо сейчас, в масштабе. Трейсы говорят, где проблема в конкретном пути через систему.
Без трейсов отладка распределённых систем - это угадывание. Без метрик вы узнаёте о проблемах от клиентов раньше, чем ваши дашборды их замечают. Без структурированных логов вы видите проблему, но не можете расследовать детали вокруг неё.
Что это реально стоит
У инструментов observability репутация дорогих. Эта репутация заработана, когда команды инструментируют всё с максимальной детализацией и направляют всё это вендору, который берёт за каждый гигабайт.
Практический подход: быть избирательным. Трейсируйте критические пути - флоу, которые работают с деньгами, аутентификацией и основными действиями продукта. Держите метрики на грубом уровне для большинства сервисов и детальными только там, где есть известные проблемы. Логируйте на уровне info в продакшне, не debug; добавляйте структурированные поля для осмысленной фильтрации (ID пользователя, ID запроса, уровень аккаунта), а не пишите абзацы текста.
Средний продукт с дисциплинированным инструментированием комфортно укладывается в $500-2000 в месяц. Я видел тот же продукт за $15 000 в месяц, потому что никто никогда не смотрел, что именно попадает в хранилище.
Управленческий вопрос
Правильный вопрос для технического собственника - не «какой инструмент observability выбрать», а «на какие вопросы мы должны уметь отвечать, когда что-то ломается, и насколько быстро?» Этот вопрос определяет требования к инструментированию, которые определяют выбор инструментов.
Если ответ - «нам нужно знать, что сервис упал, за две минуты и найти сломанный запрос за пятнадцать» - это формирует всю конфигурацию observability. Если ответ - «мы узнаём от пользователей и исправляем за день» - значит текущая ситуация это выбор, а не случайность, и нужно отдавать себе отчёт в том, от чего вы отказываетесь.