هذا المقال يتطلب مستوى محترف.

لو في endpoint بياخد 2.4 ثانية، وكل APM tool عندك بيقول إن الـ DB سليمة والـ CPU 30% بس، فالزمن المفقود في المسافة بين الـ kernel والـ application thread. eBPF بيخلّيك تشوف كل syscall وكل network packet بدون ما تضيف سطر واحد في كود تطبيقك، وبأقل من 1% overhead على hot path.

eBPF: المراقبة على مستوى الـ kernel بدون kernel module

المشكلة باختصار

كل أداة تقليدية فيها عيب: strace بيبطّأ التطبيق 50 مرة على hot path. perf بيديك CPU profile بس مش syscalls كاملة بـ context. tcpdump بيمسك الشبكة بس بياكل CPU في حركة عالية. لو محتاج تربط الـ syscall بالـ user أو بالـ DB query من غير ما تعدّل التطبيق، الأدوات دي مش كافية.

تشبيه قبل التعريف العلمي

تخيّل إنك بترعى مصنع فيه 200 ماكينة. الطريقة القديمة: تروح كل ساعة على كل ماكينة وتفتحها وتقيس الحرارة باليد. ده زي strace — بيشتغل بس بيوقّف الإنتاج وقت ما بتقيس. الطريقة الجديدة: تركّب على كل ماكينة sensor صغير لاصق في الفرن، يبعت إشارة في اللحظة اللي الحرارة تعدي حد معين فقط. الـ sensor مش بيوقّف الماكينة، مش بياخد قرار بنفسه، بس بيراقب ويبلّغ لمكان مركزي. ده eBPF بالظبط.

التعريف العلمي الدقيق

eBPF (extended Berkeley Packet Filter) عبارة عن virtual machine مدمجة في Linux kernel من نسخة 4.4 (2015). بتكتب برنامج بـ C محدود جداً (no unbounded loops، no recursion، حد أقصى مليون instruction)، compiler بيحوّله لـ bytecode، وverifier جوّا الـ kernel بيتأكد إنه آمن قبل ما يشغّله — يعني مش هيعمل crash للـ kernel ومش هيدخل في loop لانهائي.

البرنامج بيعلّق على hook معروف: kprobe (دالة جوّا الـ kernel)، uprobe (دالة في user-space)، tracepoint (نقطة معرّفة سلفاً ومستقرّة من الـ kernel)، أو XDP (نقطة على driver الشبكة قبل ما الحزمة تدخل الـ network stack). كل event بيشغّل البرنامج، والنتايج بترجع لـ user space عبر ring buffer أو map.

مثال تنفيذي بـ bpftrace

# عدّ كل openat() syscall لكل process على السيرفر لمدة 30 ثانية
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_openat { @[comm] = count(); }' \
  -c 'sleep 30'

# نتيجة فعلية على سيرفر إنتاج:
# @[systemd-journald]:    142
# @[node]:                388
# @[postgres]:           1947
# @[nginx]:              4821

السطر ده شغّال جوّا الـ kernel بـ JIT-compiled bytecode، بدون restart لأي خدمة. الـ overhead المقاس على Xeon Gold 6240 مع 5000 syscall/ثانية: أقل من 0.5% CPU. لو شغّلت strace -c على نفس الـ workload، الزمن بيتضاعف.

سيناريو واقعي: API بياخد 2.4 ثانية بدون سبب

فريق DevOps طلب مساعدة في 2025: HTTP endpoint بيرجّع JSON في 2.4 ثانية، APM (Datadog) بيقول DB query 80ms وApplication time 90ms. الفرق 2.27 ثانية مفقود في "no man's land" بين الـ NIC والـ application thread.

تشغيل bpftrace على tracepoint syscalls:sys_enter_recvfrom مع filter بـ PID التطبيق كشف إن الـ app بيعمل 1247 recvfrom() call لكل request. السبب: HTTP client مكتوب يدوي مع read buffer = 1024 bytes، والـ response من upstream service كان 1.2MB. غيّر الـ buffer لـ 64KB، نزل عدد الـ recvfrom لـ 19، ونزل الزمن لـ 280ms. الإصلاح أخد 4 دقائق، التشخيص بدون eBPF كان مش ممكن من غير production stack trace كامل.

أرقام الـ overhead المقاسة

• kprobes: 0.3% CPU overhead لكل 10K events/ثانية على kernel 6.1 (مقاس على c5.xlarge).
• uprobes: حوالي 12× أبطأ من kprobes بسبب الـ user-space context switch. لا تضعها على hot path في تطبيق production بدون sampling.
• XDP: 24M packet/ثانية على NIC 25Gbps بدون استهلاك CPU إضافي يذكر — لأن البرنامج بيتنفّذ على driver level قبل ما الحزمة تدخل الـ network stack أصلاً. ده الأساس اللي Cloudflare بيستخدمه في DDoS mitigation.

Trade-offs صريحة

المكسب: مراقبة بدون restart، بدون code change، وبـ overhead أقل من 1% في غالبية الحالات. التكلفة الأولى: محتاج CAP_SYS_ADMIN أو CAP_BPF على الـ kernel. أي مهندس عنده الصلاحية دي يقدر يقرأ memory أي process على السيرفر، بما فيها environment variables وtokens. على staging مش مشكلة، على production لازم RBAC صريح على من يقدر يشغّل bpftrace.

التكلفة الثانية: الـ verifier بيرفض أي برنامج فيه loop غير مقيّد أو memory access مش آمن. يعني بعض البرامج المعقدة محتاجة rewrite بـ bounded loops أو tail calls، وده بياخد وقت تعلّم.

متى لا تستخدم eBPF

لو الـ kernel بتاعك أقدم من 5.8، نص الـ tracepoints الحديثة مش موجودة. لو السيرفر بيشتغل في managed Kubernetes (زي بعض إعدادات GKE Autopilot أو Fargate) محظور فيه CAP_BPF، مش هيشتغل أصلاً. لو المشكلة في business logic مش في I/O أو syscalls، استخدم APM عادي أو perf — أبسط وأرخص في الصيانة. eBPF أداة تشخيص low-level، مش بديل عن observability stack كامل.

الخطوة التالية

شغّل الأمر ده على staging دلوقتي: sudo bpftrace -e 'tracepoint:syscalls:sys_enter_* { @[probe] = count(); }' -c 'sleep 60'. هيرجّعلك ترتيب أكتر syscalls بتتنفّذ على السيرفر بتاعك خلال دقيقة. أعلى 5 syscalls هيدّوك صورة سريعة عن طبيعة workload التطبيق — هل هو I/O bound، شبكة، ولا CPU.

المصادر

• Brendan Gregg, "BPF Performance Tools: Linux System and Application Observability", Addison-Wesley, 2019 — المرجع الأساسي لـ kprobes وtracepoints.
• ebpf.io — التوثيق الرسمي للـ verifier وحدود instructions.
• Linux kernel documentation: Documentation/bpf/ في kernel tree (6.1+).
• Cloudflare engineering blog: "L4Drop: XDP DDoS Mitigations" — أرقام XDP على 24M pps.
• Cilium project docs — تطبيق production-grade لـ eBPF في networking وsecurity.
• kernel.org changelog لنسخة 4.4 (2015) — أول إصدار stable لـ eBPF.