القياس صار مجانيًا: لماذا انفجرت فاتورة المراقبة في 2026؟

في 2018 كان السؤال الصعب في أي فريق هندسي هو: كيف نرى ما يحدث داخل أنظمتنا؟ كان الجواب يكلّف شهورًا من العمل — إضافة مكتبة لكل خدمة، وكتابة تتبّع يدوي لكل استدعاء، والتفاوض مع فريق آخر يرفض تعديل كوده. في 2026 صار السؤال مختلفًا تمامًا، والأصعب: كيف نتوقّف عن رؤية كل شيء؟

التقاط البيانات لم يعد المشكلة. أصبح مجانيًا تقريبًا، وتلقائيًا، وبلا سطر كود واحد. والنتيجة غير المتوقّعة أن الفاتورة الشهرية للمراقبة تحوّلت من بند تشغيلي صغير إلى واحد من أكبر بنود الإنفاق السحابي في فرق كثيرة. هذه ليست قصة عن أداة جديدة، بل عن قيد انتقل من مكان إلى مكان — ومَن لم ينتبه للانتقال يدفع ثمنه مرتين.

ما الذي تغيّر تقنيًا؟

التحوّل الأساسي اسمه eBPF: تقنية تسمح بتشغيل برامج صغيرة ومقيّدة بأمان داخل نواة لينكس نفسها، دون تعديل النواة ودون إعادة تشغيلها. بالنسبة للمراقبة، هذا يعني أن أداة خارجية تستطيع أن ترى حركة الشبكة واستدعاءات النظام من تحت التطبيق، بدل أن تُزرع داخله.

مشروع OpenTelemetry eBPF Instrumentation (المعروف اختصارًا بـOBI) هو التجسيد الرسمي لهذا الاتجاه. أصله أداة Grafana Beyla التي صدرت في سبتمبر 2023 لقياس اللغات المُترجَمة مثل Go وRust تلقائيًا، وتبرّعت بها Grafana لمشروع OpenTelemetry، ثم تشكّلت مجموعة عمل مخصّصة لها في مايو 2025. أول إصدار ألفا تحت اسم OBI نزل في نوفمبر 2025 بمساهمة مهندسين من Grafana وSplunk وCoralogix وOdigos، ثم أُعلنت النسخة التجريبية (Beta) في KubeCon أوروبا بأمستردام في أبريل 2026.

ماذا يفعل عمليًا؟

يعمل OBI خارج العملية (out-of-process) ويقيس على مستوى البروتوكول لا على مستوى المكتبة. يلتقط طلبات HTTP وgRPC واستعلامات SQL وRedis وKafka من النواة مباشرة، بدون أي تغيير في كود التطبيق، ويُشحن كملف تنفيذي وصورة Docker وحزمة Helm.

لكن المهم للسياق هنا ليس ما يفعله، بل ما يترتّب عليه: لحظة أن صار جمع البيانات لا يكلّف جهدًا هندسيًا، اختفى المُرشِّح الطبيعي الذي كان يحدّ من حجمها. حين كان كل مقياس جديد يتطلّب مراجعة كود ونقاشًا، كان أحدهم يسأل: «هل نحتاج هذا فعلًا؟» أما حين يأتي كل شيء مجانًا وتلقائيًا، فلا أحد يسأل.

الفاتورة: أين تذهب النقود بالضبط؟

OpenTelemetry مجاني ومفتوح. تخزين البيانات وفهرستها ليسا كذلك. والمفارقة أن OpenTelemetry يميل إلى زيادة حجم الإشارات لا تقليلها: مسارات تتبّع أكثر، وسمات أغنى لكل مسار — وهو بالضبط ما تحاسبك عليه المنصّات التي تسعّر بالجيجابايت.

تُوصف الزيادة عادةً بثلاثة محاور:

المحور	ما يعنيه	لماذا ينفجر في 2026
الحجم (Volume)	عدد السجلات والمسارات المُرسَلة	القياس التلقائي يلتقط كل خدمة بلا استثناء
الاحتفاظ (Retention)	كم يومًا تبقى البيانات قابلة للبحث	التحقيقات صارت تعود لأسابيع، لا ساعات
التعدّدية (Cardinality)	عدد القيم الفريدة لكل وسم	التصحيح على مستوى المستخدم الواحد يعني وسمًا بقيمة لكل مستخدم

المحور الثالث هو الأخطر لأنه الأقل وضوحًا. وسم واحد اسمه user_id أو request_id يمكن أن يحوّل مقياسًا واحدًا إلى ملايين السلاسل الزمنية المستقلّة، وكل سلسلة تُحاسَب منفردة في نماذج تسعير كثيرة. المطوّر يطلب هذا عن حسن نيّة — يريد تتبّع مشكلة عميل بعينه — والفاتورة تستجيب بصمت.

وفي المقابل، الأرقام المنشورة عن حجم المشكلة تتفاوت بشدّة حسب مصدرها: استطلاع Grafana للمراقبة لعام 2025 وجد أن 74% من المشاركين يضعون التكلفة ضمن أولوياتهم الأولى، وهذا رقم استطلاعي. أما التقديرات التي تتحدّث عن مئات آلاف الدولارات سنويًا لنشرٍ من مئة خادم، أو عن تجاوز إنفاق المؤسسات الكبرى عشرة ملايين دولار سنويًا، فمعظمها صادر عن جهات تبيع حلولًا للمشكلة نفسها — تُقرأ كتسويق لا كقياس مستقل.

القفل التقني انفكّ، والقفل الاقتصادي بقي. صار بإمكانك تغيير مزوّد المراقبة بتعديل عنوان واحد — لكن ما تدفعه لا يتحدّد بمن ترسل إليه، بل بكم ترسل.

قفل المورّد لم يُحَلّ… بل انتقل

الرواية السائدة أن OpenTelemetry أنهى مشكلة الارتباط بمورّد واحد. هذا صحيح في نصفها فقط.

ما انتهى فعلًا هو قفل القياس (instrumentation lock-in): لم تعد مضطرًا لزرع مكتبة خاصة بمورّد معيّن داخل مئة خدمة، ثم اكتشاف أن تغيير المورّد يعني إعادة العمل كله. تخرّج OpenTelemetry في مؤسسة CNCF في 11 مايو 2026، وصار OTel Collector هو طبقة الأنابيب المحايدة الفعلية، بحيث يصبح تبديل الخلفية في كثير من الحالات مجرّد تغيير نقطة الإرسال.

ما لم ينتهِ هو قفل التسعير. البيانات تُرسَل بسهولة، لكن تكلفة تخزينها والبحث فيها تبقى محكومة بنموذج المورّد. والأسوأ أن سوق الأنابيب نفسه بدأ يتركّز: جرت في الربع الأخير من 2025 استحواذات على أدوات أنابيب التتبّع لصالح شركات أمن كبرى، ثم استحوذت Palo Alto Networks على Chronosphere في يناير 2026. الملاحظة المنطقية هنا واضحة: من يملك الأنبوب وله في الوقت نفسه منصّة تخزين، ليس لديه حافز كبير لمساعدتك على إرسال بيانات أقل.

ما الذي لا يستطيع eBPF أن يراه؟

قبل إعادة بناء منظومتك على أساس القياس التلقائي، هذه حدود موثّقة يذكرها من جرّبوه في الإنتاج:

• لا تتبّع موزّع جاهزًا. يرى eBPF استدعاءات الشبكة، لا ترويسات سياق التتبّع. لربط طلب واحد عبر خمس خدمات تحتاج SDK حقيقيًا أو تمريرًا صريحًا للترويسات.
• الحمولات المشفّرة غير مقروءة. مع mTLS، ما تراه طبقة المقابس هو نصّ مشفّر. الوصول لما قبل التشفير يتطلّب ربطًا بمكتبة TLS نفسها، وهو ربط يَكسِر مع كل تغيير في إصدار المكتبة.
• شرط إصدار النواة. دعم BTF يتطلّب نواة 5.8 فأحدث — تُلبّيها معظم خدمات كوبرنيتس المُدارة، لكنها تستحق التحقّق قبل الاعتماد.
• لا يعرف منطق عملك. «كم طلبًا فشل بسبب رصيد غير كافٍ؟» سؤال لا تجيب عنه النواة. هذا يبقى شغل SDK والسمات المخصّصة.
• ما زال قبل 1.0. المشروع في إصدارات 0.x، ووجود خارطة طريق نحو الإصدار المستقر لا يعني أنه صدر.

لهذا فإن الوصف الدقيق لـOBI أنه يسدّ فجوات الرؤية، لا أنه يستبدل القياس على مستوى اللغة. والفرق ليس أكاديميًا: فريق يعتمد عليه وحده يكتشف متأخرًا أنه يملك بيانات كثيرة وإجابات قليلة.

خطوات عملية تخفّض الفاتورة بلا فقدان الرؤية

1. رشّح عند المُجمِّع، لا عند المورّد. أسقِط الوسوم عالية التعدّدية (معرّفات الحاويات، معرّفات الطلبات العابرة) في OTel Collector قبل أن تغادر البيانات شبكتك. ما لا يخرج لا يُحاسَب عليه.
2. اختر متغيّر تسعير تتحكّم فيه. اسأل قبل التوقيع: هل التكلفة تتبع شيئًا تعرفه (عدد العُقد) أم شيئًا لا تستطيع التنبّؤ به (حجم البيانات، التعدّدية، معدّل أخذ العيّنات)؟ الفرق بينهما هو الفرق بين ميزانية وفاجعة.
3. اختبر عند ضِعف الحجم المستقبلي. الفروق الحقيقية بين المنصّات لا تظهر عند حجمك الحالي، بل عند 5 إلى 10 أضعافه بتعدّدية إنتاجية واقعية.
4. افصل «ما نخزّنه» عن «ما نحلّله». ليس كل ما يُلتقط يستحق التخزين الساخن. جمّع وشكّل البيانات قبل المرحلة الغالية.
5. راقب كوبرنيتس أولًا. هو المكان الذي ينمو فيه الحجم والتعدّدية أسرع من أي مكان آخر في منظومتك.

أسئلة شائعة

هل يغني eBPF عن OpenTelemetry SDK؟

لا. يعطيك eBPF تغطية فورية لكل خدمة بلا تعديل كود — وهذا ممتاز للخدمات التي لا تملك حق تعديلها. لكن التتبّع الموزّع الكامل والسمات الخاصة بمنطق عملك تبقى من مسؤولية الـSDK. النمط الشائع في 2026 هو القياس الهجين: eBPF للتغطية العريضة، وSDK للعمق — مع انتباه لئلا يُنتِج الاثنان بيانات مكرّرة.

هل تكلفة المراقبة مشكلة مؤقتة ستحلّها التحسينات؟

على الأرجح لا؛ هي تتغيّر شكلًا أكثر مما تختفي. حجوم البيانات تواصل النمو مع أحمال الحافة وإنترنت الأشياء وأحمال الذكاء الاصطناعي، والأنماط الحديثة بلا خوادم تُنتج بيانات عالية التعدّدية بطبيعتها. المكاسب من التحسين حقيقية، لكن معدّل النمو قد يبتلعها — لذلك الضبط سياسة دائمة لا مشروع لمرّة واحدة.

ما الخطوة الأولى لفريق صغير يشعر أن فاتورته تكبر؟

لا تبدأ بتغيير المنصّة. ابدأ بسؤال: ما أعلى عشرة مقاييس من حيث عدد السلاسل الزمنية؟ في أغلب الحالات ستجد وسمًا أو اثنين مسؤولين عن الأغلبية الساحقة، وإسقاطهما عند المُجمِّع يعطي أثرًا أكبر من أي تفاوض على السعر.

الخلاصة

القصّة الحقيقية في مراقبة 2026 ليست أن أداة جديدة تفوّقت على قديمة، بل أن المورد النادر تبدّل. لعقد كامل كان النادر هو القدرة على القياس، فبنينا أدوات وثقافة وميزانيات حول تعظيم ما نلتقطه. ثم جاء eBPF وجعل الالتقاط شبه مجاني — وفجأة صار النادر هو قدرتنا على تحمّل ما التقطناه.

الفرق بين فريق يدفع فاتورة معقولة وآخر يدفع أضعافها نادرًا ما يكون في اختيار المنصّة. الفرق أن الأول يعامل التتبّع كقرار تحريري: ماذا نحتفظ به، ولأي غرض، ولكم من الوقت — والثاني يترك الافتراضات تعمل ويكتشف النتيجة في آخر الشهر.

المصادر: OpenTelemetry — أهداف OBI لعام 2026 · توثيق OBI الرسمي · Grafana — Beyla 2.5 وOBI · Dash0 — قفل المورّد في 2026 · MVP Factory — تجربة استبدال APM بـeBPF · byteiota — تكاليف المراقبة 2026