Continuous profiling: always-on flame graphs с eBPF и корреляцией trace-id

SLO горит в 2:14 ночи. Пейджер будит on-call. Традиционный profiling требует SSH, воспроизведения проблемы под нагрузкой, захвата профиля и его разбора — в 2:14 ночи, под давлением. Continuous profiling уже хранит flame graph за 2:14 на дашборде.

Традиционный vs continuous profiling

Традиционный (on-demand) profiling: SSH, запуск perf record или обращение к /debug/pprof/profile, сбор данных, анализ, выход. Стоимость: только во время захвата. Ограничение: нужно присутствие и активное проявление проблемы. Для нерегулярных инцидентов или тех, что самоустраняются, доказательство теряется.

Continuous profiling: агент работает на каждом хосте или контейнере, сэмплируя 100 раз в секунду непрерывно, пакетирует и отправляет сжатые профили каждые 10-15 секунд на бэкенд. Бэкенд хранит их с индексацией по сервису, хосту и временному диапазону. Хранилище: ~50-200 МБ/сутки на сервис, ~1.5-6 ГБ/месяц. Overhead: 2-5% CPU. Главный выигрыш: когда горит SLO, профиль горящих минут уже сохранён.

eBPF: language-agnostic profiling

Традиционные language profiler’ы (Go pprof, JFR, async-profiler, py-spy) требуют языковой поддержки — рантайм должен предоставлять API для обхода стека. Для Python, Ruby и старых интерпретаторов PHP требуются хуки от команды рантайма.

eBPF-profiler’ы (Pyroscope eBPF mode, Parca) читают стеки со стороны ядра: системный вызов ядра perf_event_open плюс BPF-прикреплённый probe захватывает user-space стеки в момент сэмпла. Это означает:

• Работает для любого языка, любого бинарника, без изменений в коде приложения.
• Один агент покрывает все сервисы на хосте — Go, Java, Node, Python.
• Ловит overhead сторонних библиотек, который language-specific profiler’ы могут пропустить.

Проблема: разрешение символов. Ядро видит адреса памяти; profiler отображает их в имена функций по debug info (DWARF, BTF, JIT-emitted symbol files для V8 или JVM). Большинство production eBPF-profiler’ов справляется с этим; иногда появляются фреймы [unknown], когда DWARF срезан или JIT-код слишком волатилен.

Покрытие profiler’ов по языкам

Корреляция trace-id: от медленного span к flame graph за 30 секунд

Каждый сэмпл профиля может содержать trace-id запроса, обрабатываемого в момент сэмпла — хранится в thread-local контексте. Когда в trace view появляется медленный trace, соответствующие сэмплы профиля (только те, что содержат этот trace-id) фильтруются и рендерятся как flame graph конкретно для этого запроса.

Это мост между «куда ушло время в запросе» (trace span) и «какой код съел CPU» (profile). Рабочий процесс:

1. Срабатывает SLO alert — p99 latency выходит за бюджет.
2. Открываешь trace view — находишь медленные span’ы, записываешь trace-id.
3. Открываешь profile view с фильтром по trace-id — появляется flame graph для этого конкретного запроса.
4. Самый широкий фрейм — функция, которую надо починить.
5. Готово — меньше чем за 60 секунд.

OTel profile signal (стабилизируется в 2025-2026) стандартизирует эту связку. Production-grade observability платформы (Datadog, Grafana с Pyroscope, Honeycomb) поставляют этот drilldown из коробки.

Экономика хранения профилей

Pyroscope 2.0 (выпущен в апреле 2026) сократил объём хранения в 3 раза за счёт дедупликации символов из профилей одного бинарника — имена функций и пути к источникам хранятся в общей таблице символов вместо повторения в каждом профиле.

Стратегия хранения: 7 дней полное разрешение для активной отладки, 30 дней с downsampling’ом (один профиль на 5 минут), 90 дней для анализа долгосрочных трендов. Команды с ограниченным бюджетом ограничиваются 14 днями fine + 60 днями coarse.