Перейти к содержимому 
Я покажу, как bpftrace в средах Linux значительно сокращает время, необходимое для выявления причины сбоя, и при этом Ядро-сигналы. Вместо того чтобы гадать, я измеряю системные вызовы, задержки ввода-вывода и сетевые события в режиме реального времени в ЭБПФ-контекст — без остановки служб.
Центральные пункты
Приведенные ниже ключевые моменты дают краткий обзор основных тем данной статьи.
- Глубокий анализ в системных вызовах, операциях ввода-вывода и сетевых операциях непосредственно из ядра
- Низкие накладные расходы благодаря безопасным программам eBPF в ядре
- Быстрое сужение круга поиска связанных с узкими местами в процессах, ввода-вывода и базах данных
- Гибкое отслеживание с фильтрами, гистограммами и трассировками стека
- Рабочий процесс в практике для экстренных ситуаций — в течение нескольких минут
Почему bpftrace позволяет быстрее выявлять проблемы на хостинге
В современных хостинг-стеках многие сервисы конкурируют за Ресурсы, в то время как классические информационные панели часто отображают лишь поверхностные показатели. Я углубляюсь на один уровень: bpftrace отслеживает системные вызовы, точки трассировки и функциональные хуки и показывает мне, что на самом деле тормозит работу. Таймауты при незаметной загрузке ЦП часто указывают на задержки ввода-вывода или блокирующие вызовы. Именно здесь bpftrace показывает свои преимущества, предоставляя подсчёты, гистограммы задержек и трассировки стека непосредственно из Ядро. Таким образом, я сопоставляю источники нагрузки с конкретными процессами, контейнерами или запросами и принимаю целенаправленные меры.
Как взаимодействуют eBPF и bpftrace
eBPF запускает небольшие, проверенные программы в Ядро и предоставляет события из первоисточника. bpftrace компилирует скрипты во время выполнения в байт-код eBPF и присоединяет их к пробам, фильтрам и действиям. Например, я выбираю точку трассировки для чтения файлов, фильтрую по имени процесса и агрегирую задержки в гистограмме. Схема „проба — фильтр — действие“ остаётся понятной, даже если я измеряю несколько сигналов одновременно. Таким образом, за считанные минуты я создаю наблюдение, которое даёт мне решающую Индикаторы поставки.
Краткие фразы на случай чрезвычайной ситуации
В чрезвычайных ситуациях важна скорость. Я использую лаконичные фразы, которые за считанные секунды позволяют выявить закономерность. Вот несколько моих проверенных вариантов для начала:
# Подсчёт „громких“ обращений к файлам по имени процесса (очистка каждые 5 секунд)
bpftrace -e 'tracepoint:syscalls:sys_enter_openat { @[comm] = count(); }
interval:s:5 { clear(@); }'
# Гистограмма задержек при чтении файлов (по процессам)
bpftrace -e '
kprobe:vfs_read { @ts[tid] = nsecs; }
kretprobe:vfs_read /@ts[tid]/ {
@lat[comm] = hist(nsecs - @ts[tid]);
delete(@ts[tid]);
}'
# Объединение повторных передач TCP с помощью стеков ядра
bpftrace -e 'tracepoint:tcp:tcp_retransmit_skb { @[kstack] = count(); }'
# Суммирование времени SoftIRQ (окно 10 с)
bpftrace -e '
tracepoint:irq:softirq_entry { @t[args->vec] = nsecs; }
tracepoint:irq:softirq_exit /@t[args->vec]/ {
@soft[args->vec] = sum(nsecs - @t[args->vec]);
delete(@t[args->vec]);
}
interval:s:10 { print(@soft); clear(@soft); }'
#: отображение нагрузки accept() на базе данных или веб-сервере
bpftrace -e 'tracepoint:syscalls:sys_enter_accept4 /comm=="mysqld" || comm=="nginx"/ { @[comm] = count(); }'
С помощью этих „зондов“ я быстро выясняю, не открывает ли какой-либо сервис аномально большое количество файлов, не тормозит ли ввод-вывод или не перегружает ли сеть. Затем я уточняю фильтры, чтобы PID, имена процессов или пути.
Диагностика процессов и ресурсов на рабочих серверах
Если отдельная учетная запись или контейнер замедляет работу общего сервера, я подсчитываю количество системных вызовов на Процесс и нахожу „шумных“ виновников. Заметно большое количество вызовов execve указывает на чрезмерный запуск процессов, что, например, свидетельствует о некорректных заданиях cron. Если какой-то сервис открывает огромное количество файлов, я сразу это замечаю и с помощью фильтров ограничиваю проверку определёнными путями. Для сильно загруженных веб-серверов это просто на вес золота, потому что я быстро выявляю источники помех. Те, кто хочет глубже погрузиться в идеи по инструментарию, могут дополнительно ознакомиться с подходами к инструменты анализа eBPF и применяет этот принцип к собственным хостам.
Представление контейнеров и Kubernetes с использованием cgroups
На хостах с поддержкой нескольких клиентов или на хостах Kubernetes мне требуется четкое разделение клиентов. Для этого bpftrace предоставляет мне cgroup-Точка зрения как ключ:
# Объединение системных вызовов по cgroup (контейнеру) и имени процесса
bpftrace -e 'tracepoint:syscalls:sys_enter_openat { @[cgroup, comm] = count(); }'
Так я могу определить, какой контейнер генерирует шум, без необходимости вручную собирать отдельные PID. Для более детального анализа я применяю дополнительные фильтры:
# Рассматривать только PHP-FPM (например, в контейнере приложения)
bpftrace -e 'tracepoint:syscalls:sys_enter_execve /comm=="php-fpm"/ { @[pid] = count(); }'
В Kubernetes я часто измеряю Узел и сгруппируйте по cgroup. Соответствие между идентификаторами cgroup и именами под/контейнеров я фиксирую в своём руководстве по эксплуатации (kubectl/CRI), чтобы можно было чётко соотносить результаты измерений.
Надежное измерение задержек ввода-вывода и файловой системы
Медленная загрузка страниц, несмотря на „нормальный“ процессор, часто указывает на ВВОД/ВЫВОД-узкие места. Я измеряю операции чтения и записи для каждого процесса, фиксирую медленные пути и строю гистограммы задержек. В средах WordPress это позволяет мне определить, что именно снижает пропускную способность: множество мелких PHP-файлов или крупные медиафайлы. После этого я решаю, что следует применить в первую очередь: кэширование, кэш опкода PHP или настройку файловой системы. Те, кто хочет углубиться в тему, найдут подробную информацию о Задержки доступа к дискам в системе хранения данных и может целенаправленно корректировать точки измерения.
Отображение времени ожидания вне ЦП и времени ожидания блокировки
Не всякое время ожидания связано с вводом-выводом: потоки могут вне процессора блокировать — например, с помощью Locks. Для этого я использую события Futex и Scheduler.
# Время ожидания Futex (конфликт блокировок) в виде гистограммы
bpftrace -e '
tracepoint:syscalls:sys_enter_futex { @ts[tid] = nsecs; }
tracepoint:syscalls:sys_exit_futex /@ts[tid]/ {
@futex[comm] = hist(nsecs - @ts[tid]);
delete(@ts[tid]);
}'
С помощью таких профилей я вижу, ждут ли блокировок рабочие процессы PHP-FPM или потоки БД. В сочетании с гистограммами ввода-вывода я отключаю Хранение- от Concurrency-проблемы.
Отображение сетевых ошибок, SoftIRQ и повторных передач
Я часто связываю жалобы на периодические таймауты с Сеть-сигналы. Я отслеживаю повторные передачи TCP, события RST и разрывы соединений непосредственно в ядре. Кроме того, я обращаю внимание на SoftIRQ, поскольку перегруженные сетевые очереди оставляют там следы. Сочетание повторных передач и увеличения времени обработки softIRQ указывает на потери пакетов, переполнение буферов или проблемы с QoS. Хорошим дополнением к поиску причин являются справочные статьи по SoftIRQ и пропускная способность сети, которые я связываю с результатами измерений bpftrace.
Пример из практики: хостинг WordPress с периодическими ошибками 504 «Таймаут»
На виртуальном сервере возникает ошибка 504, загрузка процессора составляет всего 35%. Моя последовательность действий:
- Гипотеза „Сеть или ввод-вывод“. Запускаю повторные передачи и измерение времени SoftIRQ. Результат: мало повторных передач, SoftIRQ стабильны.
- Переход к вводу-выводу: гистограмма задержек vfs_read показывает длинный хвост до 80 мс для php-fpm. Много вызовов openat на каждый запрос.
- Фильтр по путям в папках wp-content и wp-includes: преобладают бесчисленные мелкие операции чтения файлов.
- Контрольная проверка локов: Futex-Histo без отклонений — конфликтов доступа к локам не наблюдается.
- Меры: настроить конфигурацию OPCache, более активно кэшировать статические ресурсы. После этого показатели openat и задержки снизятся.
Если время активного трассирования составляет менее 15 минут, становится ясно: дело не в сети, а в Ввод-вывод файлов и отсутствие кэширования вызывают таймауты.
Базы данных и PHP-FPM: быстрое выявление узких мест
В случае с MySQL/MariaDB я анализирую системные вызовы, блокировки и задержки ввода-вывода Процессы DB . Я отслеживаю фазы accept/connect, чтобы увидеть, не задерживаются ли соединения или не зависают ли TLS-рукопожатия. В случае с PHP-FPM я проверяю, не наблюдается ли необычно высокая частота вызовов execve и операций с файлами, что указывает на отсутствие кэширования. С помощью трассировок стека для определённых системных вызовов я определяю, в каком месте кода задерживаются запросы. Таким образом, я пошагово исключаю сеть, приложение и базу данных и нахожу наиболее узкое Место.
Передовой опыт по обеспечению высокой производительности серверов
Я начинаю каждый трассировку с четкого Постановка задачи и ограничиваю набор данных с помощью фильтров. Временные ограничения или интервалы позволяют удерживать объем данных в разумных пределах. Для повторяющихся анализов я сохраняю скрипты с удобными фильтрами по умолчанию, такими как PID, cgroup или имена процессов. Перед использованием на хостах клиентов я тестирую сложные скрипты на тестовых системах. Таким образом, накладные расходы остаются минимальными, и я предотвращаю ненужные Побочные эффекты.
Качество измерений, накладные расходы и предельные значения на практике
При использовании целевых проб bpftrace обеспечивает нагрузку на ЦП в пределах однозначного процента, если соблюдать следующие условия:
- Фильтрация на входе: Я фильтрую на раннем этапе (например, по comm/PID), а не отбираю данные уже в Maps.
- Выборка: Для очень горячих проб я использую отбор проб, например, 1% событий:
tracepoint:syscalls:sys_enter_openat / rand() % 100 == 0 / { @[comm] = count(); } - Экономное использование трассировок стека: kstack/ustack — только при необходимости: сначала посчитать, потом углубляться.
- Размер буфера: В моменты пиковой нагрузки я увеличиваю размер кольцевого буфера:
export BPFTRACE_PERF_RB_PAGES=4096 - Не задерживайтесь у окна: Интервалы (5–30 с) и четко обозначенное окончание позволяют избежать путаницы в данных.
Если я вижу „пропущенные события“, я увеличиваю буфер, уменьшаю глубину стека или ужесточаю фильтры. Для обеспечения точности я предпочитаю Точки трассировки (стабильная версия ABI) по сравнению с kprobes (названия функций ядра могут отличаться).
Безопасность, управление и правила многопользовательской архитектуры
На виртуальных хостингах я строго слежу за Защита данных и четкие рамки. Я отслеживаю технические сигналы, а не данные клиентов, и документирую причину, объем и продолжительность. Для многопользовательских сред я устанавливаю чёткие правила: кто имеет право запускать трассировку, какие фильтры необходимы и когда я прекращаю трассировку. Журналы, содержащие конфиденциальные пути, я минимизирую или псевдонимизирую. Таким образом я получаю полезные технические данные, не нарушая границ арендаторов, и соблюдаю Соответствие требованиям в.
Установка и системные требования на современных серверах Linux
Для bpftrace я использую Linux 5.x, поскольку функции и Стабильность там заметно лучше, хотя 4.9 считается нижним пределом. Я устанавливаю bpftrace через apt или dnf и добавляю заголовочные файлы ядра, как только возникает необходимость в более сложных пробах. Затем я проверяю настройки cgroup, среды выполнения контейнеров и модули безопасности, регулирующие доступ к пробам. Краткий тест с простыми точками трассировки позволяет убедиться, что сигнатуры и символы совпадают. Таким образом, ничто не мешает структурированному запуску, и я могу приступить к первым Измерения ехать.
Переносимость: BTF, разрешение символов и стабильные зонды
Для создания надежных скриптов я полагаюсь на BTF-Информация о типе (vmlinux), которая помогает bpftrace при определении полей. Если её нет, я предпочитаю использовать точки трассировки вместо kprobes. Для uprobes (Userland) мне нужны бинарные файлы без удаления символов или отдельные отладочные символы — особенно в случае с PHP-FPM или mysqld это оправдано. Я проверяю версии с помощью „bpftrace –info“ и включаю в скрипты небольшой блок на случай несовместимости, если имена событий различаются в зависимости от ядра.
Рабочий процесс в практике: от симптома к причине за 15 минут
Сначала я сформулирую Гипотеза: Сеть, ввод-вывод, ЦП или БД? Тогда я запускаю по одному быстрому трасу на наиболее вероятном уровне, например, на уровне повторных передач или задержек при работе с файлами. Если в первые минуты прослеживается какая-то закономерность, я уточняю фильтры, добавляю трассировки стека и ограничиваю время выполнения. Если подозрение подтверждается, я провожу измерения глубже в затронутом сервисе и фиксирую только релевантные пути. Благодаря этому «коридору» я избегаю «полета вслепую» и быстро добираюсь до самого узкого места Причина.
Руководство: 15-минутная первоначальная реакция
- 0–2-я минута: Выбрать гипотезу (сеть/ввод-вывод/ЦП/БД). Запустить Baseline-One-Liner.
- 3–5-я минута: Выявление первых аномалий (например, высокое значение openat, повторные передачи, гистограммы Futex).
- 6–8-я минута: Улучшить фильтры (comm/PID/cgroup, пути) и добавить гистограммы задержек.
- 9–12-я минута: Включить трассировку стека только в «горячих точках», чтобы выявить проблемные участки кода.
- 13–15-я минута: Определить меры (кэширование, ограничения, изменение настроек) и провести их краткое тестирование.
Сравнительная таблица: преимущества и польза в повседневной жизни
В следующей таблице приведены типичные пробы, сферу их применения и основные преимущества в контексте хостинга. Я использую их в качестве памятки, когда мне нужно быстро выбрать подходящий пункт измерения.
| Тип пробы | Используйте | Пример | Выгода |
|---|---|---|---|
| tracepoint:syscalls | Подсчет/фильтрация системных вызовов | sys_enter_openat, execve | „Громкие“ Процессы Найти |
| kprobe/kretprobe | Измерение функций ядра | vfs_read, tcp_retransmit | Ввод-вывод и сетьЗадержки видимый |
| uprobes/uretprobes | Отслеживание функций пользовательского уровня | Символы mysqld, php-fpm | Определение точек доступа DB/приложений |
| tracepoint:net/* | Выявление сетевых событий | Повторные передачи TCP, RST | Таймаут-Причины ограничить |
| perf events | Точка зрения процессора и планировщика | Профили «on-cpu» и «off-cpu» | Выявление узких мест в планировании |
Краткое изложение для администраторов и специалистов по DevOps
bpftrace выдает мне четкий Линза на сигналы ядра и приложений, которые часто упускаются при классическом мониторинге. Я начинаю с малого, применяю целенаправленную фильтрацию и контролирую время выполнения, чтобы результаты измерений оставались четкими. С помощью нескольких строк скрипта я выявляю шумы процессов, задержки при работе с файлами, повторные передачи по сети и время ожидания БД. Такой подход заметно сокращает среднее время устранения неисправностей (Mean Time to Resolution) на рабочих хостах. Те, кто интегрирует bpftrace в свой рабочий процесс, целенаправленно устраняют инциденты на хостинге и обеспечивают заметное повышение производительности веб-сайтов и API. отзывчивый.
