Наблюдаемость
Profiling: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту profiling — экономика sampling, выбор типа профиля, чтение flame graph, символизация eBPF и production-дисциплина.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает решение, которое ты принимаешь в реальном инциденте по латентности — не определение для заучивания, а то, какой профиль снять, как его прочитать и что его числа реально значат под production-нагрузкой.
Цель
Убедись, что связываешь экономику sampling, выбор типа профиля, чтение flame graph, символизацию eBPF и production-дисциплину — тот синтез, к которому вели отдельные уроки.
Викторина
Completed
Запрос идёт 500 мс по wall-clock, но CPU profile приписывает ему лишь 20 мс. Куда ушли остальные 480 мс и какой профиль их покажет?
Heads-up Более высокий rate соберёт больше сэмплов работающего кода, но снятый с CPU поток потребляет ноль CPU и его не на чем сэмплировать при любой частоте. Это время off-CPU по определению.
Heads-up Heap profile показывает аллоцированные байты по стеку, а не время ожидания. Общий ответ для запроса с низким CPU и большим wall — off-CPU ожидание, видимое в off-CPU или block профиле.
Heads-up Ничего не потеряно. CPU profile корректно сообщает 20 мс вычислений; остальное — off-CPU время, которое CPU-профайлер и не должен видеть.
Викторина
Completed
Сервис делает 5 миллионов вызовов функций в секунду. Нужен always-on профайлинг в production. Почему sampling profiler — единственный жизнеспособный выбор против инструментирования?
Heads-up Инструментирование снимает точные счётчики вызовов и тайминги по функциям — больше данных, а не меньше. Дисквалифицирует его стоимость: она растёт с частотой вызовов, а не объём данных.
Heads-up Инструментирование точное; sampling статистический, с доверительным интервалом. Sampling выигрывает на ограниченном overhead, а не на точности — его точности просто достаточно, чтобы найти hotspot.
Heads-up Обоим нужна представительная нагрузка — на простаивающей системе виден только idle-цикл рантайма. Sampling выигрывает в production за счёт ограниченного, не зависящего от частоты вызовов overhead.
Викторина
Completed
Инженер указывает на два широких фрейма рядом на одном уровне flame graph и заключает, что левый выполняется раньше правого. Что не так?
Heads-up Это самое частое неверное прочтение flame graph. Flame graph сортирует стеки алфавитно по корню, чтобы дети одного родителя стояли рядом; ось x никогда не время.
Heads-up У них может быть общий родитель, а может и нет. Соседство возникает из лексикографической сортировки строки полного стека, а ширина — это число сэмплов; ни то ни другое не кодирует, когда и как часто они чередовались.
Heads-up Ни один стандартный flame graph не ставит время на ось x. Wall-clock-вид одного запроса — это flame chart / trace-таймлайн, другая визуализация.
Викторина
Completed
eBPF-профайлер показывает чистые стеки для Go и Rust, но множество '[unknown]' фреймов для Python-сервиса на той же ноде. Почему?
Heads-up Скорость к символизации отношения не имеет. Ядро снимает стек нормально; оно просто не может сопоставить внутренние адреса интерпретатора именам функций Python без CPython-специфичной разматки.
Heads-up [unknown] фреймы для интерпретируемых рантаймов ожидаемы без явной поддержки. Решение — Python-aware профайлер (py-spy) или CPython-поддерживающий eBPF-режим, а не замена агента.
Heads-up CPython — байткод-интерпретатор, не JIT. У JIT-рантаймов (JVM, V8) другая проблема символизации, решаемая через perf maps или AsyncGetCallTrace.
Викторина
Completed
Continuous profiler заявлен с overhead 2-5%, но в production ты меряешь 12%. Какую причину проверять первой?
Heads-up Цифра 2-5% реальна и проверяема на типичных нагрузках. Скачок выше почти всегда означает мисконфиг или стоимость глубоких стеков / JIT-символизации — проверь конфиг до смены инструмента.
Heads-up Continuous profiling на 2-5% — индустриальный always-on стандарт. Посыл юнита в том, что он достаточно дёшев, чтобы оставлять включённым; 12% — аномалия для диагностики.
Heads-up Стоимость sampling ограничена sample rate, а не частотой вызовов, поэтому она не растёт с трафиком. Рост до 12% указывает на мисконфиг rate, синхронную символизацию или глубокие стеки.
Викторина
Completed
На разборе инцидента кто-то предлагает приложить production-профиль к тикету в поддержку вендора. Почему senior-инженер должен возразить?
Heads-up Это ровно то заблуждение, о котором предупреждает юнит. Профиль ближе к выводу отладчика, чем к метрике; имена функций и паттерны вызовов позволяют реверс-инжинирить бизнес-логику.
Heads-up CPU profile уже раскрывает имена функций и паттерны вызовов. Allocation-профили добавляют сверху возможные значения аргументов — но и одного CPU profile достаточно, чтобы требовать контроль доступа.
Heads-up Сжатые профили крошечные (~50-500 КБ). Проблема в раскрытии информации, а не в размере файла.
Итог
Сквозная линия юнита — одна диагностическая петля: выбери профиль, который отвечает на твой вопрос (CPU для вычислений, off-CPU/block/mutex для ожидания, heap/allocation для памяти), читай flame graph правильно (ширина — доля сэмплов, ось x алфавитная, а не время) и доверяй числам только зная их пределы (sampling ограничен, но слеп к hot-путям короче интервала, eBPF требует language-aware символизации, overhead 2-5% реален, но чувствителен к конфигу). А поскольку профиль раскрывает внутренности кода, относись к нему как к чувствительному артефакту, а не к свободно шарящейся метрике.