تبدأ المشكلة من مفارقة تشغيلية واضحة: كانت بيانات استخدام وحدات GPU في بيئة Adobe تُجمع كل ثانية داخل Prometheus مركزي، لكن الفرق التي تتحمل تكلفة هذه الوحدات لم تكن قادرة على رؤية مقاييسها مباشرة. ووفقاً للمهندسين Bingi Narasimha Karthik وRamkumar Nagaraj، أدى ذلك إلى اكتشاف وحدة GPU ظلت عند استخدام صفري لمدة 11 يوماً، وهي مخصصة ومشغلة لكنها غير مرئية للفريق المسؤول عنها.
المادة المنشورة على مدونة CNCF في 9 سبتمبر 2026 لا تقدم منتجاً تجارياً جديداً، بل تشرح نمطاً عملياً لبناء وصول ذاتي وآمن إلى المقاييس في عناقيد Kubernetes متعددة المستأجرين. الفكرة الأساسية هي وضع طبقة وسيطة واعية بالمستأجرين أمام Prometheus المركزي، ثم منح كل فريق شريحة منتقاة من بياناته، مع خيار نسخ هذه البيانات إلى Prometheus خاص به.
لماذا لا يكفي فتح Prometheus المركزي؟
يرى الكاتبان أن منح الفرق صلاحية القراءة على نقطة استعلام Prometheus المركزية يصطدم بمشكلتين. الأولى أمنية، إذ إن نقطة استعلام Prometheus ليست واعية بمساحات الأسماء؛ ومن يستطيع تنفيذ استعلام PromQL يمكنه نظرياً طلب بيانات فرق أخرى، مثل معدلات الطلب أو خطط السعة.
أما المشكلة الثانية فهي الأداء. يخدم المتجر المركزي مقاييس الأسطول بأكمله، وقد تؤدي استعلامات طويلة أو غير محسوبة من مئات المهندسين إلى استهلاك الموارد ورفع زمن الاستجابة للجميع. لذلك فإن فتح المتجر المشترك لا يحل مشكلة الرؤية، بل قد يضيف خطر تسريب البيانات ومشكلة الجار المزعج إلى البنية نفسها.
طبقة وسيطة بثلاث مسؤوليات
يقترح التصميم طبقة رقيقة أمام Prometheus تتولى ثلاث وظائف مترابطة:
- التحديد: مصادقة صاحب الطلب ومعرفة المستأجر الذي ينتمي إليه.
- العزل: تقييد كل استعلام بمساحة أسماء المستأجر، مع فرض القيد قبل وصول الاستعلام إلى Prometheus بحيث لا يمكن التحايل عليه عبر PromQL.
- التسليم: نسخ مجموعة منتقاة من مقاييس المستأجر دورياً إلى Prometheus خاص به عند الحاجة.
يستخدم مسار القراءة Nginx لموازنة الحمل، ثم kube-rbac-proxy للمصادقة والتفويض، وبعد ذلك تصل الطلبات إلى الوكيل الذي يكتشف خوادم Prometheus عبر Kubernetes API ويجمع النتائج من الخوادم السليمة. أما مسار الكتابة فيستخدم remote write لإرسال المقاييس المنتقاة إلى Prometheus الخاص بالمستأجر. وفي البيئات عالية التوافر، تُرسل البيانات إلى جميع النسخ المتماثلة عبر أسماء DNS الخاصة بالـ Pods.
العزل يبدأ من الهوية وينتهي عند البيانات
يعتمد kube-rbac-proxy على هوية Kubernetes وRBAC لتحديد صاحب الطلب، ثم يمرر هوية المستأجر على شكل تأكيد لمساحة الأسماء. ويتولى prom-label-proxy تطبيق العزل وقت الاستعلام، إذ يعيد كتابة الطلب لإضافة محدد مساحة الأسماء قبل إرساله إلى Prometheus. بهذه الطريقة لا يصبح العزل مجرد سياسة موصى بها للمستخدم، بل قيداً مطبقاً على كل استعلام.
كما يشير المصدر إلى إجراءات تقوية للوكيل نفسه، منها تشغيله كمستخدم غير root بالمعرّف UID 65534، واستخدام نظام ملفات جذري للقراءة فقط، وإزالة جميع الصلاحيات الإضافية، ومنع تصعيد الامتيازات، ومنحه حساب خدمة بأقل صلاحيات ممكنة.
ما الذي يتغير عملياً في التكلفة والأداء؟
لا يقتصر العزل على منع رؤية بيانات الآخرين. يتيح إعداد metricIsolation تطبيق مرشح مساحة الأسماء منذ مرحلة جمع المقاييس، بحيث لا يخزن Prometheus الخاص بالمستأجر سوى السلاسل التي تخصه. وبحسب تجربة الكاتبين، قد ينخفض عدد السلاسل المخزنة لمستأجر نموذجي بنحو 97%، من أكثر من 10 آلاف سلسلة إلى بضع مئات.
هذا التخفيض يعني متجراً أصغر واستعلامات أسرع وتكلفة تخزين أقل، كما يقلل احتمال تسريب البيانات لأن المقاييس غير المطلوبة لا تصل أصلاً إلى المتجر الخاص. ويخفف التصميم أيضاً الضغط عن Prometheus المركزي، إذ تنتقل لوحات المعلومات والتنبيهات اليومية إلى متاجر المستأجرين بدلاً من الاعتماد المستمر على المتجر المشترك.
التشغيل الذاتي يحتاج إلى حدود واضحة
يعرّف الفريق مورداً مخصصاً في Kubernetes باسم MetricAccess، يحدد مساحة الأسماء والمقاييس المطلوبة ووجهة remote write وفترة الجمع. ويمكن للمستأجرين اختيار أسماء مقاييس محددة أو تعبيرات منتظمة أو محددات PromQL. ويحتاج Prometheus المستهدف إلى تفعيل استقبال remote write عبر web.enable-remote-write-receiver، بينما تبقى بقية البنية قائمة على مكونات Prometheus وKubernetes المعتادة.
وتعرض المادة ستة أنواع من الاستعلامات المفيدة، منها متوسط استخدام GPU لكل مساحة أسماء، وعدّ الوحدات التي يقل استخدامها عن 5% خلال ساعة، ونسبة الذاكرة المستخدمة، واستهلاك الطاقة، واكتشاف وحدات مشغولة من دون حركة طلبات، أو وجود طلبات مع بقاء وحدات GPU خاملة. ويعتمد المثال على مقاييس من نمط DCGM، مع التنبيه إلى ضرورة مواءمة الأسماء مع المُصدّر المستخدم فعلياً.
تؤكد التجربة أن التشغيل الذاتي لا يعني إزالة الحواجز. فالمجموعات المنتقاة للمقاييس وفترات الجمع المختلفة تعمل كحصص تحد من الحمل، كما أن خيار remote write ينبغي تخصيصه للفرق التي تملك لوحات معلومات وتنبيهات فعلية، بينما قد يكفي الوصول المقيد وقت الاستعلام للفرق الصغيرة.
قراءة certi.news
التغيير المهم هنا ليس إضافة أداة مراقبة أخرى، بل نقل التحكم في الرؤية من فريق المنصة وحده إلى المستأجر مع إبقاء العزل تحت سيطرة البنية التحتية. وهذا يعالج في وقت واحد مشكلة أمنية ومشكلة تكلفة ومشكلة أداء. لكن الحل ليس تلقائياً: اختيار المقاييس، وضبط cardinality، والتعامل مع إعادة المحاولة، والكتابة إلى نسخ التوافر العالي، وتثبيت إصدارات المصدّرات كلها مسؤوليات تشغيلية مستمرة.
كما أن النتائج الرقمية الواردة، ومنها خفض السلاسل بنحو 97%، تخص تجربة الكاتبين و«مستأجراً نموذجياً» وليست ضماناً عاماً لكل عنقود. لذلك ينبغي اختبار النمط على أسماء المقاييس وحجم السلاسل وفترات الجمع الخاصة بكل بيئة قبل اعتماده على نطاق واسع. المشروع متاح بموجب Apache 2.0، وتشمل المادة رابط مستودع prometheus-multi-tenant-proxy على GitHub.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.