ردیابی سیستمها در سطح هسته (Kernel Tracing) با eBPF بدون دستکاری کد برنامه

چرا ابزارهای سنتی مانند strace و ماژولهای کرنل در محیط پروداکشن خطرناک هستند؟

وقتی یک میکروسرویس در محیط پروداکشن هر چند ساعت یکبار دچار پرش ناگهانی تاخیر (p99 Latency Spike) میشود و در لاگهای برنامه هیچ خطایی ثبت نشده است، ریشه مشکل معمولاً در درون هسته سیستمعامل (رتبهبندی صف دیسک NVMe، ارسال مجدد بستههای TCP یا قفلهای سطح کرنل) نهفته است. رویکردهای قدیمی برای مشاهده درون کرنل دارای دو نقص کشنده هستند:

• فاجعه عملکردی `strace` (مبتنی بر `ptrace`): ابزار strace با استفاده از مکانیسم دیباگ ptrace، در ورود و خروجِ تکتک فراخوانهای سیستمی (Syscalls) پروسه هدف را به طور کامل متوقف (SIGSTOP) کرده و دو بار Context Switch به پروسه دیباگر انجام میدهد. اجرای strace روی یک دیتابیس یا وبسرور پرترافیک، توان عملیاتی آن را تا ۱۰ الی ۵۰ برابر کاهش داده و عملاً سرور را از کار میاندازد!
• ریسک کرش کل سرور با ماژولهای کرنل (`LKM`): نوشتن ماژول کرنل به زبان C دسترسی مستقیم به فضای کرنل میدهد، اما یک باگ کوچک در اشارهگر (Null Pointer Dereference) یا حلقه بینهایت، بلافاصله باعث Kernel Panic و خاموش شدن کل سرور فیزیکی میشود.

انقلاب eBPF: اجرای کدهای امن و کامپایلشده (JIT) در قلب هسته لینوکس

فناوری eBPF (Extended Berkeley Packet Filter) همان کاری را برای کرنل لینوکس انجام داد که جاوااسکریپت و WebAssembly برای مرورگرها انجام دادند: امکان تزریق و اجرای برنامههای رویدادمحور در یک محیط ایزوله (Sandbox) داخل فضای کرنل، بدون نیاز به تغییر سورس کرنل، ریاستارت کردن سرور یا دستکاری کدهای اپلیکیشن!

چرخه حیات یک برنامه eBPF از سه سد امنیتی و عملکردی عبور میکند:

• ۱. ممیز ایستا (The In-Kernel eBPF Verifier): پیش از آنکه بایتکد eBPF اجازه بارگذاری در کرنل را پیدا کند، Verifier تمام مسیرهای ممکن اجرای کد را به صورت یک گراف جهتدار غیرمدور (DAG) پیمایش میکند. اگر کد شما دارای حلقه نامحدود باشد، به حافظهای خارج از مرز مجاز اشاره کند یا اشارهگری را بدون بررسی NULL بخواند، کرنل از بارگذاری آن جلوگیری میکند. بنابراین کرش کردن کرنل توسط eBPF از نظر ریاضی غیرممکن است.
• ۲. کامپایلر درجا (JIT Compiler): پس از تایید Verifier، بایتکد eBPF مستقیماً به دستورالعملهای بومی پردازنده (Native x86_64 یا ARM64) ترجمه میشود تا با سرعت کدهای اصلی کرنل و بدون سربار مفسر اجرا گردد.
• ۳. ساختارهای داده اشتراکی (eBPF Maps & Ring Buffers): به جای ارسال میلیونها رویداد خام به فضای کاربر، برنامه eBPF آمارها، شمارندهها و هیستوگرامهای لگاریتمی را مستقیماً در داخل حافظه کرنل (BPF Maps) تجمیع کرده و فضای کاربر تنها خلاصه نتایج را با سربار نزدیک به صفر میخواند.

نقاط اتصال (Hook Points): تفاوت kprobes، tracepoints، uprobes و XDP

برنامههای eBPF تا زمانی که رویدادی رخ ندهد هیچ پردازندهای مصرف نمیکنند و میتوانند به چهار لایه کلیدی متصل شوند:

• نقاط `tracepoints` (پایدارترین در کرنل): نقاط ردیابی رسمی که توسط توسعهدهندگان لینوکس در کدهای شبکه، زمانبند و دیسک قرار داده شدهاند و API آنها بین نسخههای مختلف کرنل ثابت است.
• نقاط `kprobes` / `kretprobes`: امکان اتصال پویا به ابتدا و انتهای هر تابع دلخواه در داخل کرنل لینوکس (بیش از ده هزار تابع داخلی).
• نقاط `uprobes`: اتصال به توابع برنامههای فضای کاربر (مثلاً رهگیری تابع رمزنگاری SSL_write در کتابخانه OpenSSL برای دیدن ترافیک رمزگشاییشده پیش از رمزنگاری بدون نیاز به پراکسی!).
• لایه `XDP (eXpress Data Path)`: اجرای برنامه eBPF مستقیماً در درایور کارت شبکه پیش از آنکه کرنل حتی ساختار حافظه پکت (sk_buff) را تخصیص دهد؛ قادر به فیلتر کردن دهها میلیون پکت در ثانیه برای دفع حملات DDoS.

پیادهسازی ردیاب میکروثانیهای تاخیر دیسک (Block I/O Latency Histogram) با BCC و پایتون

در کد زیر، با استفاده از چارچوب BCC (BPF Compiler Collection) در پایتون، یک برنامه C سطح کرنل نوشته شده است که به نقاط block_rq_issue (لحظه ارسال درخواست به کنترلر دیسک NVMe/SSD) و block_rq_complete (لحظه دریافت وقفه پایان عملیات دیسک) متصل میشود، زمان دقیق را با دقت نانوثانیه در یک جدول هش کرنلی محاسبه کرده و هیستوگرام لگاریتمی (log2) تاخیر واقعی دیسک را در داخل هسته لینوکس میسازد:

import time
from bcc import BPF

# In-Kernel eBPF C Program: Zero context-switch aggregation using BPF Hash & Histogram Maps
EBPF_KERNEL_SOURCE = """
#include <uapi/linux/ptrace.h>
#include <linux/blk-mq.h>

struct req_key_t {
    u32 dev;
    u64 sector;
};

BPF_HASH(start_ts_map, struct req_key_t, u64);
BPF_HISTOGRAM(io_latency_hist_us, u64);

TRACEPOINT_PROBE(block, block_rq_issue) {
    struct req_key_t key = {};
    key.dev = args->dev;
    key.sector = args->sector;

    u64 ts = bpf_ktime_get_ns();
    start_ts_map.update(&key, &ts);
    return 0;
}

TRACEPOINT_PROBE(block, block_rq_complete) {
    struct req_key_t key = {};
    key.dev = args->dev;
    key.sector = args->sector;

    u64 *start_ns = start_ts_map.lookup(&key);
    if (start_ns == 0) {
        return 0;  // Missed issue event prior to tracer attachment
    }

    u64 delta_us = (bpf_ktime_get_ns() - *start_ns) / 1000;
    io_latency_hist_us.increment(bpf_log2l(delta_us));
    start_ts_map.delete(&key);
    return 0;
}
"""

class KernelBlockIOProfiler:
    """
    Attaches eBPF tracepoints to the Linux Block I/O subsystem
    to measure hardware NVMe/SSD request latency in microseconds.
    """
    def __init__(self):
        print('[*] Compiling and verifying eBPF program inside Linux Kernel...')
        self.bpf = BPF(text=EBPF_KERNEL_SOURCE)
        self.hist_map = self.bpf.get_table('io_latency_hist_us')

    def stream_latency_histograms(self, interval_sec: int = 5, iterations: int = 12) -> None:
        print(f'[*] Tracing Block I/O hardware latency every {interval_sec}s. Press Ctrl+C to stop.')
        for _ in range(iterations):
            try:
                time.sleep(interval_sec)
                print(f'\n--- Block I/O Latency Distribution ({time.strftime("%H:%M:%S")}) ---')
                self.hist_map.print_log2_hist('Latency (microseconds)')
                self.hist_map.clear()
            except KeyboardInterrupt:
                break

if __name__ == '__main__':
    profiler = KernelBlockIOProfiler()
    profiler.stream_latency_histograms()