Брендан Грег (Brendan Gregg), один из разработчиков DTrace, объявил (http://www.brendangregg.com/blog/2018-10-08/dtrace-for-linux...) об открытии доступа к репозиторию проекта BPFtrace (https://github.com/iovisor/bpftrace), в рамках которого развивается высокоуровневый язык для написания скриптов динамической отладки и анализа производительности приложений и ядра, продолжающий развитие системы DTrace (позиционируется как DTrace 2.0). Наработки проекта распространяются (https://github.com/iovisor/bpftrace) под лицензией Apache 2.0.BPFtrace реализован в виде фронтэнда, транслирующего отладочные сценарии в форуму приложений eBPF, имеющих доступ к низкоуровневым примитивам (https://www.opennet.me/opennews/art.shtml?num=45391) ядра для анализа производительности. Для компиляции скриптов BPFtrace в байткод BPF применяется бэкенд на базе LLVM. Язык BPFtrace напоминает AWK и Си, и предоставляет возможности для упрощения трассировки, похожие на DTrace и SystemTap.
eBPF представляет собой встроенный в ядро Linux интерпретатор байткода, позволяющий создавать обработчики сетевых операций, отслеживать работу систем, перехватывать системные вызовы, контролировать доступ, обрабатывать события с сохранением хронометража (perf_event_open), подсчитывать частоту и время выполнения операций, выполнять трассировку с использованием kprobes/uprobes/tracepoints. Благодаря применению JIT-компиляции, байткод на лету транслируется в машинные инструкции и выполняется с производительностью нативного кода. BPFtrace пока ограничен поддержкой платформы Linux, но
ведётся (https://wiki.freebsd.org/SummerOfCode2018Projects/eBPF) разработка реализации eBPF для FreeBSD, после завершения которой BPFtrace сможет быть портирован на FreeBSD.BPFtrace позволяет отслеживать поведение системы и выполнять диагностику проблем в режиме реального времени, не влияя в процессе отладки на работу и производительность исследуемых приложений. В сценариях BPFtrace может учитываться разнообразная статистика о подсистемах ядра, процессах, системных вызовах, обрабатываемых файлах, блочном вводе/выводе, сетевой активности, состоянии кэшей, работе планировщика задач, утилизации CPU (например, можно определить какое ядро CPU в данным момент выполняет код) и многих других параметрах.
Возможна (https://github.com/iovisor/bpftrace/blob/master/docs/referen...) привязка скриптов-обработчиков к функциям ядра (kprobe:vfs_read), функциям в пространстве пользователя (uprobe:/bin/bash:readline), точкам трассировки в ядре (tracepoint:sched:sched_switch), программным и аппаратным событиям (software:faults: и hardware:cache-references:). Возможен периодический запуск скриптов для сбора статистики (profile:ms: и interval:ms:). Поддерживается привязка скрипта сразу к нескольким событиям, привязка по маске (kprobe:vfs_*) и определение условий для вызова (kprobe:sys_open / uid == 0 /). Для использования в скриптах предлагается типовой набор функций и библиотека готовых обработчиков на основе BCC (https://github.com/iovisor/bcc) (BPF Compiler Collection).
Из возможностей, которые имеются в DTrace и пока отсутствуют в BPFtrace упоминаются средства агрегирования вывода, обработке аргументов для shell, поддержка трансляторов, sizeof() и спекулятивный режим трассировки. Среди функциональности, которая есть в BPFtrace, но недоступна в DTrace отмечается поддержка сохранения и извлечения трассировок стека с использованием переменных, а также возможность привлечения инструментария bcc для создания сложных сценариев и обработки аргументов.
Эквивалентные вызовы в DTrace и BPFtrace:
ТипDTracebpftrace
function@ = quantize(value)@ = hist(value)
function@ = lquantize(value, min, max, step)@ = lhist(value, min, max, step)
variablethis->name$name
variableself->name@name[tid]
variablename[key]@name[key]
variableglobal_name@global_name
variableself->name = 0delete(@name[tid])
variablecurthreadcurtask
variableprobeprov probemod probenamename
providerfbt::func:entrykprobe:func
providerfbt::func:returnkretprobe:func
providerpid$target::func:entryuprobe:func
providerpid$target::func:returnuretprobe:func
providerprofile:::99profile:hz:99
providerprofile:::tick-1secinterval:s:1
Примеры однострочников:
# Отслеживание задержек при чтении данных процессом с PID 181:bpftrace -e 'kprobe:vfs_read /pid == 30153/ { @start[tid] = nsecs; }
kretprobe:vfs_read /@start[tid]/ { @ns = hist(nsecs - @start[tid]); delete(@start[tid]); }'
# Отображение новых процессов с аргументами их вызова
bpftrace -e 'tracepoint:syscalls:sys_enter_execve { join(args->argv); }'# Отслеживание файлов, открытых процессами
bpftrace -e 'tracepoint:syscalls:sys_enter_open { printf("%s %s\n", comm, str(args->filename)); }'# Подсчёт системных вызовов с группировкой по приложениям
bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }'# Подсчёт системных вызовов с группировкой по системным вызовам
bpftrace -e 'tracepoint:syscalls:sys_enter_* { @[name] = count(); }'# Подсчёт системных вызовов с группировкой по процессам
bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[pid, comm] = count(); }'# Размер данных в байтах, прочитанных процессом
bpftrace -e 'tracepoint:syscalls:sys_exit_read /args->ret/ { @[comm] = sum(args->ret); }'# Активность обращения процессов к диску;
bpftrace -e 'tracepoint:block:block_rq_issue { printf("%d %s %d\n", pid, comm, args->bytes); }'# Сведения об обращениях к не выделенным страницам памяти (page fault) с сортировкой по числу обращений;
bpftrace -e 'software:major-faults:1 { @[comm] = count(); }'# Сведения об обращениях к не выделенным страницам памяти (page fault) с сортировкой по процессам;
bpftrace -e 'software:faults:1 { @[comm] = count(); }'# Профилирование стека процесса с PID 189 с частотой 99 Гц.
bpftrace -e 'profile:hz:99 /pid == 189/ { @[ustack] = count(); }'
URL: http://www.brendangregg.com/blog/2018-10-08/dtrace-for-linux...
Новость: https://www.opennet.me/opennews/art.shtml?num=49414
А еще eBPF, говорят, делает ненужными патчи от Meltdown. :)
Ну была мысль у разработчиков ядра в переписке: при загрузке кода искать паттерны при которых программа лезет в чужую память. Получается этакий антивирус от аппаратных взломщиков. И я что-то сомневаюсь, что это будет скоро в ядре, наверняка там все не просто с реализацией.
что-то сдается мне что если эта штука со своим jit окажется в продакшен ядре, meltdown и иже с ними покажутся детсадовскими дразнилками. А так, на этапе отладки вещь очень полезная, интересно как она с mips и arm дружить будет.
Что значит «если»? eBPF уже достаточно давно в ядре. Кажется, с 4.1. А в 4.7 из eBPF стало можно цепляться к tracepoints. Два года уже прошло.
> PID 181:
> /pid == 30153/Это какая система счисления в какую конвертируется? Ну восьмеричная в правах файла ещё ладно, но это уже перебор.
Парни там Dtrace портировали на винду!!!
https://youtu.be/tG8R5SQGPck?t=625
А всего то прошло 14 лет с того момента как это уже было реализовано в солярисе. Линукс очень инновационная и принципиально новая система (с)!
А чего же это Брендан Грег вдруг решил DTrace 2.0 в первую очередь пилить для неинновационного Линукса? Как там Соплярис поживает (инновационно развивается)?
> А чего же это Брендан Грег вдруг решил DTrace 2.0 в первую
> очередь пилить для неинновационного Линукса? Как там Соплярис поживает (инновационно развивается)?Что, вантузянтику (ведь большая часть прикладного десктопного ПО пишется для винды, значит она по этой же логике намного более инновацонна и все такое) за запускаемого в WSL пингвина обидно стало?
конечно обидно, у нас-то только просто-DTrace, без цифирок!http://www.opennet.me/openforum/vsluhforumID3/115534.html#6
Развивается, все в порядке не волнуйтесь.
А зачем это, если SystemTap уже давно есть?
SystemTap не шибко удобен если ты до этого работал с dtrace
Бедные солярадмины, и тут их хроническая необучаемость вылезает.
берем - аккуратно патчим шаблончики из которых systemTap собирает свой модуль - и опа.. человечек сам грузит в ядро троянчик. Профит!
если для простейшей проверки необходимо поставить комплятор и собрать модуль местами очень кривой - это вроде как недостаток, а не достоинство.
это достоинство - тебя никогда не уволят! ;-)P.S. но bpftrace, по-моему, часть этого достоинства унаследует
он для другого - если ты не отлаживать собираешься, а кое-что подменить на ходу в чужом бинарнике, например.для отладки там слишком много закатывания солнца вручную, с dtrace все на порядок проще и удобнее. Поравда, это про старый, солярисовый - что там понаредизайнили, разбираться лично мне лень.
короче, если ты разработчик - тебе к dtrace, а если пришел что потырить ценное из чужой системы, то для тебя sytemtap.
>Для компиляции скриптов BPFtrace в байткод BPF применяется бэкенд на базе LLVM.Вот же.. нет что бы gcc использовать.