Одной метки user_id в метрике и 90 дней хранения лишних логов хватает, чтобы observability начала работать против команды. Именно так и рождается архитектурный долг: сначала инженеры добавляют больше сигналов после инцидента, а потом получают шумные алерты, противоречивые дашборды, вопросы от безопасности и неприятный счет в конце месяца.
Как пишет Habr / Менеджмент, проблема редко начинается с плохого решения. Обычно все выглядит разумно: во время сбоя не хватило данных, команда добавила поле в лог, новую метку в метрику, еще один дашборд или алерт «на всякий случай». По отдельности это похоже на заботу о надежности. В сумме получается не observability, а архитектурный долг, который растет тихо и долго остается без владельца.
Ключевой тезис материала простой: телеметрию в компаниях часто воспринимают как побочный выхлоп приложения, а не как часть архитектуры. С базой данных, API-контрактом, кэшем или очередью обычно работают дисциплинированно: изменения обсуждают, проверяют, прогоняют через ревью. С логами, метриками и трассировками такого режима часто нет. Между тем они тоже потребляют ресурсы: процессорное время, память, сеть, диск, а еще внимание инженеров, время платформенной команды и бюджет. Причем накладные расходы часто размазываются по инфраструктуре так, что до поры не выглядят проблемой.
Именно поэтому счет за телеметрию автор статьи называет самым честным архитектурным ревью. Он показывает то, что команда долго не хотела замечать: лишние ретраи, слишком подробные health-check’и, размножающиеся отладочные логи, избыточные метки и сигналы без понятного сценария использования. Обратная связь здесь болезненно длинная. Разработчик добавляет поле сегодня, ревьюер видит в нем полезный контекст, через несколько недель платформенная команда замечает всплеск ingestion, позже финансы видят выросший счет, а еще позже безопасность обнаруживает, что в хранилище метрик или логов уехали клиентские идентификаторы. Человек, который это добавлял, к тому моменту может уже перейти в другую команду.
Где observability ломает экономику
Самая показательная часть разбора касается кардинальности метрик. Для базы временных рядов метрика — это не просто имя, а комбинация имени и набора меток. Пока метки описывают стабильные операционные измерения вроде service, env, region, status_code или route_template, система живет нормально: данные можно группировать, сравнивать и использовать в алертах. Но стоит добавить в такую метрику user_id, и инженерная логика быстро сталкивается с физикой хранилища и прайсингом вендора. Каждый новый пользователь создает новый временной ряд, а дальше начинается декартово произведение значений по всем остальным меткам. Для команды это выглядит как чуть более богатый контекст. Для платформы — как взрыв числа активных time series. Для безопасности — как новый канал утечки чувствительных данных.
С логами, по версии автора, ситуация еще более психологическая. Метрики обычно раздуваются из-за кардинальности, а логи — из-за страха. И страх этот рационален: одна пропущенная строка во время ночного инцидента действительно может стоить нескольких часов диагностики. Поэтому после каждого тяжелого разбора команды почти рефлекторно включают режим «логируем все». Проблема в том, что лог без конкретного вопроса, на который он должен отвечать, быстро превращается в мусорный контейнер с таймстампами. Полезный лог объясняет переход состояния, отказ, обходной путь, пересечение системной границы или принятое приложением решение. Все остальное часто просто индексируется, хранится и мешает находить действительно важное.
Отдельно статья попадает в нерв тех компаний, где compliance смешивают с мониторингом. Если аудитор требует хранить записи 90 дней, это еще не значит, что каждая отладочная строка должна три месяца лежать в горячем поисковом индексе. Хранение и индексирование — не одно и то же решение, но на практике их часто склеивают. Отсюда и знакомая картина: observability-платформа превращается в дорогой архив, где ищут редко, платят много, а полезный сигнал тонет в историческом шуме.
Почему проблема не в Datadog и не в Grafana
Самая сильная мысль текста в том, что реальная единица телеметрии — не гигабайт, не спан и не активный временной ряд, а решение, которое этот сигнал помогает принять. Если метрика запускает алерт и меняет следующий шаг дежурного инженера, она окупает свое существование. Если лог объясняет важный переход состояния, он полезен. Если трассировка помогает разобрать путь, который заметен пользователю, в ней есть смысл. Но если сигнал когда-то добавили «для глубокой видимости», на него не завязан ни один алерт, под него нет runbook, а живет он только на одном заброшенном дашборде, это уже не observability, а архитектурный долг в чистом виде.
В статье для иллюстрации приводится пример со Spark. Метрика, которая считает сбои задач и размечена по типу ошибки, стадии и приложению, может быть по-настоящему рабочим инструментом: по ней дежурный быстро понимает, речь о нехватке памяти, потере executor’а, проблеме с shuffle или тайм-ауте. А вот перегруженный heartbeat executor’а с executor_id, application_name, user_id и случайным идентификатором запуска дает много «видимости» только на бумаге. На практике он плодит ряды, не имеет сценария реакции и продолжает жить исключительно потому, что однажды кому-то было тревожно.
Для русскоязычной IT-аудитории из этого следует довольно приземленный вывод. Observability больше нельзя оставлять на уровне локальных решений отдельных сервисных команд. Если у телеметрии нет владельца, правил добавления полей и меток, ограничений на кардинальность, политики хранения и права сказать «нет», компания почти гарантированно будет платить дважды: сначала за сбор лишних данных, потом за уборку после них. Это касается не только больших энтерпрайзов с сотнями сервисов. Как только у стартапа появляются несколько продуктовых команд, единый стек мониторинга и требования безопасности, хаос в телеметрии начинает масштабироваться быстрее самого продукта.
На фоне общего увлечения observability-платформами материал звучит как полезное напоминание: проблема редко в том, какой агент поставить и куда отправлять трейсы. Главный вопрос гораздо менее глянцевый — кто в компании отвечает за то, чтобы каждый новый сигнал оправдывал свою стоимость. Пока на него нет внятного ответа, архитектурный долг будет расти даже в тех командах, которые искренне пытаются сделать систему надежнее.