المستوي: مبتدئ

لو محتاج تعرف بالظبط أي system call بياكل CPU السيرفر، أو أي ملف بيتفتح كل ثانية، أو أي packet داخل أي pod في Kubernetes، eBPF بيوريك ده كله بأمر واحد. بدون ما تعدّل سطر كود في تطبيقك، وبدون ما تعمل restart للسيرفر، وبـ overhead أقل من 2%.

eBPF للمبتدئ: شوف كل syscall على السيرفر بدون تعديل سطر كود

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

السيرفر بيعمل CPU 87% فجأة، والـ logs نضيفة، وكل dashboard بتاعك بيقولك "كله تمام". الطرق التقليدية للتشخيص بتطلب منك تنزّل agent جديد، أو تشغّل strace اللي بيبطّأ التطبيق 3x، أو تعدّل الكود علشان تضيف tracing. الثلاثة دول مش حلول، دول تنازلات. eBPF بيخلّيك تشوف اللي بيحصل جوّا الـ kernel نفسه، في الإنتاج مباشرة، بـ overhead صغير جدًا.

مثال يقرّب الفكرة

تخيّل إنك مدير مطعم كبير وفيه 40 جرسون شغّالين. لما طلب يتأخر، فيه 3 طرق تعرف بيها السبب:

• الطريقة الأولى: توقف كل جرسون وتسأله "إنت بتعمل إيه دلوقتي؟". بتوقف شغل الكل (= strace).
• الطريقة الثانية: تطلب من كل جرسون يكتب يومية مفصّلة. وقت ضايع وورق كتير (= application logging يدوي).
• الطريقة الثالثة: تحط كاميرا صامتة في السقف بتسجّل حركة الكل بدون ما تأثّر عليهم. ده eBPF.

الكاميرا (eBPF) شايفة كل حاجة من فوق، بتكلفة بسيطة، وبدون تعديل في طريقة شغل الجرسون.

ما هو eBPF علميًا

eBPF (extended Berkeley Packet Filter) هو virtual machine صغير جوّا الـ Linux kernel بيشغّل برامج موقّعة وآمنة عند نقاط محددة (probes) في الكيرنل. لمّا syscall زي open() بيتنفّذ، الكيرنل بيشغّل برنامج eBPF بتاعك قبل أو بعد الاستدعاء، وبيمرّر له الـ context كامل. البرنامج بيتجمّع لـ bytecode بيتحقق منه verifier (بيمنع الـ loops اللانهائية واللي ممكن يعمل crash للكيرنل) وبعدين JIT compiler بيحوّله لـ native instructions.

النتيجة: monitoring جوّا الكيرنل، بدون kernel modules خطرة، وبدون لمس كود التطبيق. التقنية موجودة من 2014 لما Alexei Starovoitov أضاف eBPF لـ kernel 3.18، ودلوقتي بتشغّل Cilium وFalco وPixie وDatadog، وKubernetes networking في Google.

مثال تنفيذي قابل للنسخ

هنشغّل أبسط أداة eBPF اسمها bpftrace. الأمر اللي تحت بيعرض كل process بيفتح ملف على السيرفر، لحظة بلحظة:

# تركيب bpftrace على Ubuntu 22.04+
sudo apt-get install -y bpftrace

# اعرض كل ملف بيتفتح + اسم الـ process
sudo bpftrace -e '
  tracepoint:syscalls:sys_enter_openat {
    printf("%-16s %s\n", comm, str(args->filename));
  }
'

# مخرج فعلي بعد ثانيتين:
# nginx            /etc/nginx/conf.d/api.conf
# postgres         /var/lib/postgresql/16/main/pg_stat_tmp/global.stat
# python3          /home/app/.cache/configstore.json
# node             /app/node_modules/express/package.json

الأمر فوق بيشتغل على سيرفر إنتاج فعلي بدون restart لأي خدمة، وبدون ما تنصّب agent، وبيقفل لما تضغط Ctrl+C. الـ overhead الحقيقي على CPU؟ أقل من 1.5% لمعظم الـ workloads حسب قياسات Brendan Gregg في Netflix.

الأرقام اللي تستحق تعرفها

• overhead في الإنتاج: 0.5% إلى 2% لمعظم الـ probes. strace العادي بيوصل لـ 50% إلى 300%.
• زمن التركيب: دقيقتين على Ubuntu أو Debian حديث. صفر تعديلات على التطبيق.
• أقل kernel مدعوم بشكل عملي: 4.18+ (CentOS 8 و RHEL 8). الميزات الكاملة من 5.4+.
• أدوات production جاهزة: bpftrace (CLI سريع)، bcc (Python frontend)، Cilium (networking لـ Kubernetes)، Falco (runtime security)، Pixie (auto-tracing لـ K8s).
• النشاط في الكيرنل: أكتر من 28 ألف commit مرتبط بـ BPF منذ 2014، حسب لوحة kernelnewbies.org.

الـ trade-offs الحقيقية

كل أداة قوية ليها ثمن. eBPF كذلك:

• منحنى تعلم: bpftrace one-liner سهل جدًا. لكن كتابة eBPF program متقدم بـ libbpf-go أو CO-RE بتاخد أسبوعين على الأقل لمهندس متوسط.
• اعتماد على نسخة الكيرنل: probe على tracepoint مستقر آمن. probe على kprobe جوّا دالة كيرنل ممكن يكسر بعد upgrade.
• صلاحيات root: معظم الـ probes محتاجة CAP_BPF أو root كامل. ده مش مناسب لكل sandboxed environment.
• قراءة فقط افتراضيًا: eBPF مش بديل عن APM زي Datadog أو New Relic. هو بيكمّلهم، مش بياخد مكانهم.

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

eBPF مش الحل لكل مشكلة. ابعد عنه في الحالات دي:

• تطبيقك شغّال على macOS أو Windows في الإنتاج. eBPF لينكس فقط (eBPF-for-Windows لسه preview).
• محتاج distributed tracing بين 7 microservices. استخدم OpenTelemetry. eBPF بيشوف node واحد فقط.
• مفيش عندك صلاحية root على الـ nodes (managed PaaS زي Heroku أو Vercel أو Railway).
• المشكلة في كود التطبيق نفسه (logic bug). eBPF بيشوف syscalls، مش بيشوف ليه function رجّعت قيمة غلط.

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

افتح terminal على أي سيرفر Linux عندك دلوقتي، نزّل bpftrace، وشغّل الأمر اللي فوق لمدة دقيقة. هتشوف بنفسك أكتر من 100 ملف بيتفتحوا في الثانية، وهتتفاجأ من حجم الـ syscalls اللي بتحصل بدون ما حد يلاحظ. لو شفت process مش معروف بيفتح ملفات حساسة، ده أول كشف أمني مجاني من eBPF. بعد كده اقرأ "BPF Performance Tools" لـ Brendan Gregg، مرجع لازم لو هتعتمد على eBPF في الإنتاج.

المصادر

• التوثيق الرسمي لـ eBPF: ebpf.io/what-is-ebpf
• توثيق bpftrace: github.com/bpftrace/bpftrace
• Linux Kernel BPF documentation: kernel.org/doc/html/latest/bpf
• Brendan Gregg, "BPF Performance Tools", Addison-Wesley 2019 (قياسات Netflix لـ overhead).
• Cilium production deployments: docs.cilium.io
• Falco runtime security: falco.org/docs
• ورقة Alexei Starovoitov الأصلية على lwn.net: lwn.net/Articles/603983