eBPF профилирование
Тема дорожной карты · Observability
eBPF (Extended Berkeley Packet Filter) профилирование — это техника наблюдаемости на уровне ядра, позволяющая безопасно внедрять профилировщики в ядро Linux во время работы системы и собирать данные о производительности из любого процесса без изменений кода приложения или языкоспецифичных SDK. eBPF-профилировщики, такие как bcc, bpftrace и Grafana Beyla, подключаются к точкам трассировки ядра и событиям perf для одновременного сбора профилей CPU, трассировок ввода-вывода и данных о задержке системных вызовов из всех запущенных процессов. Это делает eBPF-профилирование особенно мощным в полиглотных окружениях, где развёртывание языкоспецифичных агентов профилирования для каждого сервиса непрактично — единственный eBPF-агент на каждом Kubernetes-узле может прозрачно профилировать все контейнеры. Grafana Pyroscope поддерживает eBPF-непрерывное профилирование через grafana/pyroscope-ebpf, а такие инструменты, как Cilium, используют eBPF как для сетевой наблюдаемости, так и для применения политик безопасности. Поскольку программы eBPF выполняются в ядре с гарантиями безопасности (ограниченные циклы, проверка безопасности памяти), eBPF-профилирование добавляет минимальные накладные расходы и безопасно для непрерывного использования в продакшене.
Как это работает
eBPF профилирование — 4-й столп observability: always-on профилирование CPU, памяти, lock contention, goroutines/threads. Инструменты: Pyroscope (теперь часть Grafana, поддерживает много языков), Polar Signals Parca, datadog-profiler, async-profiler (JVM), pprof (Go встроен). Найдите медленную функцию в production без повторного запуска с прицепленным профайлером. Flame graphs — каноническая визуализация. Overhead sampling обычно < 5%.
Когда применять
Включите continuous profiling для любого сервиса с performance-sensitive кодом (latency-sensitive API, batch-jobs). Pyroscope/Parca — open-source выбор; включите per-language профайлеры (net/http/pprof для Go, pyflame / py-spy для Python, async-profiler для JVM). Профайлите в production — staging показывает другие паттерны. Комбинируйте с traces для "какой span = какая функция".
Типичные ошибки
Ловушки eBPF профилирование: overhead профайлинга не трекается (иногда > 10% — sampling rate важен); профили без service-контекста (какая версия? какая env?); профайлят всё, но никогда не читают данные ("они у нас есть" != "мы их используем"); flame graphs без фильтрации (одна гигантская башня прячет всё остальное).