انتقل إلى المحتوى الرئيسي
DevOpsMar 28, 2026

المراقبة بدون أدوات قياس: كيف استبدل eBPF أسطول Sidecar

OS
Open Soft Team

Engineering Team

67% من فرق Kubernetes تحولت إلى مراقبة eBPF

وفقاً لاستطلاع CNCF السنوي 2026، 67% من فرق Kubernetes تستخدم الآن أدوات قائمة على eBPF لركيزة مراقبة واحدة على الأقل (مقاييس أو تتبعات أو سجلات) — ارتفاعاً من 29% في 2024 و41% في 2025.

السبب بسيط: المراقبة التقليدية القائمة على sidecar (وكلاء Envoy وsidecar OpenTelemetry Collector ووكلاء Datadog) تستهلك موارد ضخمة وتضيف زمن انتقال لكل طلب وتتطلب تغييرات في الكود. يفعل eBPF كل ذلك من النواة — بدون أي تغيير في التطبيق.

ما هو eBPF ولماذا هو مهم

eBPF (extended Berkeley Packet Filter) هي تقنية تسمح بتشغيل برامج معزولة داخل نواة Linux بدون تغيير كود مصدر النواة. صُممت أصلاً لتصفية حزم الشبكة، وتطورت eBPF إلى إطار عمل عام لبرمجة النواة.

كيف يعمل

  1. اكتب برنامجاً صغيراً بلغة C أو Rust
  2. اربطه بنقطة ربط في النواة — استدعاءات النظام، أحداث الشبكة، نقاط التتبع
  3. مُحقق eBPF في النواة يتحقق من أمان البرنامج
  4. مُجمع JIT يترجم بايتكود eBPF إلى تعليمات آلة أصلية
  5. البرنامج يُنفذ عند نقطة الربط بأداء شبه أصلي
// برنامج eBPF مبسط لتتبع طلبات HTTP
SEC("kprobe/tcp_v4_connect")
int trace_connect(struct pt_regs *ctx) {
    struct sock *sk = (struct sock *)PT_REGS_PARM1(ctx);
    
    u32 pid = bpf_get_current_pid_tgid() >> 32;
    u16 dport = sk->__sk_common.skc_dport;
    u32 daddr = sk->__sk_common.skc_daddr;
    
    struct event_t event = {
        .pid = pid,
        .dport = ntohs(dport),
        .daddr = daddr,
        .timestamp = bpf_ktime_get_ns(),
    };
    
    bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU,
                          &event, sizeof(event));
    return 0;
}

لماذا هو مهم للمراقبة

المراقبة التقليدية تتطلب أدوات قياس — إضافة كود أو مكتبات أو حاويات sidecar. هذا النهج له ثلاث مشاكل جوهرية:

  1. حمل الموارد — كل sidecar يستهلك CPU وذاكرة. في مجموعة 500 pod مع sidecar Envoy، يمكن أن تستهلك السايدكارات 30-40% من إجمالي موارد المجموعة.
  2. فجوات التغطية — يمكنك فقط مراقبة ما تقيسه.
  3. عبء الصيانة — كل لغة وإطار عمل يحتاج مكتبة أدوات قياس خاصة.

يحل eBPF الثلاثة: يعمل في النواة (صفر حمل على التطبيق)، يرى كل ما تراه النواة (بدون فجوات)، ويعمل بغض النظر عن اللغة.

مكدس مراقبة eBPF في 2026

Cilium + Hubble: مراقبة الشبكة

Cilium هو واجهة شبكة الحاوية (CNI) الفعلية لـ Kubernetes. Hubble يوفر:

  • رؤية تدفقات L3/L4 — كل اتصال TCP/UDP بين pods
  • تحليل بروتوكولات L7 — HTTP وgRPC وKafka وDNS وPostgreSQL بدون تغيير التطبيق
  • تدقيق سياسات الشبكة — مشاهدة السياسات التي تسمح أو ترفض حركة المرور في الوقت الحقيقي
  • رسم خريطة تبعيات الخدمات — إنشاء رسم بياني تلقائي للخدمات

Pixie: مراقبة أداء التطبيقات

Pixie (مشروع CNCF sandbox) يوفر APM بدون أدوات قياس:

  • تتبع البروتوكولات التلقائي — HTTP/1.1 وHTTP/2 وgRPC وPostgreSQL وMySQL وRedis وKafka وDNS
  • تنميط CPU مستمر — مخططات اللهب من تتبعات مكدس eBPF
  • تسجيل ديناميكي — إضافة نقاط تتبع بدون إعادة نشر
  • التقاط كامل للطلب/الاستجابة — رؤوس HTTP واستعلامات SQL وحمولات gRPC

Tetragon: أمان وقت التشغيل والتدقيق

Tetragon (من Isovalent/Cilium):

  • تتبع تنفيذ العمليات — كل حدث exec وfork وexit
  • مراقبة الوصول إلى الملفات — تتبع القراءة والكتابة وتغييرات الأذونات
  • تدقيق اتصالات الشبكة — تسجيل كل اتصال صادر مع سياق العملية
  • تطبيق سياسات الأمان — حظر الأنشطة المشبوهة في الوقت الحقيقي

Grafana Beyla: أدوات قياس تلقائية

Grafana Beyla هو وكيل أدوات قياس تلقائية قائم على eBPF:

  • يكتشف طلبات HTTP وgRPC وSQL وRedis على مستوى النواة
  • يصدر نطاقات OpenTelemetry مع انتشار سياق التتبع
  • يتكامل مع Grafana Cloud وTempo وMimir وأي خلفية OpenTelemetry

الأداء: الأرقام المهمة

معايير حقيقية من مجموعة Kubernetes إنتاجية مكونة من 500 pod:

مقارنة استخدام الذاكرة

المكوننهج Sidecarنهج eBPFالتوفير
سايدكار Envoy (500 pod)50 GB0 (Cilium CNI)50 GB
سايدكار OTel Collector (500 pod)15 GB0 (Beyla DaemonSet)15 GB
وكلاء Cilium (20 عقدة)N/A8 GB-8 GB
وكلاء Beyla (20 عقدة)N/A2 GB-2 GB
الإجمالي75 GB12 GBتخفيض 84%

حمل CPU

المقياسنهج Sidecarنهج eBPF
زمن الانتقال المضاف لكل طلب1-5ms<0.1ms
حمل CPU لكل عقدة8-12%<1%
تأثير زمن الانتقال الذيلي (p99)+15-30ms<1ms

دليل الترحيل: من Sidecar إلى eBPF

المرحلة 1: نشر أدوات eBPF بجانب Sidecars (الأسبوع 1-2)

  • تثبيت Cilium كـ CNI
  • نشر Hubble لمراقبة الشبكة
  • نشر Beyla كـ DaemonSet
  • تشغيل كلا المكدسين بالتوازي

المرحلة 2: التحقق والضبط (الأسبوع 3-4)

  • التحقق من أن أدوات eBPF تلتقط نفس الإشارات
  • ضبط اكتشاف البروتوكولات في Beyla
  • إعداد لوحات معلومات مطابقة

المرحلة 3: إزالة Sidecars تدريجياً (الأسبوع 5-8)

  • البدء بالخدمات غير الحرجة
  • مراقبة تراجع جودة البيانات
  • إزالة سايدكارات Envoy من الخدمات التي لا تحتاج إدارة حركة مرور متقدمة

المرحلة 4: مكدس eBPF كامل (الأسبوع 9-12)

  • إزالة السايدكارات المتبقية
  • نشر Tetragon لأمان وقت التشغيل
  • توحيد التنبيهات على إشارات eBPF
  • استرداد الموارد المحررة

الأسئلة الشائعة

هل تعمل مراقبة eBPF مع أحمال عمل غير Kubernetes؟

نعم. يعمل eBPF على مستوى نواة Linux، لذا يعمل مع أي حمل عمل.

هل يمكن لـ eBPF استبدال التتبع الموزع؟

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

ماذا عن حركة المرور المشفرة (TLS)؟

يمكن لأدوات eBPF تتبع حركة TLS بالربط بوظائف مكتبة TLS.

هل eBPF آمن؟ هل يمكن لبرنامج eBPF معيب أن يعطل النواة؟

لا. يفحص محقق eBPF كل برنامج قبل التحميل. البرنامج المعيب سيفشل في التحميل.

كيف يتعامل eBPF مع الخدمات عالية الإنتاجية (100K+ طلب/ثانية)؟

عبر التجميع داخل النواة والعينات.

الوسوم
DevOpsDockerKubernetes