ما هي مقاييس شبكة الحاويات؟

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

• الرؤية قليلة جدا. تجمعات على مستوى العقد تخبرك أن هناك خطبا ما، لكنها لا تخبرك بمكان ذلك. بدون تحليلات على مستوى الوحدة تشمل سياق المصدر والوجهة، فإن عزل عبء العمل الفاشل يعني التخمين.
• الكثير من البيانات على نطاق واسع. يمكن لمجموعة تشغل مئات الخدمات المصغرة إنتاج آلاف السلاسل الزمنية المترية لكل عقدة. جمع كل شيء يزيد من تكاليف التخزين ويبطئ لوحة القيادات.

مقاييس شبكات الحاويات في Advanced Container Networking Services خدمة Azure Kubernetes ‏(AKS) تتعامل مع كلا الأمرين. تجمع الميزة مقاييس الشبكة على مستوى العقدة ومستوى البودرة عبر مستويات البيانات المدعومة من Cilium وغير Cilium، على أنظمة Linux وWindows.

في عناقيد Cilium، يمكنك الذهاب خطوة أبعد من ذلك باستخدام التصفية على مستوى المصدر، والتي تتيح لك اختيار بالضبط أي مساحات الأسماء، وأعباء العمل، وأنواع المقاييس التي يتم جمعها قبل مغادرة البيانات من العقدة.

تصفية مقاييس الحاويات هي تحكم مسبق للدخول لبيانات الملاحظة. بدلا من جمع كل مقياس متاح وتصفية لاحقا في لوحات المعلومات أو الاستعلامات، تحدد ما الذي يجب جمعه من المصدر. هذا يحافظ على مقاييس عالية القيمة لأعباء العمل التي تهتم بها ويتجنب التعرض لسلاسل زمنية منخفضة القيمة أو صاخبة.

والنتيجة: قابلية الرصد الشبكي على أي مستوى بيانات مدعوم، مع ترشيح اختياري وفعال من حيث التكلفة على Cilium.

تمنحك مقاييس شبكة الحاويات رؤية عميقة على مستوى عبء العمل لحل المشكلات والتخطيط، بينما يساعد التصفية على مستوى المصدر في سيليوم في الحفاظ على تكاليف الملاحظة متناسبة مع أعباء العمل الحيوية للأعمال.

الجمع والتصفية بنظرة سريعة

استخدم هذا الجدول لفهم سريع أين تتوفر مجموعة واسعة وأين تتوفر التصفية الدقيقة:

القدرة	تجمعات الأهداب	العناقيد غير الأهدبية
مجموعة مقياس على مستوى العقدة	✅	✅
مجموعة مقياس على مستوى البودرة	✅ (لينكس)	✅ (لينكس)
تصفية على مستوى المصدر حسب مساحة الأسماء، تسمية البود، ونوع المقياس	✅	❌
التحكم في التكاليف من خلال الترشيح المسبق	✅	❌

Important

ابتداء من 30 نوفمبر 2025، لم تعد خدمة خدمة Azure Kubernetes ‏(AKS) تدعم أو توفر تحديثات الأمان ل Azure Linux 2.0. صورة عقدة Azure Linux 2.0 مجمدة عند إصدار 202512.06.0. ابتداء من 31 مارس 2026، سيتم إزالة صور العقد، ولن تتمكن من توسيع مجموعات العقد الخاصة بك. انتقل إلى نسخة Azure Linux المدعومة عن طريق ترقية مجموعات العقد إلى نسخة Kubernetes مدعومة أو الانتقال إلى osSku AzureLinux3. لمزيد من المعلومات، راجع مشكلة GitHub للتقاعدوإعلان تقاعد Azure Updates. للبقاء على اطلاع بالإعلانات والتحديثات، تابع ملاحظات إصدار AKS.

المزايا الرئيسية

• الحبيبات على مستوى العقدة والبود. تتبع حجم حركة المرور، معدلات الانقطاع، وحالات الاتصال على مستوى العقدة لصحة البنية التحتية. ابحث إلى وحدات فردية مع تسميات المصدر والوجهة لتحديد عبء العمل الدقيق الذي يسبب المشكلة.

• حل أخطاء أسرع. عندما تبدأ خدمة في إسقاط الحزم أو فشل استعلامات DNS، تتيح مقاييس المستوى على مستوى الوحدة عزل المشكلة إلى وحدة محددة أو مساحة اسم أو بروتوكول في ثوان وليس ساعات.

• تصور مرن. تخزين المقاييس في Azure Managed Prometheus وتصور في Azure Managed Grafana (الإدارة بالكامل)، أو أحضر بنية Prometheus وGrafana الخاصة بك.

• قابلة للتوسع عن طريق التصميم. يتعامل خط الأنابيب مع مجموعات كبيرة وديناميكية تحتوي على مئات العقد وآلاف البودات دون الحاجة للاختيار بين تغطية شاملة وأحجام بيانات قابلة للإدارة.

• الملاحظة المستهدفة (عناقيد الأهداب). في عناقيد Cilium، يتيح لك التصفية على مستوى المصدر تحديد مساحات الأسماء، أو تسميات الكبسولات، أو أنواع المقاييس التي تهتم بها وجمع تلك فقط. لا حاجة لتقليم بعد الجمع.

• تكاليف استهلاك المقاييس أقل (مجموعات السيليوم). نظرا لأن التصفية تحدث عند المصدر في كل عقدة، فإن سلاسل الزمن المتري غير المرغوب فيها لا يتم جمعها أو نقلها أو استيعابها في خلفية Prometheus الخاصة بك. أنت تدفع فقط مقابل المقاييس التي تحتاجها فعليا. في المجموعات الكبيرة حيث يمكن للجمع غير المصفاة أن ينتج آلاف السلاسل الزمنية لكل عقدة، يمكن أن يقلل التصفية على مستوى المصدر بشكل كبير من تكاليف الامتصاص والتخزين بواسطة Azure Managed Prometheus.

طريقة العمل

يعتمد تكديس الوكلاء على كل عقدة على مستوى البيانات، كما هو موضح في الرسم التوضيحي.

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

تستخدم عقد Linux غير Cilium خطاطيف نواة eBPF التي تغذي Microsoft الشبكية، مع طبقة هابل فوقها لفحص التدفق. تتولى Microsoft Retina جمع المقاييس وتصدر المقاييس على مستوى العقد والبودي بصيغة Prometheus.

من جميع المسارات، يتم جمع المقاييس بصيغة Prometheus ويتم دمجها في Azure Managed Prometheus أو الخلفية الخاصة بك في Prometheus، ثم يتم تصورها في Azure Managed Grafana أو مكدس Grafana الخاص بك.

للبدء، قم بإعداد مقاييس شبكة الحاويات، ثم قم بتكوين مقاييس تصفية مقاييس شبكة الحاويات لمجموعات Cilium.

متى تستخدم مقاييس شبكة الحاويات

تم تصميم مقاييس شبكة الحاويات للفرق التي تحتاج إلى بيانات شبكة مركزة وقابلة للتنفيذ بدلا من القياس الخام عن بعد. تتضمن السيناريوهات الشائعة ما يلي:

• تصحيح عبء عمل معين. استخدم مقاييس على مستوى البودرة لعزل إسقاط الحزم، أو إعادة ضبط TCP، أو فشل DNS لخدمة معينة. في عناقيد Cilium، يمكن أن تضيق التصفية المجموعة إلى تلك المساحة الاسمية أو علامة الكبسولة، مما يقطع الضوضاء على مستوى العنقود.
• مراقبة المجموعات متعددة المستأجرين. تتبع صحة الشبكة لكل مساحة أسماء حتى يكون لكل فريق رؤية لأنماط حركة المرور الخاصة به. في عناقيد Cilium، يحافظ التصفية المحددة النطاق على حصر الجمع على مساحات أسماء خاصة بالمستأجرين.
• تخطيط القدرات. تتبع عدد البايتات المحسنة والمفقودة لكل عقدة لتحديد الروابط المشبعة أو توزيع عبء العمل غير المتوازن.
• مراقبة صحة DNS. فشل استعلامات DNS في Surface وبطء أوقات الحل لاكتشاف المشكلات قبل أن تتحول إلى أخطاء في التطبيق.
• تقليل تكاليف الملاحظة على نطاق واسع. في المجموعات الكبيرة، يمكن للمجموعات غير المصفاة أن تولد آلاف السلاسل الزمنية لكل عقدة. في عناقيد Cilium، يقوم الترشيح على مستوى المصدر بإزالة السلاسل غير المرغوب فيها قبل الابتلاع حتى تبقى التكاليف متوافقة مع أعباء العمل وأنواع المقاييس التي تختارها.

كيفية اختيار ما يجب جمعه (عناقيد الأهداب)

استخدم هذا النموذج للنشر لتحقيق التوازن بين الرؤية والتكلفة:

1. ابدأ بمجموعة واسعة في مساحة أسماء غير إنتاجية لتحديد خط أساس.
2. احتفظ بمقاييس حالة سقوط الحزم، DNS، وTCP لمساحات الأسماء الحرجة.
3. حدد نطاق مقاييس التدفق عالية العدد لتشمل الأحمال المهمة للأعمال فقط.
4. راجع اتجاهات تناول بروميثيوس وقم بتحسين الفلاتر أسبوعيا.

يساعدك هذا النهج على الحفاظ على مقاييس ذات قيمة عالية مع التحكم في نمو السلاسل الزمنية وتكاليف الاستهلاك.

قبل مراجعة جداول المقاييس

ضع هذه النقاط في الاعتبار:

• تتوفر مقاييس على مستوى العقدة عبر مستويات بيانات سيليوم مدعومة وغير مدعومة.
• مقاييس على مستوى البودرة متوفرة على لينكس.
• يتوفر الترشيح على مستوى المصدر فقط على عناقيد Cilium.
• في عناقيد Cilium، تتطلب مقاييس DNS سياسة شبكة Cilium FQDN.

مرجع المقاييس

مقاييس على مستوى العقدة

توفر مقاييس مستوى العقد إحصائيات حركة مرور مجمعة لكل عقدة — الحزم المحولات والمفقودة، وعدد البايتات، وحالات الاتصال. تخزن هذه المقاييس بصيغة بروميثيوس ويمكن تصورها في غرافانا.

يتم تجميع المقاييس التالية لكل عقدة. تتضمن جميع المقاييس هذه التسميات:

• cluster
• instance (اسم العقدة)

Cilium

بالنسبة لمجموعات مستوى بيانات سيليوم، تتوفر مقاييس على مستوى العقدة فقط على لينكس. يعرض سيليوم المقاييس التالية المستخدمة في مقاييس شبكة الحاويات:

اسم قياسي	Description	تسميات إضافية	Linux	Windows
cilium_forward_count_total	إجمالي عدد الحزم التي تمت إعادة توجيهها	direction	✅	❌
cilium_forward_bytes_total	إجمالي عدد البايت الذي تمت إعادة توجيهه	direction	✅	❌
cilium_drop_count_total	إجمالي عدد الحزم التي تم إسقاطها	direction، reason	✅	❌
cilium_drop_bytes_total	إجمالي عدد البايت المسقط	direction، reason	✅	❌

Non-Cilium

بالنسبة لسيناريوهات مستوى البيانات غير Cilium، تتوفر مقاييس شبكة الحاويات لكل من Linux وWindows.

Note

بسبب خطأ معروف، فإن إعادة تعيين TCP غير مرئية مؤقتا. مقياس networkobservability_tcp_flag_counters غير منشور على لينكس في الوقت الحالي.

اسم قياسي	Description	تسميات إضافية	Linux	Windows
networkobservability_forward_count	إجمالي عدد الحزم التي تمت إعادة توجيهها	direction	✅	✅
networkobservability_forward_bytes	إجمالي عدد البايت الذي تمت إعادة توجيهه	direction	✅	✅
networkobservability_drop_count	إجمالي عدد الحزم التي تم إسقاطها	direction، reason	✅	✅
networkobservability_drop_bytes	إجمالي عدد البايت المسقط	direction، reason	✅	✅
networkobservability_tcp_state	عدد مقابس TCP النشط حسب الولاية	state	✅	✅
networkobservability_tcp_connection_remote	عدد مقابس TCP النشطة حسب IP/المنفذ البعيد	address (IP)، port	✅	❌
networkobservability_tcp_connection_stats	إحصائيات اتصال TCP (على سبيل المثال، تأكيدات ACK المؤجلة، TCPKeepAlive، TCPSackFailures)	statistic	✅	✅
networkobservability_tcp_flag_counters	عدد حزم TCP حسب العلم	flag	❌	✅
networkobservability_ip_connection_stats	إحصائيات اتصال IP	statistic	✅	❌
networkobservability_udp_connection_stats	إحصائيات اتصال UDP	statistic	✅	❌
networkobservability_udp_active_sockets	عدد المقابس النشطة في UDP		✅	❌
networkobservability_interface_stats	إحصائيات الواجهة	اسم الواجهة، statistic	✅	✅

مقاييس على مستوى الجراب (مقاييس Hubble)

تشمل مقاييس مستوى الوحدة معلومات عن الكبسولة المصدر والوجهة، بحيث يمكنك تحديد مشاكل الشبكة بدقة على مستوى عبء العمل الفردي. تغطي هذه المقاييس حجم حركة المرور، والحزم المنقطعة، وإعادة ضبط TCP، وتدفقات الطبقة 4/الطبقة 7.

يتم جمع مقاييس DNS (عدد الاستعلامات، رموز الاستجابة، والأخطاء) بشكل افتراضي على مستويات البيانات غير التابعة ل Cilium. على مستويات بيانات Cilium، تتطلب مقاييس DNS سياسة شبكة Cilium FQDN. يمكنك أيضا استكشاف أخطاء DNS في الوقت الحقيقي باستخدام واجهة تحكم هابل.

يصف الجدول التالي المقاييس التي يتم تجميعها لكل جراب (يتم الاحتفاظ بمعلومات العقدة).

تتضمن جميع المقاييس التسميات:

• cluster

• instance (اسم العقدة)

• source أو destination

  • بالنسبة لحركة المرور الصادرة، يشير المعلم source إلى مساحة اسم الكبسولة المصدر والاسم.

  • بالنسبة لحركة المرور الواردة، يشير الملصق destination إلى مساحة اسم واسم وحدة الوجهة.

اسم قياسي	Description	تسميات إضافية	Linux	Windows
hubble_dns_queries_total	إجمالي طلبات DNS حسب الاستعلام	source أو destination، query( qtypes نوع الاستعلام)	✅	❌
hubble_dns_responses_total	إجمالي استجابات DNS حسب الاستعلام/الاستجابة	sourceأو destination، queryqtypes (نوع الاستعلام)، rcode (رمز الإرجاع)، ips_returned (عدد عناوين IP)	✅	❌
hubble_drop_total	إجمالي عدد الحزم التي تم إسقاطها	sourceأو destination، ، protocolreason	✅	❌
hubble_tcp_flags_total	إجمالي عدد حزم TCP حسب العلم	source أو destination، flag	✅	❌
hubble_flows_processed_total	إجمالي تدفقات الشبكة المعالجة (حركة مرور الطبقة 4/الطبقة 7)	sourceأو destination، protocol، verdict، ، typesubtype	✅	❌

Limitations

مستوى المنصة والبيانات:

• تتوفر مقاييس مستوى الجراب فقط على Linux.
• يتم دعم مستوى بيانات Cilium بدءا من Kubernetes الإصدار 1.29.
• تصفية المقاييس على مستوى المصدر متاحة فقط على عناقيد Cilium.
• تحتوي التسميات القياسية على اختلافات دقيقة بين مجموعات Cilium وغير Cilium.

مقاييس DNS:

• في مجموعات Cilium، تتطلب مقاييس DNS سياسة شبكة Cilium FQDN، أو يمكنك استخدام واجهة Hubble لاستكشاف أخطاء DNS في الوقت الحقيقي.

المشكلات المعروفة:

• إذا تعطل وكيل عقدة هابل، قد يتعطل مرحل هابل، مما قد يقطع جلسات واجهة التحكم في هابل.

دعم FIPS (لمستويات البيانات غير السيليوم فقط):

• FIPS غير متوفر على عقد أوبونتو 20.04 بسبب قيود النواة. استخدم تجمع عقد Azure Linux بدلا من ذلك. هذا القيد لا ينطبق على مستويات بيانات سيليوم. للحصول على التحديثات، راجع متتبع مشكلات AKS.

نظام التشغيل	دعم FIPS
Azure Linux 3.0	Yes
Azure Linux 2.0	Yes
أوبونتو 20.04	No

الحجم:

• تفرض الخدمة المدارة ل Prometheus في Azure Monitor وAzure Managed Grafana قيود مقياس خاصة بالخدمة. لمزيد من المعلومات، راجع مقاييس Scrape Prometheus على نطاق واسع في Azure Monitor.

Pricing

Important

خدمات شبكات الحاويات المتقدمة هي عرض مدفوع.

لمزيد من المعلومات حول التسعير، راجع خدمات شبكات الحاويات المتقدمة - التسعير.

المحتوى ذو الصلة

• إعداد مقاييس شبكة الحاويات
• تكوين تصفية مقاييس شبكة الحاويات
• خدمات شبكات الحاويات المتقدمة ل AKS
• قابلية الملاحظة لشبكة الحاويات في خدمات شبكات الحاويات المتقدمة
• أمان شبكة الحاويات في خدمات شبكات الحاويات المتقدمة