27 فبراير 2026 | وقت القراءة: 13 دقيقة 37 ثانية
المقدمة: النواة كبنية أساسية
لعقود من الزمن، كانت الملاحظة تعني إضافة رمز إلى تطبيقاتك. كنت تستقصي خدماتك باستخدام مكتبات المقاييس والسجلات المتتبعة المتتبعة عبر مسارات الاستدعاء الخاصة بك وتكوين ناقلات السجل على كل مضيف. كانت كل طبقة رؤية تأتي مع تكلفة: إدارة التبعيات وفوائد الأداء وتغييرات الرمز التي تحتاج إلى نشر والصيانة. تخطي نقطة نهاية وكان لديك نقطة عمياء. ترقية مكتبة وكنت تخاطر بكسر خط أنابيب الاستقصاء الخاص بك.
eBPF يغير هذه المعادلة بشكل أساسي. بدلاً من استقصاء التطبيقات، فإنك تستقصي النواة. كل استدعاء نظام، وكل حزمة شبكية، وكل وصول ملف، وكل عملية الوصول تمر عبر نواة Linux — و eBPF يسمح لك بالمراقبة والعمل على هذه الأحداث دون تعديل النواة نفسها أو التطبيقات التي تولدها. لا توجد تغييرات في الكود. لا توجد تبعيات SDK. لا توجد تنسيق نشر.
هذا ليس تحسين طفيف. إنها فئة قدرة مختلفة. عندما تعمل طبقة المراقبة الخاصة بك على مستوى النواة، فإنك ترى كل شيء — بما في ذلك الأشياء التي تختار التطبيقات عدم تسجيلها والاتصالات الشبكية التي تتجاوز شبكة الخدمة وكلاء الخاص بك والعمليات التي لا تعرف وقت التشغيل حول الحاوية عنها.
نضج نظام eBPF بسرعة خلال 2025 وإلى عام 2026. ما كان مجموعة من المشاريع البحثية والأدوات المتخصصة أصبح البنية الأساسية للإنتاج على نطاق واسع. يتعامل Cilium مع الشبكات لموفري السحابة الرئيسيين. يوفر Falco أمان وقت التشغيل لمجموعات Kubernetes في جميع أنحاء العالم. Tetragon يفرض سياسات الأمان مباشرة في النواة. وأدوات مثل Coroot توفر ملاحظة المكدس الكامل — مقاييس وسجلات وآثار والتنميط المستمر — من وكيل واحد مستند إلى eBPF يتطلب صفر تطبيق يتغير.
تشرح هذه المقالة ما هو eBPF وسبب أهميته للأمان والملاحظة وكيفية اعتماده عمليًا.
ما هو eBPF حقًا
يرمز eBPF إلى عامل فلتر بيرت بيركلي الممتد، على الرغم من أن الاسم معظمه تاريخي في هذه النقطة. تحرك eBPF الحديث إلى ما بعد تصفية الحزم.
في جوهره، eBPF هو آلة افتراضية داخل نواة Linux التي تشغل برامج الرمل في استجابة لأحداث النواة. يمكن لهذه البرامج مراقبة استدعاءات النظام وحركة الشبكة والعمليات الملف والعمليات الجدولة وأساسًا أي نشاط على مستوى النواة — دون كل ذلك دون تعديل النواة نفسها أو تطلب وحدات النواة.
نموذج السلامة
ما يجعل eBPF عمليًا هو نموذج السلامة الخاص به. قبل أن يعمل أي برنامج eBPF، يتحقق معامل النواة من ذلك بشكل شامل:
- لا حلقات غير مرتبطة: يجب أن تنهي البرامج. يرفض الفاحص برامج قد تعمل إلى أجل غير مسمى.
- لا الوصول إلى الذاكرة غير الصحيح: تم التحقق من كل إلغاء مؤشر. تجاوزات المخزن المؤقت مستحيلة.
- حدود حجم المكدس: للبرامج حجم مكدس ثابت (512 بايت)، منع استنزاف الرصيف.
- الوصول إلى دالة مساعدة: يمكن للبرامج استدعاء وظائف مساعدة النواة المعتمدة مسبقًا فقط، وليس رمز النواة التعسفي.
- متطلبات الامتياز: تحميل برامج eBPF يتطلب قدرات مناسبة (عادة
CAP_BPFأو الجذر).
يحدث هذا التحقق في وقت التحميل، وليس وقت التشغيل. بمجرد أن تمر برنامج على الفاحص، فإنها تعمل بسرعة قريبة من الأصلية دون فحوصات سلامة وقت التشغيل. النتيجة هي الملاحظة على مستوى النواة مع فوائد أداء لا تُذكر — عادة أقل من 1-2٪ من تأثير وحدة المعالجة المركزية للمراقبة الشاملة.
نقاط الاتصال
تعلق برامج eBPF على أحداث النواة المحددة تسمى الخطافات أو نقاط التعلق:
| نوع السنانير | حالة الاستخدام | مثال |
|---|---|---|
| kprobes | تتبع أي وظيفة النواة | مراقبة sys_open لتتبع الوصول إلى الملف |
| tracepoints | أحداث تتبع نواة مستقرة | تتبع إنشاء عملية عبر sched_process_exec |
| XDP | معالجة حزمة الشبكة | إسقاط الحزم الخبيثة قبل وصولها إلى مكدس الشبكة |
| TC | التحكم في حركة المرور | تطبيق سياسات الشبكة على مستوى الحاوية |
| LSM | خطافات وحدة أمان Linux | فرض سياسات الأمان على العمليات الملف |
| uprobe | تتبع وظيفة مساحة المستخدم | ملف تعريف وظائف التطبيق المحددة |
| perf events | عدادات أداء وحدة المعالجة المركزية | التنميط المستمر لـ CPU والذاكرة |
يتم ما يجعل eBPF قويًا جدًا نطاق نقاط التعلق. يمكن لوكيل واحد مستند إلى eBPF مراقبة حركة الشبكة وأصول الملف وتنفيذ العملية وحل DNS وأنماط استدعاء النظام في وقت واحد — مما يوفر عرضًا موحدًا والذي تقليديًا يتطلب خمسة أو ستة أدوات منفصلة.
eBPF للملاحظة: رؤية كل شيء
تتكون الملاحظة التقليدية من ثلاث أعمدة: المقاييس والسجلات والآثار. eBPF تمكن جميعها الثلاثة دون استقصاء، وتضيف رابعة — التنميط المستمر — وهذا غير عملي مع نهج مستوى التطبيق.
خرائط الخدمة بدون استقصاء
عندما تراقب eBPF اتصالات الشبكة على مستوى النواة، فإنها ترى كل اتصال TCP و UDP بين الخدمات — بما في ذلك الاتصالات التي تتجاوز شبكة الخدمة والمحاكاة الجانبية أو الاستقصاء على مستوى التطبيق. هذا يتيح الاكتشاف التلقائي للخدمة والخريطة الاعتماد.
الأدوات مثل Coroot استخدام هذه القدرة لإنشاء خرائط الطوبولوجيا المباشرة تظهر جميع تبعيات الخدمة. لا تغييرات في الكود المطلوبة. لا وعاء جانبي. لا تكوين لكل خدمة. نشر الوكيل، وفي غضون دقائق ترى أي خدمات تتواصل مع أي خدمات أخرى وكمون كل اتصال ومعدلات الأخطاء عبر كل مسار.
هذا قيم بشكل خاص لـ:
- التطبيقات الموروثة التي لا يمكن استقصاؤها دون جهد كبير
- الخدمات الخارجية حيث لا تتحكم في الكود
- بيئات Polyglot حيث تستخدم الخدمات المختلفة لغات وأطر عمل مختلفة
- تصحيح مشاكل الإنتاج حيث تسبب التبعيات غير المعروفة فشل متتال
مقاييس الروتوكول الذكية
eBPF لا ترى فقط اتصالات الشبكة — فهمها بروتوكول. بناء رؤوس الحزم على مستوى النواة، ويمكن لوكلاء eBPF استخراج المقاييس على مستوى التطبيق دون أي وعي بالتطبيق:
HTTP/HTTPS: طريقة الطلب والمسار وكود الحالة والكمون — معادل لما تحصل عليه من سجل الوصول، لكن الملتقطة على مستوى النواة لكل خدمة تلقائيًا.
بروتوكولات قاعدة البيانات: تم تحليل PostgreSQL و MySQL و Redis و MongoDB بروتوكول السلك لاستخراج كمون الاستعلام ومعدلات الأخطاء وعدد الاتصالات. هذا يعني أنك تحصل على مقاييس أداء قاعدة البيانات دون تثبيت أي وكيل مراقبة قاعدة بيانات أو تعديل سلاسل الاتصال.
gRPC: تتبع الكمون والأخطاء على مستوى الطريقة لخدمات gRPC، الملتقطة دون تعديل تكوين إطار عمل gRPC.
DNS: كمون الحل ومعدلات الفشل لكل بحث DNS، مساعدة في تحديد مشاكل DNS ذات الصلة التي يصعب تصحيحها مع الأدوات على مستوى التطبيق.
Kafka: قياسات تأخير المنتج والمستهلك الملتقطة على مستوى البروتوكول، مما يوفر رؤية الوسيط المستقل في أداء خط أنابيب الرسالة.
التنميط المستمر
ربما تكون أكثر القدرات التي يتم التقليل من شأنها من ملاحظة eBPF التنميط المستمر. يتطلب التنميط التقليدي إرفاق محلل بعملية محددة وتشغيله لفترة وتحليل الإخراج. هذا مزعج جدًا وسادة الموارد لاستخدام الإنتاج.
يعمل التنميط المستند إلى eBPF بشكل مختلف. يعلق على أحداث الأداء وعينات آثار المكدس لـ CPU على فترات زمنية منتظمة عبر جميع العمليات على المضيف. النفقات العامة ضئيلة — عادة أقل من 1٪ من وحدة المعالجة المركزية — مما يجعل من الممكن تشغيلها بشكل مستمر في الإنتاج.
الفائدة العملية كبيرة. عندما تشهد الخدمة بروز الكمون، فلا تحتاج إلى إعادة إنتاج المشكلة مع إرفاق محلل. بيانات التنميط موجودة بالفعل، تُلتقط كرسوم بيانية للهب توضح بالضبط حيث تم قضاء وقت وحدة المعالجة المركزية أثناء الحادثة. هذا يحول تصحيح أداء من التحقيق التفاعلي إلى التحليل بأثر رجعي.
eBPF للأمان: النواة كمرستقل أول
الملاحظة هي نصف القصة فقط. eBPF محولة بنفس الدرجة لأمان وقت التشغيل، والتقارب بين الملاحظة والأمان إلى وكيل مستوى النواة الواحد هو أحد أهم التحولات المعمارية في البنية الأساسية الحديثة.
كشف التهديدات في وقت التشغيل
تعتمد المراقبة الأمنية التقليدية على تحليل السجل — فحص سجلات التطبيقات وسجلات المراجعة وسجلات النظام للبحث عن مؤشرات الاختراق. هذا النهج له حدود أساسية: يمكن للمهاجمين تعديل السجلات أو قمعها، والتطبيقات قد لا تسجل أحداث ذات صلة أمنية، والشحن بالسجل يقدم الكمون بين الحدث والكشف عنه.
تعمل المراقبة الأمنية المستندة إلى eBPF على مستوى مختلف. من خلال ربط استدعاءات النظام وأحداث النواة، فإنها تراقب الأنشطة التي لا يمكن لأي سجل قمعها:
- تنفيذ العملية: كل عملية بدأت على نظام، بما في ذلك تلك التي بدأتها كسر الحاوية اللوحات الاستغلال
- الوصول إلى الملف: كل ملف مفتوح أو قراءة أو كتابة أو حذف، بما في ذلك الوصول إلى المسارات الحساسة مثل
/etc/shadowأو المفاتيح التشفيرية - اتصالات الشبكة: كل اتصال خارجي، بما في ذلك تلك التي تتجاوز سياسات الشبكة على مستوى التطبيق
- تصعيد الامتياز: استدعاءات النظام التي تعدل قدرات العملية أو معرفات المستخدم أو السياقات الأمنية
- تحميل وحدة النواة: محاولات تحميل وحدات النواة، والتي قد تشير إلى تثبيت rootkit
فرض السياسة
الكشف قيم، لكن الوقاية أفضل. تمكين خطافات LSM eBPF (وحدة أمان Linux) من فرض سياسات الأمان مباشرة في النواة، حجب الإجراءات غير المصرح بها قبل أن تسري مفعولها.
Tetragon، الذي طورته فريق Cilium، هو الأداة الرائدة في هذا المجال. يوفر:
سياسات تنفيذ العملية: حدد الملفات الثنائية المسموح بتنفيذها في حاوية. إذا تسببت الرمل في shell داخل حاوية يجب أن تشغل فقط ثنائية Go، يمكن لـ Tetragon حظر التنفيذ وإنشاء تنبيه.
سياسات الشبكة: فرض الوجهات التي يمكن للبودية الاتصال بها على مستوى النواة، متجاوزة الثغرات المحتملة في وقت تشغيل الحاوية.
سياسات الوصول إلى الملف: قيد الملفات والدلائل التي يمكن للعملية الوصول إليها، مما يوفر دفاع العمق خارج أذونات نظام الملفات.
قيود القدرة: حد القدرات على Linux التي يمكن للعملية ممارستها، حتى لو منحها وقت تشغيل الحاوية.
يحدث الفرض في النواة، مما يعني أنه لا يمكن تجاوزه بواسطة استغلال على مستوى التطبيق. قد يكسب أحد المهاجمين الإنجاز البرمجي داخل حاوية لا يزال لا يمكنهم تنفيذ الإجراءات التي تحظرها سياسة eBPF، لأن السياسة تُفرض قبل استدعاء النظام المكتمل.
أمان الشبكة
Cilium، الأداة المنتشرة على نطاق واسع بناءً على eBPF، أعادت تعريف كيفية عمل أمان الشبكة في بيئات Kubernetes. تعمل السياسات الشبكية التقليدية على عنوان IP ومستوى المنفذ. سياسات Cilium المستندة إلى eBPF تعمل على الهوية ومستوى API:
- سياسات قائمة على الهوية: تشير السياسات إلى تسميات Kubernetes وهويات الخدمة بدلاً من عناوين IP، مما يلغي الحاجة إلى تتبع تخصيصات عنوان IP pod
- تصفية L7: سياسات تدرك HTTP و gRPC و Kafka التي يمكن أن تقيد الوصول إلى نقاط نهاية API محددة وليس فقط المنافذ
- التشفير الشفاف: تشفير قائم على WireGuard بين العقد، المطبقة في النواة عبر eBPF دون تطلب تطبيق التغييرات
- إدارة النطاق الترددي: حدود النطاق الترددي لكل pod المفروضة على مستوى النواة
نظام أدوات eBPF
دون نظام eBPF على مشاريع رئيسية عديدة، يعالج كل مجال محدد.
الشبكات والأمان
| الأداة | الغرض | مسؤول |
|---|---|---|
| Cilium | شبكات Kubernetes وسياسة الشبكة وشبكة الخدمة | Isovalent (Cisco) |
| Tetragon | فرض الأمان في وقت التشغيل | Isovalent (Cisco) |
| Falco | كشف تهديد وقت التشغيل | Sysdig / CNCF |
| Calico eBPF | شبكات Kubernetes مع مسار بيانات eBPF | Tigera |
الملاحظة
| الأداة | الغرض | مسؤول |
|---|---|---|
| Coroot | ملاحظة المكدس الكامل (مقاييس وسجلات وآثار والتنميط) | Coroot |
| Hubble | ملاحظة الشبكة ل Cilium | Isovalent (Cisco) |
| Pixie | ملاحظة Kubernetes | New Relic / CNCF |
| Parca | التنميط المستمر | القطبية الإشارات |
| Grafana Beyla | الاستقصاء التلقائي لـ HTTP و gRPC | Grafana Labs |
تتبع وتصحيح
| الأداة | الغرض | مسؤول |
|---|---|---|
| bpftrace | لغة تتبع المستوى الأعلى لـ eBPF | IO Visor |
| BCC | مجموعة أدوات BPF Compiler | IO Visor |
| bpftool | أداة إدارة برنامج eBPF | نواة Linux |
الاعتماد العملي: البدء
لا يتطلب اعتماد eBPF معرفة نواة عميقة. تجرد أدوات eBPF الحديثة التعقيد وتقدم واجهات مألوفة — لوحات معلومات وتنبيهات وتعريفات السياسة.
البدء بـ Observability
نقطة الدخول ذات أقل مخاطر هي الملاحظة. نشر وكيل مستند إلى eBPF مثل Coroot أو Grafana Beyla جنباً إلى جنب مع مكدس المراقبة الموجود. يتطلب الوكيل لا تغيير التطبيق — فهو يعمل كحاوية امتيازة أو DaemonSet وبدء الفور بجمع المقاييس.
بالنسبة لبيئات Kubernetes:
# نشر Coroot مع Helm
helm repo add coroot https://coroot.github.io/helm-charts
helm repo update coroot
helm install -n coroot --create-namespace coroot-operator coroot/coroot-operator
helm install -n coroot coroot coroot/coroot-ce
# الوصول إلى لوحة التحكم
kubectl port-forward -n coroot service/coroot-coroot 8080:8080
في دقائق قليلة، ستشهد خريطة الخدمة وكمون مقاييس لـ HTTP والاتصالات قاعدة البيانات وبيانات استخدام الموارد — جميع الملتقطة دون أي تغييرات استقصاء على تطبيقاتك.
إضافة فرض الأمان
بمجرد أن تكون الملاحظة في المكان، فإن الخطوة الطبيعية التالية هي فرض الأمان. Tetragon يوفر مسار متدرج:
المرحلة 1: وضع التدقيق. نشر Tetragon مع السياسات في وضع التدقيق. يسجل انتهاكات السياسة دون حظرها، مما يعطيك الوقت لفهم سلوك التطبيق وصقل السياسات قبل الفرض.
المرحلة 2: وضع التنبيه. ربط أحداث Tetragon بنظام التنبيهات الخاص بك. تلقي إشعارات عندما يحدث نشاط مريب — عمليات غير متوقعة واتصالات شبكية غير مصرح بها والوصول إلى ملفات حساسة.
المرحلة 3: وضع الفرض. تفعيل الفرض على السياسات التي تم التحقق من صحتها في وضع التدقيق. ابدأ بأكثر المحظورات حرجة — منع كسر الحاوية، على سبيل المثال — وقم بتوسيع التغطية تدريجياً.
متطلبات النواة
قدرات eBPF تعتمد على إصدار نواة Linux. لأدوات الملاحظة والأمان الحديثة بناءً على eBPF، تحتاج إلى:
| الميزة | أدنى نواة | موصى به |
|---|---|---|
| eBPF الأساسية | 4.4 | 5.10+ |
| دعم BTF | 5.2 | 5.10+ |
| خطافات LSM | 5.7 | 5.15+ |
| رموز BPF | 6.9 | 6.9+ |
| Ring buffer | 5.8 | 5.10+ |
معظم خدمات Kubernetes المُدارة من موفري السحابة (EKS و GKE و AKS) تشغل أنوية تدعم جميع ميزات eBPF الحديثة. يجب أن تستهدف النشرات على الأماكن النواة 5.10 أو أحدث لأفضل توافق.
اعتبارات الأداء
تضيف مراقبة eBPF فوائق عامة بسيطة، لكن "بسيطة" ليست "صفر":
- فوائض وحدة المعالجة المركزية: عادة 1-2٪ لمراقبة شاملة (الشبكة والعملية والملف والتنميط)
- استخدام الذاكرة: 50-200 MB لكل عقدة للوكيل، اعتمادًا على العلاقة
- عفو الشبكة: يتم شحن المقاييس والأحداث إلى خادم مركزي؛ الاستخدام يعتمد على حجم المجموعة والنشاط
- تخزين: ClickHouse (المستخدم من Coroot) أو Prometheus (المستخدم من قبل العديد من الأدوات) يتطلب التخزين يتناسب مع عدد الخدمات وفترة الاحتفاظ
بالنسبة لمعظم البيئات، فإن هذه النفقات العامة لا تُذكر مقارنة بالرؤية المكتسبة. ومع ذلك، أنظمة التداول عالية التردد ومعالجة الصوت/الفيديو في الوقت الفعلي والأعباء الأخرى الحساسة للكمون يجب على معايير أدوات eBPF بعناية قبل نشر الإنتاج.
تقارب الأمان والملاحظة
الاتجاه الأكثر أهمية في نظام eBPF هو التقارب بين الأمان والملاحظة إلى منصات موحدة. تاريخيًا، كانت هذه تخصصات منفصلة مع أدوات منفصلة وفرق منفصلة وميزانيات منفصلة. eBPF يمسح الحدود التقنية.
عندما يلتقط وكيل نواة واحد الاتصالات الشبكية وتنفيذ العملية والوصول إلى الملف وأنماط استدعاء النظام، فإن نفس البيانات تخدم كلا الغرضين:
- الملاحظة: "زاد كمون Service A إلى قاعدة البيانات بمقدار 200ms بعد آخر نشر"
- الأمان: "عملية غير متوقعة بدأت في حاوية Service A وقدمت اتصالًا خارجيًا إلى عنوان IP غير معروف"
تأتي كلا الملاحظتين من نفس مصدر بيانات eBPF. الفرق في كيفية تحليل البيانات والإجراءات التي يتم تشغيلها. هذا التقارب يقلل من انتشار الوكيل (وكيل واحد بدلاً من ثلاثة أو أربعة)، والقضاء على تكرار البيانات، ويتيح ارتباط يكون مستحيلاً سابقًا — مثل ربط حدث أمان بتأثيره على الأداء في الوقت الفعلي.
الأدوات مثل Coroot تجسد بالفعل هذا التقارب، مما يوفر لوحات ملاحظة جنباً إلى جنب مع تتبع SLO والكشف عن الحالات الشاذة. يوفر Cilium و Tetragon معًا الشبكات والملاحظة وفرض الأمان من منصة واحدة. توقع هذا التقارب للإسراع مع نضج النظام الإيكولوجي.
الخلاصة: طبقة البنية الأساسية الجديدة
تنقلت eBPF من ميزة نواة Linux إلى طبقة بنية أساسية تأسيسية. إنها التكنولوجيا خلف الشبكات في عروض Kubernetes الرئيسية لمعظم موفري السحابة الرئيسيين. إنها تقوى منصات الملاحظة التي استبدلت وكلاء APM التقليديين. يفرض سياسات الأمان التي تحمي الحاويات في وقت التشغيل.
بالنسبة لفرق الهندسة، فإن الدرس العملي واضح: إذا كنت تشغل أعباء عمل Linux — خاصة في Kubernetes — يجب أن تكون أدوات المستندة إلى eBPF جزءًا من مكدس البنية الأساسية الخاص بك. الملاحظة التي تكسبها دون أي تغييرات في الكود ملحوظة. فرض الأمان الذي يمكنك إضافته دون تعديلات التطبيق محول. والتقارب بين كليهما في منصات موحدة يبسط العمليات بطرق لا تستطيع أكوام الأدوات المنفصلة.
ابدأ بـ الملاحظة. أضف فرض الأمان تدريجياً. دع النواة تقوم بالعمل الذي تطلبه من تطبيقاتك. النتائج تستحق كل ذلك.