Как flame graph строится из сэмплов и как использовать его в production

Старший инженер на конференции спрашивает: «Какая функция выполняется раньше этой на flame graph?» Он указывает на два соседних фрейма на одном уровне. Ответ: ни один — x-ось алфавитная. Если этого не знать, потеряешь часы на неверную гипотезу.

Как flame graph строится из сэмплов

Каждый сэмпл — список имён функций от leaf (выполняется сейчас) до root (точка входа программы). После окна профилирования:

1. Собираются все сэмплы.
2. Одинаковые стеки схлопываются в одну колонку — их счётчики суммируются, делая колонку шире.
3. Для рендеринга все уникальные стеки сортируются алфавитно по корневой функции — так один и тот же родитель группирует дочерние элементы рядом.
4. Для каждого уровня прямоугольники рисуются с шириной, пропорциональной счётчику.

Читается сверху вниз: выбери leaf-фрейм (верх), проверь его ширину, спустись вниз, чтобы увидеть, кто его вызывает.

Самая дорогая ошибка прочтения

Позиция по x-оси — алфавитный порядок полного пути стека, не время, не порядок вызовов. Фрейм, стоящий левее другого на том же уровне, не говорит ничего о том, какой из них выполнился первым. Он говорит только о том, что путь его стека раньше по алфавиту.

Это самая распространённая ошибка инженеров при первом чтении flame graph. Если видишь два широких фрейма рядом и думаешь «сначала A, потом B», ты делаешь ложный вывод. Оба могут вызываться одним родителем в разные моменты, из несвязанных code path, из распараллеленного кода.

Если нужен порядок времени — правильный инструмент это trace view (timeline span’ов в стиле Gantt). Flame graph отвечает «что» горячее; traces отвечают «когда» в запросе выполнялся каждый шаг.

Рабочие процессы с профилями в production

SLO burn drilldown: Срабатывает SLO alert → кликаешь ссылку → временной диапазон предфильтрован по burn-окну → CPU + off-CPU flame graph рядом → определяешь изменившуюся функцию → привязываешь к деплою. Менее 90 секунд от пейджера до git blame для любого инцидента, где баг работал на CPU.

Обнаружение регрессий деплоя: Захватываешь профиль до и после деплоя под сравнимой нагрузкой. Делаешь diff: дифференциальный flame graph окрашивает фреймы по относительному изменению — красный для выросших фреймов, синий для сократившихся, белый для неизменных. Новые широкие красные фреймы, которых не было до деплоя — это регрессия. Production-grade continuous-profile бэкенды (Pyroscope, Datadog) включают это из коробки: «compare versions» выбирает два коммита или временных окна и рендерит diff.

Profile-as-data: запросы за пределами flame graph:

Профили — это временные ряды сэмплов стека; бэкенды всё чаще позволяют делать к ним запросы как к базе данных:

• «Top-10 функций по self-CPU по всем сервисам за последний час» → capacity planning.
• «Найти все профили, где функция X входит в top-5» → оценка влияния перед удалением медленной библиотеки.
• «Сгруппировать flame graph’ы по Kubernetes-ноде» → найти горячие ноды.
• «Alert при появлении новой функции в top-5 после деплоя» → автоматическое обнаружение регрессии.