Две новые технологии, BTF и CO-RE, прокладывают для BPF путь в отрасль с миллиардным оборотом. Уже сейчас существует множество BPF (eBPF) стартапов, создающих сетевые продукты, продукты для обеспечения безопасности и производительности (и многое другое вне нашего поля зрения), но требующих от клиентов установки зависимостей LLVM, Clang и заголовков библиотек ядра (kernel-headers), которые могут занимать в памяти более 100 мегабайт, что негативно сказывается на скорости распространения технологии. BTF и CO-RE устраняют эти зависимости во время выполнения, делая BPF не только более практичным для встроенных сред Linux, но и для повсеместного внедрения. Эти технологии представляют из себя: BTF: BPF Type Format, который предоставляет структурную информацию в целях устранения необходимости в заголовках библиотек ядра и Clang. CO-RE: BPF Compile-Once Run-Everywhere, который делает скомпилированный байт-код BPF перемещаемым, избавляя от необходимости перекомпиляции с помощью LLVM. Clang и LLVM по-прежнему требуются для компиляции, но в результате получается облегченный ELF-бинарник, который включает предварительно скомпилированный BPF байт-код и может выполняться везде. В проекте BCC есть такой набор, называемый libbpf tools. Для примера я перенес свой инструмент opensnoop(8):  Это opensnoop(8) - ELF-бинарник, который не использует libLLVM или libclang:   … и stripped занимает всего 151 Кбайт. А теперь представьте BPF-продукт: вместо того, чтобы требовать от клиентов установки различных тяжелых (и хрупких) зависимостей, BPF-агент теперь может быть одним крошечным бинарником, который работает с любым ядром, имеющим BTF. Дело не только в том, чтобы сохранить BPF байт-код в ELF и затем отправить его в любое другое ядро. Многие BPF-программы используют структуры ядра (kernel structs), которые могут изменяться от одной версии ядра к другой. Ваш BPF байт-код может по-прежнему выполняться на разных ядрах, но он может считывать неправильные смещения структуры и выводить бессмыслицу! opensnoop(8) не просматривает структуры ядра, поскольку он использует стабильные точки трассировки и их аргументы, но многие другие инструменты это делают. Это проблема перемещения, и BTF и CO-RE решают эту проблему для BPF-бинарников. BTF предоставляет информацию о типе, чтобы смещения структуры и другие детали могли быть запрошены по мере необходимости, а CO-RE записывает, какие части BPF-программы необходимо переписать и как. Разработчик CO-RE Андрей Накрыко написал длинные статьи, в которых это объясняется более подробно: «Переносимость BPF» и «информация о типах CO-RE BTF». Эти новые BPF-бинарники возможны только в том случае, если установлен этот параметр конфигурации ядра. Он добавляет около 1,5 Мбайт к образу ядра (это крошечный размер по сравнению с DWARF debuginfo, который может составлять сотни Мбайт). В Ubuntu 20.10 этот параметр конфигурации уже установлен по умолчанию, и все остальные дистрибутивы должны следовать ему. Примечание для разработчиков дистрибутива: он требует pahole >= 1.16. Для работы со средствами оценки производительности BPF (BPF performance tools) вы должны начать с запуска инструментария BCC и bpftrace, а затем написания bpftrace-кода. Инструментарий BCC в конечном итоге следует переключить с Python на libbpf C - на работе это не отразится. Средства оценки производительности кода в BCC Python теперь считаются устаревшими, по этому мы переходим к libbpf C с BTF и CO-RE (хотя у нас все еще остается некоторая работа с библиотеками, например, поддержка USDT, поэтому Python-версии будут нам необходимы еще некоторое время). Обратите внимание, что существуют другие варианты использования BCC, которые могут продолжать использовать Python-интерфейс; сомейнтейнер BPF Алексей Старовойтов и я кратко обсудили это на iovisor-dev. Моя книга BPF Performance Tools посвящена запуску инструментария BCC и написанию bpftrace-кода, и эта часть не меняется. Однако примеры программирования на Python в Приложении C теперь считаются устаревшими. Приносим извинения за неудобства. К счастью, это всего лишь 15 страниц из 880-страничной книги. А что насчет bpftrace? Он поддерживает BTF, и в будущем мы планируем также уменьшить объем его установки (в настоящее время он может достигать 29 Мбайт, и мы убеждены, что этот показатель может быть намного меньше). Учитывая средний размер программы libbpf в 229 Кбайт (на основе текущих инструментов libbpf, stripped) и средний размер программы bpftrace в 1 Кбайт (инструменты из моей книги), большая коллекция инструментов bpftrace плюс бинарник bpftrace может потребовать меньший объем установки, чем эквивалент в libbpf. Кроме того, версии bpftrace можно изменять на лету. libbpf лучше подходит для более сложных и серьезных инструментов, которым нужны настраиваемые аргументы и библиотеки. Как видно из скриншотов, будущее инструментов оценки производительности BPF таково: … и таково: … а не таково:  Спасибо Yonghong Song (Facebook) за руководство в разработке BTF, Andrii Nakryiko (Facebook) за руководство разработке CO-RE и всем, кто участвует в этом проекте. Перевод статьи подготовлен в преддверии старта курса "Нагрузочное тестирование". В связи с этим приглашаем всех желающих посетить бесплатный демо-урок по теме: "Проведение нагрузочного тестирования в средстве Performance center". ЗАБРАТЬ СКИДКУ Редактор