Profiling в production: безопасность, war stories, OTel profiles и дизайн инфраструктуры

Continuous profiler Stripe поймал регрессию через два дня после деплоя — ни один дашборд её не показал. Новый feature flag читал с диска на каждый запрос вместо in-memory кеша. CPU-профиль выглядел нормально; off-CPU профиль показал ожидание диска. Фикс — одна строка. Без continuous profiling обнаружение заняло бы недели.

Профили — чувствительные артефакты

Профиль содержит имена функций (часто приватных), паттерны вызовов и иногда аргументы аллокаций — достаточно для обратной разработки бизнес-логики. Некоторые profiler’ы захватывают значения аргументов на сайтах аллокаций; плохо настроенные allocation profiler’ы утекали credentials.

В недружественных контекстах профиль чужого бинарника может раскрыть проприетарные алгоритмы — одни лишь имена функций часто телеграфируют, что делает сервис. eBPF-profiler’ы, работающие на общих ядрах, в принципе могут наблюдать выполнение других тенантов; именно поэтому eBPF требует явных capabilities и ограничен по namespace в современных ядрах.

Production-дисциплина:

• Профили ограничены RBAC по команде (модель tenancy Pyroscope).
• Хранение ограничено 30-90 днями; экспорт требует согласования.
• Никогда не отправляются за пределы организации.
• eBPF-агент работает только с CAP_PERFMON, не с полным root.
• Audit log того, кто и какой профиль забирал.

Production war stories

Discord 2020: chat-сервис работал при 80% CPU с загадочной tail latency. CPU-профиль указал на JSON-сериализацию. Переход на более быструю JSON-библиотеку снизил CPU до 30%, tail latency — до baseline.

GitHub 2021: Ruby worker’ы падали с OOM на определённых endpoint’ах. Allocation profile показал одну функцию рендеринга шаблонов, аллоцирующую 200 МБ на запрос из-за unbounded loop конкатенации строк.

Stripe 2022: continuous profiling поймал регрессию через два дня после деплоя. Новый feature flag читал с диска на каждый запрос вместо in-memory кеша. CPU-профиль выглядел нормально; off-CPU профиль показал ожидание диска. Фикс — одна строка.

Cloudflare 2023: регрессия Worker runtime появилась в eBPF-профилях как время в GC V8. Команда откатила обновление V8, введшее более агрессивный сбор.

Slack 2024: PHP-сервис тратил 30% CPU на autoloader. Profiler-guided настройка opcache снизила до 5%.

Общий паттерн: у каждой крупной инженерной организации есть war story о profiling’е. Общая нить: дашборды показывали норму, но профиль показывал bottleneck. Фикс был очевиден по flame graph; невозможен для обнаружения без него.

OTel profile signal: четвёртая стойка

OpenTelemetry стандартизирует профили как четвёртый сигнал (после логов, метрик, traces). Спецификация определяет:

• Модель данных профиля: сэмплы со стеками, метками и временными диапазонами.
• Транспорт: OTLP profile signal (добавлен в 2024).
• Интеграцию с context propagation: тегирование trace-id на каждом сэмпле.

Статус adoption: Datadog, Grafana, Honeycomb, Splunk реализуют ingestion OTel profiles. Агенты (OTel Collector + сторона profiler’а) отправляют профили в формате OTel. OTel profile spec находится в beta с 2026 — большинство production-деплойментов по-прежнему используют vendor-специфичные форматы (pprof, JFR, Pyroscope-native). Выбор инструмента сегодня закрепляет формат на 2-3 года; траектория OTel стоит отслеживания.

Обещание: cross-vendor портируемость и унифицированный collector pipeline — та же архитектура, что у логов, метрик и traces. Проблема: спецификация молодая, реализации расходятся по краям.

Проектирование инфраструктуры continuous profiling

Polyglot-платформа из 200 сервисов (Go, Java, Node, Python) с требованием обнаружения регрессий деплоя за 1 час и drill trace-to-profile за менее чем 30 секунд:

Уровень 1 — Сбор: eBPF DaemonSet на каждой ноде (в стиле Parca или Pyroscope eBPF) как универсальная база — покрывает все языки, один агент на ноду. Per-language агенты как дополнение: pprof для Go, async-profiler для Java, py-spy для Python. eBPF-агент — базовый; per-language агенты дают allocation и mutex профили.

Уровень 2 — Бэкенд: self-hosted Pyroscope 2.0 кластер. Object storage (S3 / GCS) с 30-дневным full-resolution хранением и 90-дневным downsampled. Дедупликация символов держит хранилище на сервис ниже 10 ГБ/месяц.

Уровень 3 — Корреляция с trace: профили несут метки trace-id и span-id. Grafana связывает trace span → Pyroscope с фильтром по trace-id. Drill за менее чем 30 секунд.

Уровень 4 — Обнаружение регрессий: CI job на каждый деплой: захват 5-минутного профиля новой версии под canary-трафиком, diff с профилем предыдущей версии, публикация diff flame graph как комментарий к PR, падение CI, если новая функция появляется в top-5 по self-CPU. Ежечасный production diff с baseline того же часа вчера; Slack alert на изменения формы.

Уровень 5 — Контроль стоимости: rate сэмплирования на сервис настраивается в service.yaml (по умолчанию 99 Hz; снижается до 19 Hz для дешёвых baseline-сервисов). Budget alert при достижении 80% месячного потолка стоимости.