Наблюдаемость
OTel: тест с множественным выбором
Суть Синтез юнита OTel в формате множественного выбора — архитектура из четырёх частей, сигналы и OTLP, пайплайн Collector, sampling, vendor-нейтральность и эксплуатация.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов, прошивающих весь юнит. Каждый отражает реальное архитектурное или инцидентное решение — не определение для заучивания, а место, где вносить изменение, и почему оно ложится именно туда.
Цель
Убедись, что связываешь четыре части — API, SDK, Collector, OTLP — с решениями, которыми они управляют: где живёт портируемость, что даёт корреляцию сигналов, как sampling и пайплайн Collector складываются вместе и как всё это падает в проде.
Викторина
Completed
Платформенная команда заявляет полную vendor-нейтральность OTel. На ревью всплывают два факта: код приложения напрямую импортирует вендорский SDK dd-trace, а перед каждым сервисом стоит Collector, конвертирующий в OTLP. Нейтральны ли они и почему?
Heads-up Collector может переформировать данные, но стоимость миграции уже понесена выше по потоку: каждый сервис импортирует вендорский SDK. Чтобы реально уйти, придётся переписать инструментирование во всех сервисах, так что нейтральность задаёт граница, а не Collector.
Heads-up Collector — необходимая инфраструктура, но недостаточная для нейтральности. Если граница приложения не OTLP, lock-in живёт в коде приложения независимо от того, что делает Collector.
Heads-up Вендорские дистрибутивы, принимающие и эмитящие OTLP, допустимы; тихая эрозия — это вендорские SDK в коде приложения и проприетарные процессоры, существующие только в дистрибутиве, а не сам дистрибутив.
Викторина
Completed
Команде нужен tail sampling, сохраняющий 100% трейсов с ошибками. Они гоняют один agent Collector как DaemonSet (по одному на ноду), экспортирующий прямо в backend. Почему это не работает и каков минимальный фикс?
Heads-up Бинарь процессора один и тот же; проблема в локальности данных. Агент получает только спаны своей ноды, поэтому у него никогда нет полного контекста трейса, которого требует tail sampling — это не отсутствующая фича.
Heads-up Head sampling решает на старте корневого спана, до того как ошибка произошла — он слеп к ошибкам. Только tail sampling, видя завершённый трейс, может сохранить 100% трейсов с ошибками.
Heads-up Размер буфера ни при чём, когда агент вообще не получает спаны трейса с других нод. Проблема в том, что полный трейс не ко-локализован, а не в том, что буфер мал.
Викторина
Completed
Два сервиса эмитят HTTP-телеметрию. Сервис A тегирует маршрут как http.route; сервис B — как http_route. OTLP-экспорт успешен у обоих, ошибки SDK нет. Что на самом деле ломается и где?
Heads-up OTLP не накладывает ограничений на имена атрибутов; оба экспортируются нормально. Semantic Conventions — это соглашение об именовании, обеспечиваемое управлением, а не wire-протоколом.
Heads-up Ни SDK, ни Collector не обеспечивают Semantic Conventions на этапе записи. Именно поэтому дрейф тихий и почему platform-обёртка плюс CI-линт — единственный устойчивый фикс.
Heads-up Процессоры transform/attributes могут переименовывать поля, но только если ты напишешь правило — автоматической коррекции нет. По умолчанию нестандартное имя проходит насквозь.
Викторина
Completed
В продовом trace-пайплайне у тебя memory_limiter, batch и tail_sampling. Почему memory_limiter должен быть первым и каково последствие постановки tail_sampling первым?
Heads-up Collector выполняет процессоры ровно в том порядке, в котором ты их объявил. Порядок — решение о корректности и защите, а не подсказка.
Heads-up tail_sampling не сокращает память в полёте — он буферизует каждый спан на 30-60с до решения. Запуск его перед memory_limiter означает, что limiter не может защитить от той самой буферизации, что вызывает OOM.
Heads-up memory_limiter проверяет RAM процесса независимо от батчинга и должен идти первым, чтобы отказывать новым записям до того, как более дорогие процессоры потребят больше памяти.
Викторина
Completed
У metrics-backend взрывается кардинальность после флотового раската OTel auto-instrumentation. Новое измерение, разгоняющее её, — атрибут url.full у HTTP-клиента. Какова корневая причина и правильный фикс?
Heads-up Масштабирование хранилища лечит симптом, а стоимость продолжает расти. Причина — атрибут неограниченной кардинальности; устойчивый фикс — шаблонизировать или убрать его, а не поглощать бесконечные series.
Heads-up Tail sampling действует на трейсы, а не на кардинальность metric series. Взрывающееся измерение — это пер-запросный атрибут на метриках — url.full — независимо от sampling.
Heads-up Тип гистограммы управляет разрешением бакетов латентности, а не кардинальностью лейблов. Кардинальность — в измерении лейбла url.full, которое ни один тип гистограммы не меняет.
Викторина
Completed
Твой единственный gateway OTel Collector падает во время инцидента. Дашборды on-call остаются зелёными и алерты не срабатывают, хотя пользовательские ошибки растут. Каков урок и структурный фикс?
Heads-up Дашборды зелёные, потому что их источник данных — Collector — лежит, а не потому что система здорова. Отсутствие телеметрии трактуется как отсутствие проблем.
Heads-up Больше логов всё равно течёт через тот же упавший Collector. Фикс — сделать сам Collector высокодоступным и самонаблюдаемым, а не лить больше объёма в сломанную трубу.
Heads-up Прямой экспорт теряет буферизацию, центральную политику и единообразную обработку и создаёт новую точку отказа на каждый сервис. Ответ — сделать ярус Collector HA и наблюдаемым, а не убирать его.
Итог
Сквозная линия: портируемость решается на границе приложения (эмить OTLP там или нигде), корреляция решается Semantic Conventions (согласованные имена или невидимые сервисы), а Collector — это место, где живёт политика: порядок процессоров его защищает, sampling складывает дешёвый head и курируемый tail, а gateway должен быть HA и самонаблюдаемым, потому что когда Collector падает, твоя видимость падает молча. Каждый продовый сбой этого юнита — размытая нейтральность, разрезанные трейсы, дрейф именования, OOM, утечки кардинальности, слепые дашборды — сводится к одной из этих четырёх частей.