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

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

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

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

Эти четыре шага объясняют, почему x-ось алфавитная, а не временная: сортировка на шаге 3 группирует связанные пути, а не последовательные события. Без этого понимания каждый фрейм левее соседнего будет соблазнять тебя ложным выводом «этот выполнился раньше».

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

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

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

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

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

Поэтому чтение строго вертикальное: ищи самое широкое плато, потому что ширина — это число сэмплов, и широкий фрейм — это место, где CPU реально провёл время; это и есть цель оптимизации. Высокая, но узкая башня — это глубокая цепочка вызовов, которая редко бывает на CPU; это red herring, каким бы драматичным ни казался её рост. Плоская вершина широкого стека — это leaf, который реально делает работу, ведь над ним нет ничего шире.

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

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

Обнаружение регрессий деплоя: Захватываешь профиль до и после деплоя под сравнимой нагрузкой. Делаешь diff: дифференциальный flame graph (differential 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 после деплоя» → автоматическое обнаружение регрессии.