Самые интересные проблемы с телеметрией, с которыми мне приходилось сталкиваться, обычно начинались с инцидента, во время которого нам не хватило видимости. После разбора инцидента мы добавляли недостающее поле. Затем «на всякий случай» мы добавляли еще и смежные поля, потому что никто не хотел, чтобы в следующий раз зеркало погасло. На тот момент решение казалось разумным, и именно поэтому такой беспорядок так трудно заметить.

После достаточного количества инцидентов начинаешь носить с собой каждый шрам: отладочные логи от прошлых отказов, метки, добавленные ради одного расследования, дашборды, собранные во время выкатки, оповещения, созданные после одной тяжелой ночи. Никто из тех, кто все это добавлял, не думал, что создает проблему с observability. Им казалось, что они просто полируют зеркало для следующего дежурного инженера.

Потом растет счет, замедляются запросы, дашборды противоречат друг другу, а служба безопасности находит идентификаторы клиентов там, куда они вообще не должны были попасть. В конце концов вы очищаете несколько полей, сокращаете срок хранения, удаляете устаревшие дашборды и жестче применяете выборку. Так и складывается схема: согрешить, покаяться, повторить.

К телеметрии относятся как к выхлопу

Телеметрия часто начинается подобно выхлопу. Логи, метрики, трейсы, профили, события и записи аудита выходят из приложения «сбоку».

Схема базы данных, контракт API, очередь, кэш или новая внешняя зависимость обычно проходят проверку; продуктовые данные, чувствительные с точки зрения безопасности, тоже так или иначе проверяются. Изменения в телеметрии часто проскакивают как деталь реализации.

В продакшене телеметрия потребляет процессорное время, память, сетевые ресурсы и диск. Она требует внимания инженеров, времени на проверку безопасности и бюджета. Она может стать настолько тяжелой, что начинает мешать той нагрузке, которую должна отражать.

Ресурсы контейнера приложения рассчитывают под бизнес-логику, а затем к нему присоединяются агент, вспомогательный контейнер, коллектор, компонент журналирования или профилировщик. Возможно, накладные расходы на каждый под совсем небольшие, но в масштабе всего парка они могут стать огромными. Выхлоп уходит наружу и исчезает. Зеркало остается внутри и влияет на то, что вы видите.

Счет за телеметрию – это архитектурное ревью

Счет за телеметрию показывает, что ваша архитектура замела под ковер. Он вскрывает беспорядок, который казался безобидным, пока был размазан по сервисам: слишком много хитроумных компонентов, слишком много ретраев, проверок работоспособности, меток и отладочных логов, тихо размножающихся в фоне. В момент создания никто не ощущает ущерба, потому что контур обратной связи находится намного дальше по цепочке.

Сегодня разработчик добавляет поле, рецензент видит в нем полезный контекст, позднее платформенная команда замечает всплеск поступления данных, затем финансовая служба видит счет, а спустя месяцы служба безопасности обнаруживает случайную утечку данных во время проверки. К этому моменту разработчик, возможно, уже перешел в другую команду. А может быть, сменился владелец сервиса.

Так локальное решение превратилось в глобальные издержки. Тот, кто создает нагрузку для системы, не тот же человек, который несет издержки от очередей и задержек, а тот, кто понимает риск, может не иметь полномочий его заблокировать. Счет – единственное зеркало, которое никогда не лжет.

Кардинальность – это место, где контекст превращается в стоимость

Самое распространенное техническое объяснение стоимости телеметрии – кардинальность. В базе данных временных рядов метрика становится сочетанием своего имени и своих меток. Каждый уникальный набор меток создает отдельный временной ряд.

С этим все в порядке, пока метки имеют ограниченное множество значений: service, env, region, status_code, route_template, team, zone. Такие метки описывают стабильные эксплуатационные измерения. Они позволяют группировать, фильтровать, настраивать оповещения и сравнивать данные, не создавая безграничного хаоса.

Затем команда добавляет user_id в метрику, чтобы разобраться с проблемой горячей партиции. Через три недели платформенная команда видит взрывной рост числа активных временных рядов, руководителю команды сообщают об огромном счете, а служба безопасности понимает, что идентификаторы клиентов теперь оказались частью хранилища метрик.

На уровне хранения система видит декартово произведение всех возможных значений. Именно там сталкиваются инженерный замысел, физика базы данных, ценообразование вендора и пробелы во владении.

Логи – это тревога с временными метками

Метрики обычно разрастаются из-за кардинальности. Логи обычно разрастаются из-за страха. И этот страх рационален. Одна пропущенная строка лога во время инцидента может стоить нескольких часов. Поэтому команды усваивают простой урок и добавляют больше логов.

Журналирование без вопроса, на который оно должно отвечать, оставляет нас с выгрузками логов. Хороший лог объясняет переход состояния, пересечение границы, принятое решение, отказ, переход на резервный сценарий или сбой. Требования соответствия усугубляют ситуацию, когда срок хранения и индексирование начинают считать одним и тем же решением. Возможно, вам нужно хранить записи аудита девяносто дней. Но это не означает, что каждая отладочная строка должна три месяца лежать в горячем поисковом индексе.

Настоящая единица телеметрии – решение

Большинство обсуждений стоимости телеметрии начинается с объема: гигабайты в день, спаны в секунду, активные временные ряды, проиндексированные логи, срок хранения, кардинальность, нагрузка от запросов. Я полностью за то, чтобы отслеживать метрики, но настоящая единица измерения не в этом.

Настоящая единица телеметрии – решение. Какое решение поддерживает этот сигнал? Эта метрика управляет оповещением? Этот лог объясняет переход состояния? Эти трейсы помогают диагностировать путь, заметный пользователю? Эта запись аудита закрывает требование соответствия? Это поле помогает службе безопасности расследовать злоупотребления? Эта панель мониторинга влияет на решение о развертывании? Этот атрибут помогает сравнить нормальное и аномальное поведение системы?

Возьмем два сигнала Spark. Первый – spark_job_task_failures_total с метками failure_type, stage и application. По нему срабатывает оповещение. Когда значение резко растет, дежурный инженер может понять, из-за чего падают jobs: из-за ошибок нехватки памяти, сбоев при чтении shuffle-данных, потери executor’а или тайм-аутов. Этот сигнал меняет следующий шаг, а значит, заслуживает своего места.

Второй – метрика heartbeat’ов executor’а, перегруженная executor_id, application_name, user_id и сгенерированным идентификатором запуска, добавленная на лету ради более глубокой видимости. Вполне понятно. Никто не поступал глупо. Тем не менее у этой метрики нет ни оповещения, ни инструкции по реагированию, а есть только один заброшенный дашборд. Количество временных рядов продолжает множиться по всем executor’ам, пользователям, приложениям и запускам.

Именно поэтому я думаю, что в отношении телеметрии команды полностью забывают принцип YAGNI – «вам это не понадобится». Разница в том, что если забыть его в коде, появляется технический долг, а если забыть его в телеметрии, где-то далеко по цепочке появляется прибавка к счету.

Инструменты не решают, кто может сказать «нет»

Инструменты – удобный аргумент, потому что он кажется техническим. Datadog или Grafana. SaaS или самостоятельное развертывание. OpenTelemetry или агент поставщика. Но инструменты не отвечают на более сложный вопрос: когда следует добавлять телеметрию и кому разрешено сказать «нет»?

Кто утверждает метку с неограниченным множеством значений? Кто решает, место ли customer_id в метрике, атрибуте трассировки, структурированном логе или вообще нигде? Кто может заставить отладочные логи истекать через семь дней? Кто владеет дашбордом после инцидента, ради которого он был создан?

Это уже политическая работа. Без нее зеркало продолжает отражать всё подряд, независимо от того, нужно ли кому-то всё еще на это смотреть.

У владения есть адрес

Новое измерение метрики должно восприниматься скорее как миграция базы данных, чем как небольшая правка в журналировании. Это не значит, что платформенная команда должна проверять каждый пулл-реквест с новой метрикой. Так возникли бы неправильные стимулы. Команды либо начали бы избегать полезной телеметрии, потому что процесс кажется тяжелым, либо кто-то стал бы формально штамповать согласования, лишь бы работа не останавливалась. Так получается худшая версия управления: более медленная поставка изменений, фиктивное согласование и по-прежнему никакого настоящего владения.

Масштабируемый вариант – это защитные ограничители. Дайте командам стандартные библиотеки, утвержденные измерения и скучные значения по умолчанию: service, env, region, team, zone, status_code, route_template. Затем блокируйте мусор на границе. CI отклоняет user_id, session_id, trace_id, идентификаторы контейнеров и сгенерированные идентификаторы запусков. Коллектор удаляет небезопасные атрибуты. Шлюз отбрасывает проверки работоспособности, отладочный шум и малоценный мусор до того, как они попадут к вендору. Ручная проверка по-прежнему нужна для таких вещей, как новое глобальное измерение, чувствительный идентификатор, новый экспортер, более длительный класс хранения и так далее.

Для сроков хранения нужна та же дисциплина. Каждый сигнал должен рождаться с ожидаемой продолжительностью жизни. Метрики, управляющие оповещениями, хранятся дольше. Диагностические сигналы получают более короткое горячее окно. Отладочные сигналы быстро удаляются. Все неклассифицированное по умолчанию живет недолго. Если метрика не поддерживает оповещение, дашборд, инструкцию по реагированию, SLO, проверку развертывания, процесс соответствия требованиям или расследование безопасности, она не должна жить вечно.

Платформенная команда отвечает за поддерживаемый путь, список запретов, правила коллектора, процесс исключений и бюджетные границы. Сервисные команды отвечают за сигналы, которые они испускают, и решениями, которые эти сигналы поддерживают.

Сломанное зеркало хуже, чем отсутствие зеркала

Бесполезный сигнал легко заблокировать на уровне коллектора. Но через шесть месяцев у него уже есть дашборд, полумертвое оповещение и одна страшная история об инциденте, которой все прикрываются, чтобы его защитить. Плохая телеметрия недолго остается безвредной. Вскоре люди начинают относиться к ней как к чему-то, что обязательно должно существовать.

Отсутствие телеметрии – это честная слепота. Плохая телеметрия хуже. Она дает людям то, чему можно доверять, и при этом незаметно приучает организацию принимать решения на основе шума. Именно эту часть мы недооцениваем. Зеркало находится не снаружи машины. Оно меняет то, как машина ведет себя.

Телеметрия редко ломается резко — обычно она просто постепенно превращается в шум, который никто уже не контролирует. И чем больше в инфраструктуре автоматизации, платформенных слоев и AI-инструментов, тем сложнее становится понимать, где сигнал действительно помогает принимать решения, а где только создает нагрузку и иллюзию контроля. Если вам интересны такие темы — приходите на бесплатные уроки:

• 3 июня в 20:00. «Как измерить рост производительности команды от внедрения ИИ». Записаться

• 16 июня в 20:00. «От кода к людям: как вырасти в руководителя команды и не возненавидеть свою работу». Записаться

Еще больше бесплатных уроков от преподавателей курсов можно посмотреть в календаре мероприятий.