مراقبة خدمة Azure Kubernetes ‏(AKS)

ينطبق على: ✔️ AKS ✔️ Automatic Standard

تتطلب مراقبة AKS مستويات متعددة من القابلية للرصد عبر مقاييس المنصة، ومقاييس بروميثيوس، وسجلات الأنشطة، وسجلات الموارد، ورؤى الحاويات. يوفر AKS قدرات مراقبة مدمجة ويتكامل مع Azure Monitor وContainer Insights والخدمة المدارة لبروميثيوس وAzure Managed Grafana لمراقبة صحة العنقود والأداء بشكل شامل.

بالنسبة لمعظم أعباء العمل الإنتاجية، يعتبر AKS Automatic هو الإعداد الافتراضي الموصى به لجاهز الإنتاج ل AKS. تتضمن مجموعات AKS Automatic خط أساس مراقبة مهيأ مسبقا مع خدمة مدارة ل Prometheus لجمع المقاييس، وContainer insights لجمع السجلات، ولوحات تحكم Azure Monitor مع Grafana للتصور في بوابة Azure. في AKS Standard، يمكنك تفعيل وتكوين نفس قدرات المراقبة بناء على متطلباتك.

تلميح

يمكنك استخدام Azure Copilot لتكوين المراقبة على مجموعات AKS الخاصة بك في بوابة Azure. لمزيد من المعلومات، راجع العمل مع عناقيد AKS بكفاءة باستخدام Azure Copilot.

الرؤى

تحتوي بعض الخدمات في Azure على لوحة معلومات مراقبة مضمنة في مدخل Microsoft Azure توفر نقطة بداية لمراقبة خدمتك. تسمى لوحات المعلومات هذه رؤى، ويمكنك العثور عليها في مركز Insights ل Azure Monitor في مدخل Microsoft Azure.

إعدادات المراقبة التلقائية في AKS

يوفر AKS Automatic تجربة افتراضية جاهزة للإنتاج لمعظم أعباء عمل AKS. كجزء من تلك التجربة، يقوم AKS Automatic بتكوين خط أساس مراقبة افتراضي لك.

قدرة المراقبة AKS تلقائي معيار AKS
خدمة مدارة ل Prometheus افتراضي اختياري
نتائج تحليلات الحاوية افتراضي اختياري
Azure Monitor لوحات المعلومات باستخدام Grafana الافتراضي في بوابة Azure الافتراضي في بوابة Azure
Azure Managed Grafana اختياري اختياري

استخدم AKS Automatic عندما تريد تجربة AKS جاهزة للإنتاج مع إعدادات المراقبة الافتراضية الموجودة مسبقا. استخدم AKS Standard عندما ترغب في اختيار وتكوين مكونات المراقبة بشكل فردي.

لمزيد من المعلومات حول الديفالات التلقائية في AKS، انظر What is خدمة Azure Kubernetes ‏(AKS) Automatic?

بيانات مراقبة AKS: المقاييس، السجلات، التكاملات

تقوم AKS بإنشاء نفس أنواع بيانات المراقبة مثل موارد Azure الأخرى كما هو موضح في مراقبة البيانات من موارد Azure. للحصول على معلومات مفصلة حول المقاييس والسجلات التي تم إنشاؤها بواسطة AKS، راجع مرجع بيانات مراقبة AKS.

في AKS Automatic، تم إعداد مكدس المراقبة الافتراضي الموصى به بالفعل لك. في AKS Standard، يمكنك تجميع نفس حزمة المراقبة من خلال تمكين خدمات المراقبة والتكاملات ذات الصلة.

تجمع خدمات وميزات Azure الأخرى بيانات أخرى وتمكن خيارات التحليل الأخرى كما هو موضح في الرسم التخطيطي والجدول التاليين.

رسم تخطيطي لبيانات المراقبة التي يتم جمعها من AKS.

المصدر ‏‏الوصف
قياسات النظام الأساسي يتم جمع مقاييس النظام الأساسي تلقائيا لمجموعات AKS دون أي تكلفة. يمكنك تحليل هذه المقاييس باستخدام مستكشف المقاييس أو استخدامها لإنشاء تنبيهات مقياسية.
مقاييس Prometheus عند تمكين استخراج المقاييس للمجموعة الخاصة بك، تجمع الخدمة المدارة ل Prometheus في Azure Monitor مقاييس Prometheus وتخزنها في مساحة عمل Azure Monitor. حلل هذه المقاييس باستخدام لوحات المعلومات الجاهزة في Azure Managed Grafana وباستخدام تنبيهات Prometheus.
سجلات الأنشطة يجمع سجل نشاط Azure Monitor تلقائيا بعض البيانات لمجموعات AKS دون أي تكلفة. تتعقب ملفات السجل هذه المعلومات مثل وقت إنشاء نظام مجموعة أو إجراء تغييرات على تكوين نظام المجموعة. لتحليل بيانات سجل النشاط مع بيانات السجل الأخرى، أرسل بيانات سجل النشاط إلى مساحة عمل تحليلات السجل.
سجلات الموارد يتم تنفيذ سجلات وحدة التحكم ل AKS كسجلات موارد. أنشئ إعداد تشخيصيلإرسال السجلات إلى مساحة عمل تحليلات السجلات. في مساحة العمل، يمكنك تحليل السجلات باستخدام الاستعلامات وإعداد تنبيهات بناء على معلومات السجل.
نتائج تحليلات الحاوية تجمع Container Insights سجلات وبيانات أداء مختلفة من مجموعة وتخزنها في مساحة عمل Log Analytics وفي مقاييس Azure Monitor. حلل البيانات مثل stdout البيانات والتدفقات stderr باستخدام العروض والكتيبات في Container Insights أو Log Analyticsومستكشف المقاييس.
Application Insights تجمع Application Insights، وهي ميزة من ميزات Azure Monitor، السجلات والمقاييس والتتبعات الموزعة. يتم تخزين بيانات تتبع الاستخدام في مساحة عمل Log Analytics للتحليل في مدخل Microsoft Azure. لتمكين Application Insights مع تغييرات التعليمات البرمجية، راجع تمكين Azure Monitor OpenTelemetry. لتمكين Application Insights دون تغييرات في التعليمات البرمجية، راجع AKS autoinstrumentation. لمزيد من المعلومات حول الأجهزة، تعرف على أساسيات جمع البيانات.

أنواع الموارد

يستخدم Azure مفهوم أنواع الموارد والمعرفات لتحديد كل شيء في الاشتراك. أنواع الموارد هي أيضا جزء من معرفات الموارد لكل مورد يعمل في Azure. على سبيل المثال، نوع مورد واحد لجهاز ظاهري هو Microsoft.Compute/virtualMachines. للحصول على قائمة بالخدمات وأنواع الموارد المقترنة بها، راجع موفري الموارد.

ينظم Azure Monitor بالمثل بيانات المراقبة الأساسية في مقاييس وسجلات استنادا إلى أنواع الموارد، وتسمى أيضا مساحات الأسماء. تتوفر مقاييس وسجلات مختلفة أنواع موارد مختلفة. قد تكون خدمتك مقترنة بأكثر من نوع مورد واحد.

لمزيد من المعلومات حول أنواع الموارد في AKS، راجع مرجع بيانات مراقبة AKS.

تخزين البيانات.

بالنسبة إلى Azure Monitor:

  • يتم تخزين بيانات المقاييس في قاعدة بيانات مقاييس Azure Monitor.
  • يتم تخزين بيانات السجل في مخزن سجلات Azure Monitor. Log Analytics هي أداة في مدخل Microsoft Azure يمكنها الاستعلام عن هذا المتجر.
  • سجل نشاط Azure هو مخزن منفصل بواجهة خاصة به في مدخل Microsoft Azure.

يمكنك اختياريا توجيه بيانات سجل المقاييس والنشاط إلى مخزن سجلات Azure Monitor. يمكنك بعد ذلك استخدام Log Analytics للاستعلام عن البيانات وربطها ببيانات السجل الأخرى.

يمكن للعديد من الخدمات استخدام إعدادات التشخيص لإرسال بيانات القياس والسجل إلى مواقع التخزين الأخرى خارج Azure Monitor. تتضمن الأمثلة تخزين Azure وأنظمة الشركاء المستضافة وأنظمة الشركاء غير Azure باستخدام مراكز الأحداث.

للحصول على معلومات مفصلة حول كيفية تخزين Azure Monitor للبيانات، راجع النظام الأساسي لبيانات Azure Monitor.

مقاييس النظام الأساسي ل Azure Monitor

يوفر Azure Monitor مقاييس النظام الأساسي لمعظم الخدمات. هذه المقاييس هي:

  • معرف بشكل فردي لكل مساحة اسم.
  • مخزن في قاعدة بيانات مقاييس السلسلة الزمنية ل Azure Monitor.
  • خفيف الوزن وقادر على دعم التنبيه في الوقت الفعلي تقريبا.
  • يستخدم لتعقب أداء مورد بمرور الوقت.

المجموعة: يجمع Azure Monitor مقاييس النظام الأساسي تلقائيا. لا يلزم التكوين.

التوجيه: يمكنك أيضا توجيه بعض مقاييس النظام الأساسي إلى Azure Monitor Logs / Log Analytics حتى تتمكن من الاستعلام عنها باستخدام بيانات السجل الأخرى. تحقق من إعداد تصدير DS لكل مقياس لمعرفة ما إذا كان يمكنك استخدام إعداد تشخيص لتوجيه المقياس إلى سجلات Azure Monitor / Log Analytics.

للحصول على قائمة بجميع المقاييس، من الممكن جمعها لجميع الموارد في Azure Monitor، راجع المقاييس المدعومة في Azure Monitor.

للحصول على قائمة بالمقاييس التي يمكنك جمعها ل AKS، راجع مرجع بيانات مراقبة AKS.

تلعب المقاييس دورا مهما في مراقبة المجموعات، وتحديد المشكلات، وتحسين الأداء في مجموعات AKS. تنشئ AKS مقاييس النظام الأساسي التي Azure Monitor تجمع تلقائيا دون تكوين. يجب عليك أيضا تمكين الخدمة المدارة لمقاييس Prometheus لجمع مقاييس الحاوية ومقاييس كائن Kubernetes، بما في ذلك حالة نشر العنصر.

في AKS Automatic، الخدمة المدارة لبروميثيوس مفعلة بشكل افتراضي، لذا تبدأ بقاعدة مقاييس جاهزة للإنتاج بدون إعدادات إضافية.

يمكنك عرض قائمة الخدمة المدارة الافتراضية لمقاييس Prometheus.

لمزيد من المعلومات، راجع تجميع الخدمة المدارة لمقاييس Prometheus من مجموعة AKS.

المقاييس غير المستندة إلى Azure Monitor

توفر هذه الخدمة مقاييس أخرى غير مضمنة في قاعدة بيانات مقاييس Azure Monitor.

يمكنك استخدام خدمات Azure التالية وميزات Azure Monitor لمراقبة مجموعات AKS. في AKS Automatic، يشمل خط المراقبة الافتراضي بالفعل خدمة مدارة لأجهزة Prometheus وContainer insights ولوحات تحكم Azure Monitor مع Grafana. في AKS Standard، يمكنك تفعيل هذه الميزات عند إنشاء عنقود أو دمج العنقود لاحقا.

في مدخل Microsoft Azure، استخدم علامة التبويب Integrations ، أو استخدم Azure CLI أو Terraform أو نهج Azure. في بعض الحالات، يمكنك إلحاق نظام المجموعة الخاص بك بخدمة مراقبة أو ميزة بعد إنشاء نظام المجموعة. قد تتحمل كل خدمة أو ميزة تكلفة، لذا راجع معلومات التسعير لكل مكون قبل تمكينه.

الخدمة أو الميزة ‏‏الوصف
نتائج تحليلات الحاوية يستخدم إصدار حاوية من عامل Azure Monitor لتجميع stdoutstderr وسجلات وأحداث Kubernetes من كل عقدة في نظام المجموعة الخاص بك. تدعم الميزة مجموعة متنوعة من سيناريوهات المراقبة لمجموعات AKS. يمكنك تمكين المراقبة لمجموعة AKS عند إنشاؤها باستخدام Azure CLI، أو سياسة Azure، أو بوابة Azure، أو Terraform. إذا لم تقم بتمكين نتائج تحليلات الحاوية عند إنشاء نظام المجموعة، فشاهد تمكين نتائج تحليلات الحاوية لمجموعة AKS للحصول على خيارات أخرى لتمكينها.

تخزن نتائج تحليلات الحاوية معظم بياناتها في مساحة عمل Log Analytics. عادة ما تستخدم نفس مساحة عمل Log Analytics مثل سجلات الموارد للمجموعة الخاصة بك. للحصول على إرشادات حول عدد مساحات العمل التي يجب استخدامها ومكان تحديد موقعها، راجع تصميم بنية مساحة عمل Log Analytics.
خدمة مدارة ل Prometheus في Azure Monitor Prometheus هو حل مقاييس سحابية أصلية من Cloud Native Computing Foundation. إنها الأداة الأكثر شيوعا لاستخدامها لجمع وتحليل البيانات القياسية من مجموعات Kubernetes. الخدمة المدارة ل Prometheus في Azure Monitor هي حل مراقبة متوافق مع Prometheus مدار بالكامل. إذا لم تقم بتمكين الخدمة المدارة ل Prometheus عند إنشاء نظام المجموعة الخاص بك، فشاهد تجميع مقاييس Prometheus من مجموعة AKS للحصول على خيارات أخرى لتمكينها.

تخزن الخدمة المدارة ل Prometheus في Azure Monitor بياناتها في مساحة عمل Azure Monitorالمرتبطة بمساحة عمل Grafana. يمكنك استخدام Azure Managed Grafana لتحليل البيانات.
Azure Managed Grafana تنفيذ مدار بالكامل ل Grafana. Grafana هو نظام أساسي لتصور البيانات مفتوح المصدر يستخدم عادة لتقديم بيانات Prometheus. تتوفر لوحات معلومات Grafana متعددة معرفة مسبقا لمراقبة Kubernetes واستكشاف الأخطاء وإصلاحها بالكامل. إذا لم تقم بتمكين Azure Managed Grafana عند إنشاء نظام المجموعة، فشاهد ربط مساحة عمل Grafana. يمكنك ربطه بمساحة عمل Azure Monitor بحيث يمكنه الوصول إلى مقاييس Prometheus من مجموعتك.

مراقبة مقاييس مستوى التحكم في AKS (معاينة)

المتطلبات الأساسية والنطاق: تتطلب ميزة المعاينة هذه نظام مجموعة AKS يستخدم مصادقة الهوية المدارة ولديه الخدمة المدارة ل Prometheus ممكنة. يجب عليك أيضا تسجيل علامة الميزة AzureMonitorMetricsControlPlanePreview . Azure Private Link غير مدعوم، ويمكنك تخصيص ملف التكوين الافتراضي ama-metrics-settings-configmap.yaml فقط.

تعرض AKS أيضا مقاييس من مكونات وحدة التحكم الهامة مثل خادم API، وما إلى ذلك، والمجدول من خلال الخدمة المدارة ل Prometheus في Azure Monitor. حاليا، هذه الميزة قيد المعاينة. لمزيد من المعلومات، راجع مراقبة مقاييس وحدة التحكم AKS. تتوفر مجموعة فرعية من مقاييس مستوى التحكم لخادم API وما إلى ذلك مجانا من خلال مقاييس النظام الأساسي ل Azure Monitor. يتم جمع هذه المقاييس بشكل افتراضي. يمكنك استخدام المقاييس لإنشاء تنبيهات.

سجلات موارد Azure Monitor

توفر سجلات الموارد نظرة ثاقبة على العمليات التي تم إجراؤها بواسطة مورد Azure. يتم إنشاء السجلات تلقائيا، ولكن يجب توجيهها إلى سجلات Azure Monitor لحفظها أو الاستعلام عنها. يتم تنظيم السجلات في فئات. قد تحتوي مساحة الاسم المحددة على فئات سجل موارد متعددة.

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

التوجيه: الافتراضي المقترح هو توجيه سجلات الموارد إلى سجلات Azure Monitor حتى تتمكن من الاستعلام عنها باستخدام بيانات السجل الأخرى. تتوفر أيضا مواقع أخرى مثل تخزين Azure ومراكز أحداث Azure وبعض شركاء مراقبة Microsoft. لمزيد من المعلومات، راجع سجلات موارد Azure ووجهات سجل الموارد.

للحصول على معلومات مفصلة حول جمع سجلات الموارد وتخزينها وتوجيهها، راجع إعدادات التشخيص في Azure Monitor.

للحصول على قائمة بجميع فئات سجل الموارد المتوفرة في Azure Monitor، راجع سجلات الموارد المدعومة في Azure Monitor.

تحتوي جميع سجلات الموارد في Azure Monitor على نفس حقول العنوان، متبوعة بالحقول الخاصة بالخدمة. المخطط الشائع مُوضح في مخطط سجل الموارد في Azure Monitor.

للحصول على فئات سجل الموارد المتوفرة وجداول Log Analytics المقترنة بها ومخططات السجل ل AKS، راجع مرجع بيانات مراقبة AKS.

سجلات موارد وحدة التحكم AKS

المتطلبات الأساسية: يتطلب مساحة عمل Log Analytics. يمكن أن تكون مساحة العمل في اشتراك مختلف إذا كان الشخص الذي يقوم بتكوين إعداد التشخيص لديه حق الوصول المناسب Azure التحكم في الوصول المستند إلى الدور (RBAC) إلى كلا الاشتراكين. بالنسبة لمساحة عمل في مستأجر Microsoft Entra آخر، استخدم Azure Lighthouse. تتحمل سجلات الموارد تكاليف الاستقبال والاحتفاظ في مساحة العمل الوجهة. لتحسين التكاليف، استخدم وضع المورد الخاص وقم بتكوين مستوى سجلات Basic لجداول التدقيق. لمزيد من المعلومات، راجع وجهات إعدادات التشخيص.

يتم تنفيذ سجلات وحدة التحكم لمجموعات AKS كسجلات موارد في Azure Monitor. لا يتم تجميع سجلات الموارد وتخزينها حتى تقوم بإنشاء إعداد تشخيص لتوجيهها إلى موقع واحد على الأقل. عادة ما ترسل سجلات الموارد إلى مساحة عمل Log Analytics، حيث يتم تخزين معظم بيانات نتائج تحليلات الحاوية.

لتعلم كيفية إنشاء إعداد تشخيصي باستخدام بوابة Azure أو واجهة تحكم Azure أو Azure PowerShell، راجع إنشاء إعدادات التشخيص. عند إنشاء إعداد تشخيص، فإنك تحدد فئات السجلات المراد تجميعها. يتم سرد فئات AKS في مرجع بيانات مراقبة AKS.

تحذير

يمكنك تحمل تكلفة كبيرة عند جمع سجلات الموارد ل AKS، خاصة لسجلات تدقيق kube . ضع في اعتبارك التوصيات التالية لتقليل كمية البيانات التي تم جمعها:

  • تعطيل kube-audit التسجيل عندما لا يكون مطلوبا.
  • تمكين المجموعة من kube-audit-admin، والتي تستبعد get أحداث و list التدقيق.
  • تمكين السجلات الخاصة بالموارد كما هو موضح في هذه المقالة، وتكوين جدول AKSAuditكسجلات أساسية.

لمزيد من توصيات المراقبة، راجع مراقبة مجموعات AKS باستخدام خدمات Azure والأدوات السحابية الأصلية. للحصول على استراتيجيات لتقليل تكاليف المراقبة، راجع تحسين التكلفة وAzure Monitor.

يدعم AKS إما وضع تشخيص Azure أو الوضع الخاص بالموارد لسجلات الموارد. يرسل وضع تشخيص Azure جميع البيانات إلى جدول AzureDiagnostics. يحدد الوضع الخاص بالموارد الجداول في مساحة عمل Log Analytics حيث يتم إرسال البيانات. كما يرسل البيانات إلى AKSAuditو AKSAuditAdminو AKSControlPlane كما هو موضح في الجدول في سجلات الموارد.

نوصي باستخدام الوضع الخاص بالموارد ل AKS للأسباب التالية:

  • من الأسهل الاستعلام عن البيانات لأنها موجودة في جداول فردية مخصصة ل AKS.
  • يدعم الوضع الخاص بالموارد التكوين كسجلات أساسية لتحقيق وفورات كبيرة في التكاليف.

لمزيد من المعلومات حول الفرق بين أوضاع المجموعة، بما في ذلك كيفية تغيير إعداد موجود، راجع تحديد وضع المجموعة.

إشعار

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

az monitor diagnostic-settings create --name AKS-Diagnostics --resource /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myresourcegroup/providers/Microsoft.ContainerService/managedClusters/my-cluster --logs '[{"category": "kube-audit","enabled": true}, {"category": "kube-audit-admin", "enabled": true}, {"category": "kube-apiserver", "enabled": true}, {"category": "kube-controller-manager", "enabled": true}, {"category": "kube-scheduler", "enabled": true}, {"category": "cluster-autoscaler", "enabled": true}, {"category": "cloud-controller-manager", "enabled": true}, {"category": "guard", "enabled": true}, {"category": "csi-azuredisk-controller", "enabled": true}, {"category": "csi-azurefile-controller", "enabled": true}, {"category": "csi-snapshot-controller", "enabled": true}]'  --workspace /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/myresourcegroup/providers/microsoft.operationalinsights/workspaces/myworkspace --export-to-resource-specific true

استعلامات وأمثلة سجل موارد AKS

متطلبات نطاق الاستعلام: عند اختيار سجلات في قائمة عنقود AKS، يفتح Log Analytics مع تعيين نطاق الاستعلام على الcluster الحالي. تتضمن استعلامات السجل بيانات من هذا المورد فقط. لتشغيل الاستعلامات التي تتضمن بيانات من مجموعات أخرى أو خدمات Azure، اختر Logs من قائمة Azure Monitor .

إذا كانت إعدادات التشخيص في العنقود تستخدم وضع Azure diagnostics، فإن سجلات الموارد ل AKS مخزنة في جدول AzureDiagnostics . تحديد السجلات عبر عمود الفئة . للحصول على وصف لكل فئة، راجع سجلات الموارد المرجعية لـ AKS.

‏‏الوصف وضع الاستعلام عن السجل
عدد السجلات لكل فئة وضع تشخيص Azure AzureDiagnostics
| where ResourceType == "MANAGEDCLUSTERS"
| summarize count() by Category
جميع سجلات خادم واجهة برمجة التطبيقات وضع تشخيص Azure AzureDiagnostics
| where Category == "kube-apiserver"
جميع سجلات تدقيق kube في نطاق زمني وضع تشخيص Azure let starttime = datetime("2023-02-23");
let endtime = datetime("2023-02-24");
AzureDiagnostics
| where TimeGenerated between(starttime..endtime)
| where Category == "kube-audit"
| extend event = parse_json(log_s)
| extend HttpMethod = tostring(event.verb)
| extend User = tostring(event.user.username)
| extend Apiserver = pod_s
| extend SourceIP = tostring(event.sourceIPs[0])
| project TimeGenerated, Category, HttpMethod, User, Apiserver, SourceIP, OperationName, event
كافة سجلات التدقيق وضع المورد الخاص AKSAudit
جميع سجلات التدقيق باستثناء get أحداث التدقيق list وضع المورد الخاص AKSAuditAdmin
جميع سجلات خادم واجهة برمجة التطبيقات وضع المورد الخاص AKSControlPlane
| where Category == "kube-apiserver"

للوصول إلى مجموعة من الاستعلامات التي تم إنشاؤها مسبقا في مساحة عمل Log Analytics، راجع واجهة استعلامات Log Analytics، وحدد نوع مورد Kubernetes Services . للحصول على قائمة بالاستعلامات الشائعة لرؤى الحاوية، راجع استعلامات نتائج تحليلات الحاوية.

سياسة تدقيق AKS

يستخدم AKS سياسة تدقيق Kubernetes للتحكم في الأحداث المسجلة وما هي البيانات التي تحتويها. تعرف السياسة قواعد تحدد مستوى التدقيق لأنواع طلبات API المختلفة بناء على المستخدمين والموارد ومساحات الأسماء والأفعال. تستخدم مستويات التدقيق التالية:

  • لا شيء: الأحداث التي تطابق هذه القاعدة لا يتم تسجيلها.
  • البيانات الوصفية: بيانات تعريف طلب السجل (طلب المستخدم، الطابع الزمني، المورد، الفعل) ولكن ليست طلب أو جسم الرد.
  • طلب: سجل بيانات الحدث الوصفية وجسم الطلب وليس جسم الرد.
  • RequestResponse: سجل بيانات وصفية للأحداث، وأجسام الطلبات والرد.

يلخص الجدول التالي قواعد سياسة التدقيق الرئيسية المطبقة في AKS:

مستوى التدقيق ‏‏الوصف مثال الأحداث
بلا عمليات قراءة عالية الحجم ومنخفضة المخاطر aksServiceعمليات المستخدمget/list، kube-proxy مراقبة نقاط النهاية/الخدمات، Kubelet get على العقد/حالة العقد، عناوين التحقق من الصحة (/healthz*, /version, ) /swagger*
Metadata أحداث النظام، موارد الأحداث (باستثناء الإنشاءات/التحديثات في default/kube-system)، الأسرار، خرائط الإعدادات، حسابات الخدمة، مراجعات الرموز مراجعات الرموز، الوصول السري/خريطة التهيئة السرية، CRDs الكبيرة مثل installations.operator.tigera.io
Request تحديثات حالة العقد والوحدات من الكوبليت/العقد، عمليات الجمع المحذوفة، تحديثات CRD لقطات الحجم، عمليات القراءة (get/list/watch) على مجموعات واجهات برمجة التطبيقات الأساسية، تغييرات VPA تحديثات حالة Kubelet، حذف مساحة الأسماء، تحديثات نقاط التحقق الخاصة ب VPA
RequestResponse تحديثات خرائط التكوين المخصصة ل CoreDNS، عمليات واجهة برمجة التطبيقات للأسطول، تغييرات موارد كاربنتر، جميع عمليات الكتابة الأخرى على مجموعات واجهات برمجة التطبيقات الأساسية تغييرات تكوين CoreDNS، عمليات عنقود أعضاء الأسطول، تغييرات تجمع عقد Karpenter

سياسة التدقيق الكاملة المستخدمة في AKS متاحة للمراجعة في القسم التالي القابل للطي.

عرض سياسة التدقيق الكاملة ل AKS 
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # audit level 'None' for high volume and low risk events
  - level: None
    users: ["aksService"]
    verbs: ["get", "list"]
  # audit level 'None' for low-risk requests
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
      - group: ""
        resources: ["endpoints", "services", "services/status"]
  # audit level 'None' for low-risk requests
  - level: None
    users: ["kubelet"] # legacy kubelet identity
    verbs: ["get"]
    resources:
      - group: ""
        resources: ["nodes", "nodes/status"]
  # audit level 'None' for low-risk requests
  - level: None
    userGroups: ["system:nodes"]
    verbs: ["get"]
    resources:
      - group: ""
        resources: ["nodes", "nodes/status"]
  # audit level 'None' for low-risk requests
  - level: None
    users:
      - aksService # the default user/cert used by aks in master node
      - system:serviceaccount:kube-system:endpoint-controller
    verbs: ["get", "update"]
    namespaces: ["kube-system"]
    resources:
      - group: ""
        resources: ["endpoints"]
  # audit level 'None' for low-risk requests
  - level: None
    users: ["system:apiserver"]
    verbs: ["get"]
    resources:
      - group: ""
        resources: ["namespaces", "namespaces/status", "namespaces/finalize"]
  # audit level 'None' for low-risk requests
  - level: None
    users:
      - aksService # the default user/cert used by aks in master node
    verbs: ["get", "list"]
    resources:
      - group: "metrics.k8s.io"
  # Don't log these read-only URLs.
  - level: None
    nonResourceURLs:
      - /healthz*
      - /version
      - /swagger*
  # monitor metadata for system events which are being logged by eventlogger component
  - level: Metadata
    verbs: ["create", "update", "patch"]
    resources:
      - group: ""
        resources: ["events"]
      - group: "events.k8s.io"
        resources: ["events"]
    namespaces: ["default", "kube-system"]
  # Monitoring of actions to detect security/performance relevant activities.
  - level: Metadata
    verbs: ["delete", "list"]
    resources:
      - group: ""
        resources: ["events"]
      - group: "events.k8s.io"
        resources: ["events"]
  # Don't log other events requests.
  - level: None
    resources:
      - group: ""
        resources: ["events"]
      - group: "events.k8s.io"
        resources: ["events"]
  # node and pod status calls from nodes are high-volume and can be large, don't log responses for expected updates from nodes
  - level: Request
    users: ["client", "kubelet", "system:node-problem-detector", "system:serviceaccount:kube-system:node-problem-detector", "system:serviceaccount:kube-system:aci-connector-linux"]
    verbs: ["update","patch"]
    resources:
      - group: ""
        resources: ["nodes/status", "pods/status"]
    omitStages:
      - "RequestReceived"
  # node and pod status calls from nodes are high-volume and can be large, don't log responses for expected updates from nodes
  - level: Request
    userGroups: ["system:nodes"]
    verbs: ["update","patch"]
    resources:
      - group: ""
        resources: ["nodes/status", "pods/status"]
    omitStages:
      - "RequestReceived"
  # deletecollection calls can be large, don't log responses for expected namespace deletions
  - level: Request
    users: ["system:serviceaccount:kube-system:namespace-controller"]
    verbs: ["deletecollection"]
    omitStages:
      - "RequestReceived"
  # ignore response object that has big size
  - level: Request
    verbs: ["update","patch"]
    resources:
      - group: "apiextensions.k8s.io"
        resources: ["customresourcedefinitions"]
        resourceNames: ["volumesnapshotcontents.snapshot.storage.k8s.io", "volumesnapshots.snapshot.storage.k8s.io"]
    omitStages:
      - "RequestReceived"
  # ignore request and response objects for large CRDs that will be filtered down anyway
  - level: Metadata
    resources:
      - group: "apiextensions.k8s.io"
        resources: ["customresourcedefinitions"]
        resourceNames: ["installations.operator.tigera.io"]
    omitStages:
      - "RequestReceived"
  # overriding the default behavior of coredns might have security threats for Kubernetes DNS in security perspective, set the level as RequestResponse
  - level: RequestResponse
    verbs: ["update","patch"]
    resources:
      - group: ""
        resources: ["configmaps"]
        resourceNames: ["coredns-custom"]
    namespaces: ["kube-system"]
    omitStages:
      - "RequestReceived"
  # Secrets, ConfigMaps, ServiceAccounts, TokenRequest and TokenReviews can contain sensitive & binary data,
  # so only log at the Metadata level.
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets", "configmaps", "serviceaccounts", "serviceaccounts/token"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
    omitStages:
      - "RequestReceived"
  # Capture state of vertical pod autoscalers
  - level: Request
    verbs: ["create", "update", "patch", "delete"]
    resources:
      - group: "autoscaling.k8s.io"
        resources: ["verticalpodautoscalers", "verticalpodautoscalercheckpoints"]
    omitStages:
      - "RequestReceived"
  # Capture create and delete of internal fleet resources
  - level: RequestResponse
    verbs: ["create", "delete"]
    resources:
      - group: "cluster.kubernetes-fleet.io"
        resources: ["memberclusters", "internalmemberclusters"]
      - group: "placement.kubernetes-fleet.io"
        resources: ["works"]
      - group: "networking.fleet.azure.com"
        resources: ["internalserviceexports", "internalserviceimports"]
    omitStages:
      - "RequestReceived"
  # Capture CUD of user facing Fleet API
  - level: RequestResponse
    verbs: ["create", "update", "patch", "delete"]
    resources:
      - group: "placement.kubernetes-fleet.io"
        resources: ["clusterstagedupdateruns", "clusterresourceplacements", "clusterresourceplacementevictions", "clusterresourceplacementdisruptionbudgets", "clusterstagedupdatestrategies", "clusterapprovalrequests", "clusterresourceoverrides", "resourceoverrides"]
      - group: "networking.fleet.azure.com"
        resources: ["serviceexports", "multiclusterservices", "trafficmanagerprofiles", "trafficmanagerbackends"]
    omitStages:
      - "RequestReceived"
  # Capture CUD of user facing Karpenter resources
  - level: RequestResponse
    verbs: ["create", "update", "patch", "delete"]
    resources:
      - group: "karpenter.azure.com"
        resources: ["aksnodeclasses", "aksnodeclasses/status"]
      - group: "karpenter.sh"
        resources: ["nodepools", "nodepools/status", "nodeclaims", "nodeclaims/status"]
    omitStages:
      - "RequestReceived"
  # Get responses can be large; don't log response
  - level: Request
    verbs: ["get", "list", "watch"]
    resources:
      - group: ""
      - group: "admissionregistration.k8s.io"
      - group: "apiextensions.k8s.io"
      - group: "apiregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "metrics.k8s.io"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "scheduling.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
    omitStages:
      - "RequestReceived"
  # Default level for known APIs
  - level: RequestResponse
    resources:
      - group: ""
      - group: "admissionregistration.k8s.io"
      - group: "apiextensions.k8s.io"
      - group: "apiregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "metrics.k8s.io"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "scheduling.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
    omitStages:
      - "RequestReceived"
  # Default level for all other requests.
  - level: Metadata
    omitStages:
      - "RequestReceived"

إشعار

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

سجلات نتائج تحليلات حاوية وحدة بيانات AKS

المتطلبات المسبقة ومتطلبات التكوين: تتطلب Container Insights مساحة عمل Log Analytics لتخزين السجلات وتدعم طرق المصادقة المدارة والتحقق القديم. بالنسبة للمجموعات الجديدة، يوصى بالمصادقة المدارة للهوية. يمكن تخصيص جمع البيانات باستخدام قواعد جمع البيانات لمراقبة Azure (DCRs) للتحكم في التكاليف وتقليل حجم الاستقبال.

تجمع نتائج تحليلات الحاوية أنواعا مختلفة من بيانات تتبع الاستخدام من الحاويات ومجموعات AKS لمساعدتك في مراقبة واستكشاف الأخطاء وإصلاحها واكتساب رؤى حول التطبيقات الحاوية التي تعمل في مجموعات AKS الخاصة بك. للحصول على قائمة بالجداول والأوصاف التفصيلية الخاصة بها التي تستخدمها نتيجة تحليلات الحاوية، راجع مرجع جدول Azure Monitor. تتوفر جميع الجداول للاستعلامات الخاصة بالسجل.

في AKS Automatic، يتم تفعيل رؤى الحاوية افتراضيا كجزء من خط المراقبة الأساسي.

استخدم إعدادات تحسين التكلفة لتخصيص بيانات المقاييس التي تم جمعها من خلال عامل نتائج تحليلات الحاوية والتحكم فيها. تدعم هذه الميزة إعدادات جمع البيانات لتحديد الجدول الفردي والفواصل الزمنية لجمع البيانات ومساحات الأسماء لاستبعاد جمع البيانات من خلال قواعد تجميع بيانات Azure Monitor (DCRs). تتحكم هذه الإعدادات في حجم الاستيعاب وتقلل من تكاليف مراقبة نتائج تحليلات الحاوية. يمكنك تخصيص بيانات رؤى الحاوية التي جمعتها في بوابة Azure باستخدام الخيارات التالية. تحديد أي خيارات أخرى غير الكل (افتراضي) يجعل تجربة نتائج تحليلات الحاوية غير متوفرة.

التجميع الجداول ملاحظات
الكل (افتراضي) جميع جداول نتائج تحليلات الحاوية القياسية مطلوب لتمكين مرئيات نتائج تحليلات الحاوية الافتراضية.
الأداء Perf و InsightsMetrics ‏‫غير متوفر‬
السجلات والأحداث ContainerLog أو ContainerLogV2، KubeEvents، KubePodInventory يوصى به إذا قمت بتمكين الخدمة المدارة لمقاييس Prometheus.
أحمال العمل والنشرات وHPAs InsightsMetrics، KubePodInventory، KubeEvents، ContainerInventory، ContainerNodeInventory، KubeNodeInventory، KubeServices ‏‫غير متوفر‬
وحدات التخزين الثابتة InsightsMetrics، KubePVInventory ‏‫غير متوفر‬

يلتقط تجميع السجلات والأحداث السجلات من جداول ContainerLog أو ContainerLogV2وKubeEventsوKubePodInventory ، ولكن ليس المقاييس. المسار الموصى به لجمع المقاييس هو تمكين الخدمة المدارة ل Prometheus من مجموعة AKS واستخدام Azure Managed Grafana لتصور البيانات. لمزيد من المعلومات، راجع إدارة مساحة عمل Azure Monitor.

مخطط ContainerLogV2

متطلبات التوافق والتكوين: استخدم مخطط ContainerLogV2 لنشر نتائج تحليلات الحاوية الجديدة التي تستخدم مصادقة الهوية المدارة عبر قوالب Azure Resource Manager (ARM) أو Bicep أو Terraform أو نهج Azure أو مدخل Azure. يدعم المخطط طبقة السجلات الأساسية لتوفير التكاليف. تدعم السجلات الأساسية تنبيهات بحث السجل البسيطة، ولكن التنبيه المتقدم يتطلب سجلات Analytics-tier. للتنبيه المجمع أو شبه الحقيقي، استخدم Prometheus المدار عند توفر المقاييس أو قواعد الملخص أو توجيه البيانات المحددة إلى طبقة التحليلات مع التحويلات. لمزيد من المعلومات، راجع تمكين مخطط ContainerLogV2واستراتيجيات التنبيه الفعالة من حيث التكلفة ل AKS.

توفر نتائج تحليلات الحاوية في Azure Monitor مخططا موصى به لسجلات الحاوية، ContainerLogV2. يتضمن التنسيق الحقول التالية للاستعلامات الشائعة لعرض البيانات المتعلقة ب AKS ومجموعات Kubernetes الممكنة في Azure Arc:

  • اسم الحاوية
  • PodName
  • PodNamespace

سجل الأنشطة Azure

يحتوي سجل النشاط على أحداث على مستوى الاشتراك تتعقب العمليات لكل مورد Azure كما هو ظاهر من خارج هذا المورد؛ على سبيل المثال، إنشاء مورد جديد أو بدء تشغيل جهاز ظاهري.

المجموعة: يتم إنشاء أحداث سجل النشاط تلقائيا وتجميعها في مخزن منفصل للعرض في مدخل Microsoft Azure.

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

عرض سجلات حاوية AKS والأحداث ومقاييس الجراب في الوقت الفعلي

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

يمكنك عرض سجلات الحاويات والأحداث ومقاييس الوحدات باستخدام ميزة البيانات الحية في Container Insights وحل المشكلات في الوقت الحقيقي مع الوصول المباشر إلى kubectl logs -c، kubectl get الأحداث و kubectl top pods.

إشعار

تستخدم AKS بنيات التسجيل على مستوى نظام المجموعة Kubernetes. توجد سجلات الحاوية في /var/log/containers على العقدة. للوصول إلى عقدة، راجع الاتصال بعقد نظام مجموعة AKS.

لمعرفة كيفية إعداد هذه الميزة، راجع تكوين البيانات المباشرة في نتائج تحليلات الحاوية. تصل الميزة مباشرة إلى واجهة برمجة تطبيقات Kubernetes. لمزيد من المعلومات حول نموذج المصادقة، راجع واجهة برمجة تطبيقات Kubernetes.

عرض السجلات المباشرة لمورد AKS

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

  1. في مدخل Microsoft Azure، انتقل إلى نظام مجموعة AKS.

  2. ضمن موارد Kubernetes، حدد Workloads.

  3. بالنسبة إلى Deployment أو Pod أو Replica Set أو Stateful Set أو Job أو Cron Job، حدد قيمة، ثم حدد Live Logs.

  4. حدد سجل موارد لعرضه.

    يوضح المثال التالي سجلات مورد pod:

    لقطة شاشة تعرض نشر السجلات المباشرة.

عرض سجلات الحاوية الحية باستخدام Container Insights

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

يمكنك عرض بيانات السجل في الوقت الحقيقي أثناء إنشاء محرك الحاوية لها في علامة التبويب Cluster أو Nodes أو Controllers أو Containers .

  1. في مدخل Microsoft Azure، انتقل إلى نظام مجموعة AKS.

  2. ثم، ضمن Monitoring، حدد Insights.

  3. في علامة التبويب Cluster أو Nodes أو Controllers أو Containers ، حدد قيمة.

  4. في جزء Overview للمورد، حدد Live Logs.

    تعرض الصورة التالية سجلات مورد حاوية:

    لقطة شاشة تعرض خيار سجلات مباشرة للحاوية لعرض البيانات.

عرض أحداث الحاوية الحية باستخدام Container Insights

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

يمكنك عرض بيانات الحدث في الوقت الحقيقي أثناء إنشاء محرك الحاوية لها في علامة التبويب Cluster أو Nodes أو Controllers أو Containers .

  1. في مدخل Microsoft Azure، انتقل إلى نظام مجموعة AKS.

  2. ثم، ضمن Monitoring، حدد Insights.

  3. حدد علامة التبويب Cluster أو Nodes أو Controllers أو Containers ، ثم حدد عنصرا.

  4. في جزء نظرة عامة على المورد، حدد الأحداث المباشرة.

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

    لقطة شاشة تعرض خيار الحاوية Live Events لعرض البيانات.

عرض مقاييس البودك الحية باستخدام Container Insights

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

يمكنك عرض بيانات المقاييس في الوقت الحقيقي حيث يقوم محرك الحاوية بإنشائه في علامة التبويب Nodes أو Controllers عن طريق تحديد مورد pod.

  1. في مدخل Microsoft Azure، انتقل إلى نظام مجموعة AKS.

  2. ثم، ضمن Monitoring، حدد Insights.

  3. حدد علامة التبويب Nodes أو Controllers ، ثم حدد كائن pod.

  4. في جزء نظرة عامة على المورد، حدد Live Metrics.

    بعد المصادقة الناجحة، إذا كان من الممكن استرداد البيانات، فإنها تبدأ في البث إلى علامة التبويب Live Metrics . تعرض الصورة التالية مقاييس مورد pod:

    لقطة شاشة تعرض خيار pod Live Metrics لعرض البيانات.

    تحليل بيانات المراقبة

    هناك العديد من الأدوات لتحليل بيانات المراقبة.

    أدوات Azure Monitor

    يدعم Azure Monitor الأدوات الأساسية التالية:

    • مستكشف المقاييس، أداة في مدخل Microsoft Azure تسمح لك بعرض وتحليل المقاييس لموارد Azure. لمزيد من المعلومات، راجع تحليل المقاييس باستخدام مستكشف مقاييس Azure Monitor.

    • Log Analytics، أداة في مدخل Microsoft Azure تسمح لك بالاستعلام عن بيانات السجل وتحليلها باستخدام لغة استعلام Kusto (KQL). لمزيد من المعلومات، راجع البدء في استعلامات السجل في Azure Monitor.

    • سجل النشاط، الذي يحتوي على واجهة مستخدم في مدخل Microsoft Azure للعرض وعمليات البحث الأساسية. لإجراء تحليل أكثر تعمقا، يجب عليك توجيه البيانات إلى سجلات Azure Monitor وتشغيل استعلامات أكثر تعقيدا في Log Analytics.

    تتضمن الأدوات التي تسمح بتصور أكثر تعقيدا ما يلي:

    • لوحات المعلومات التي تتيح لك دمج أنواع مختلفة من البيانات في جزء واحد في مدخل Microsoft Azure.
    • المصنفات والتقارير القابلة للتخصيص التي يمكنك إنشاؤها في مدخل Microsoft Azure. يمكن أن تتضمن المصنفات النص والمقاييس واستعلامات السجل.
    • Grafana، أداة منصة مفتوحة تتفوق في لوحات المعلومات التشغيلية. يمكنك استخدام Grafana لإنشاء لوحات معلومات تتضمن بيانات من مصادر متعددة غير Azure Monitor.
    • Power BI، خدمة تحليلات الأعمال التي توفر مرئيات تفاعلية عبر مصادر بيانات مختلفة. يمكنك تكوين Power BI لاستيراد بيانات السجل تلقائيًا من Azure Monitor للاستفادة من هذه المرئيات.

    أدوات تصدير Azure Monitor

    يمكنك الحصول على البيانات من Azure Monitor في أدوات أخرى باستخدام الطرق التالية:

    • المقاييس: استخدم واجهة برمجة تطبيقات REST للمقاييس لاستخراج بيانات القياس من قاعدة بيانات مقاييس Azure Monitor. تدعم واجهة برمجة التطبيقات تعبيرات التصفية لتحسين البيانات التي تم استردادها. لمزيد من المعلومات، راجع مرجع Azure Monitor REST API.

    • السجلات: استخدم واجهة برمجة تطبيقات REST أو مكتبات العميل المقترنة.

    • خيار آخر هو تصدير بيانات مساحة العمل.

    لبدء استخدام واجهة برمجة تطبيقات REST ل Azure Monitor، راجع معاينة واجهة برمجة تطبيقات REST لمراقبة Azure.

مراقبة مجموعات AKS في بوابة Azure

توفر علامة التبويب Monitoring في جزء Overview لمورد نظام مجموعة AKS طريقة سريعة لبدء عرض بيانات المراقبة في مدخل Microsoft Azure. تتضمن علامة التبويب هذه رسوما بيانية مع مقاييس شائعة للمجموعة مفصولة بتجمع عقدة. يمكنك تحديد أي من هذه الرسوم البيانية لتحليل البيانات في مستكشف المقاييس بشكل أكبر.

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

في AKS Automatic، تتوفر لوحات تحكم Azure Monitor مع Grafana بشكل افتراضي في تجربة بوابة Azure.

تلميح

للوصول إلى ميزات المراقبة لجميع مجموعات AKS في اشتراكك، في الصفحة الرئيسية لمدخل Azure، حدد Azure Monitor.

مراقبة واستكشاف المشكلات في التطبيقات باستخدام سطح مكتب AKS

AKS desktop هو تجربة سطح مكتب تركز على التطبيقات لخدمة خدمة Azure Kubernetes ‏(AKS)، وتساعدك على الاتصال بالعناصر، وعرض الموارد، ونشر التطبيقات، واستكشاف أعباء العمل دون خبرة عميقة في Kubernetes.

يكمل سطح مكتب AKS Azure Monitor ورؤى الحاوية من خلال منح فرق التطبيقات مكانا واحدا وجاهز للاستخدام للمراقبة اليومية عالية المستوى واستكشاف الأخطاء وإصلاحها لأحمال عمل التطبيقات الفردية الخاصة بهم، دون إنشاء أدوات مخصصة أو التبديل بين الأدوات.

من خلال Project سطح مكتب AKS، يمكنك:

  • عرض مقاييس مثل استهلاك المعالج والذاكرة لمكونات التطبيق.
  • تسجل كبسولة البث في الوقت الحقيقي للتصحيح.
  • تصور التبعيات بين أحمال العمل والخدمات باستخدام خريطة الموارد.

لقطة شاشة لنظرة عامة Project في سطح مكتب AKS تظهر مكونات التطبيق، والمقاييس، والصحة ل project.

لمزيد من المعلومات، راجع نظرة عامة على سطح مكتب AKS.

استعلامات Kusto

يمكنك تحليل بيانات المراقبة في مخزن Azure Monitor Logs / Log Analytics باستخدام لغة استعلام Kusto (KQL).

هام

عند تحديد Logs من قائمة الخدمة في المدخل، يفتح Log Analytics مع تعيين نطاق الاستعلام إلى الخدمة الحالية. يعني هذا النطاق أن استعلامات السجل ستتضمن بيانات من هذا النوع من الموارد فقط. إذا كنت ترغب في تشغيل استعلام يتضمن بيانات من خدمات Azure الأخرى، فحدد Logs من قائمة Azure Monitor . راجع نطاق الاستعلام عن السجل والزمن في Azure Monitor Log Analytics للحصول على التفاصيل.

للحصول على قائمة بالاستعلامات الشائعة لأي خدمة، راجع واجهة استعلامات Log Analytics.

التنبيهات

تقوم تنبيهات Azure Monitor بإعلامك بشكل استباقي عند العثور على شروط محددة في بيانات المراقبة الخاصة بك. تسمح لك التنبيهات بتحديد المشكلات ومعالجتها في النظام قبل أن يلاحظها عملاؤك. لمزيد من المعلومات، راجع تنبيهات Azure Monitor.

هناك العديد من مصادر التنبيهات الشائعة لموارد Azure. للحصول على أمثلة للتنبيهات الشائعة لموارد Azure، راجع نموذج استعلامات تنبيه السجل. يوفر موقع Azure Monitor Baseline Alerts (AMBA) طريقة شبه آلية لتنفيذ تنبيهات قياس النظام الأساسي الهامة ولوحات المعلومات والإرشادات. ينطبق الموقع على مجموعة فرعية موسعة باستمرار من خدمات Azure، بما في ذلك جميع الخدمات التي تعد جزءا من منطقة هبوط Azure (ALZ).

يوحد مخطط التنبيه الشائع استهلاك إعلامات تنبيه Azure Monitor. لمزيد من المعلومات، راجع مخطط التنبيه الشائع.

أنواع التنبيهات

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

تصف القائمة التالية أنواع تنبيهات Azure Monitor التي يمكنك إنشاؤها:

  • تقيم التنبيهات القياسية مقاييس الموارد على فترات منتظمة. يمكن أن تكون المقاييس مقاييس النظام الأساسي أو المقاييس المخصصة أو السجلات من Azure Monitor المحولة إلى مقاييس أو مقاييس Application Insights. يمكن أن تطبق التنبيهات القياسية أيضا شروطا متعددة وحدا ديناميكيا.
  • تسمح تنبيهات السجل للمستخدمين باستخدام استعلام Log Analytics لتقييم سجلات الموارد بتردد محدد مسبقا.
  • يتم تشغيل تنبيهات سجل النشاط عند حدوث حدث سجل نشاط جديد يطابق الشروط المحددة. تنبيهات صحة الموارد وتنبيهات حالة الخدمة هي تنبيهات سجل النشاط التي تبلغ عن الخدمة وصحة الموارد.

تدعم بعض خدمات Azure أيضا تنبيهات الكشف الذكية أو تنبيهات Prometheus أو قواعد التنبيه الموصى بها.

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

بالنسبة لبعض خدمات Azure، يمكنك تمكين قواعد التنبيه الجاهزة الموصى بها.

يجمع النظام قائمة بقواعد التنبيه الموصى بها بناءً على:

  • معرفة موفر المورد بالإشارات والحدود الهامة لمراقبة المورد.
  • البيانات التي توضح ما يقوم العملاء بالتنبيه عليه عادة لهذا المورد.

إشعار

تتوفر قواعد التنبيه الموصى بها ل:

  • الأجهزة الظاهرية
  • موارد خدمة Azure Kubernetes (AKS)
  • مساحات عمل Log Analytics

تكوين تنبيهات تعتمد على مقاييس بروميثيوس

متطلبات التنزيل والتكوين: قواعد التنبيه متاحة كقوالب ARM قابلة للتحميل أو ملفات بايسيب. قبل إعداد التنبيهات، تأكد من تفعيل الخدمة المدارة ل Prometheus على مجموعتك وأن مساحة عمل Azure Monitor مرتبطة بشكل صحيح بعنقود AKS الخاص بك.

عند تمكين مجموعة من الخدمة المدارة لمقاييس Prometheus لمجموعتك، يمكنك تنزيل مجموعة من الخدمة المدارة الموصى بها لقواعد تنبيه Prometheus.

يتضمن التنزيل القواعد التالية:

المستوى التنبيهات
مستوى نظام المجموعة KubeCPUQuotaOvercommit
KubeMemoryQuotaOvercommit
KubeContainerOOMKilledCount
KubeClientErrors
KubePersistentVolumeFillingUp
KubePersistentVolumeInodesFillingUp
KubePersistentVolumeErrors
KubeContainerWaiting
KubeDaemonSetNotScheduled
KubeDaemonSetMisScheduled
KubeQuotaAlmostFull
مستوى العقدة KubeNodeUnreachable
KubeNodeReadinessFlapping
مستوى الجراب KubePVUsageHigh
KubeDeploymentReplicasMismatch
KubeStatefulSetReplicasMismatch
KubeHpaReplicasMismatch
KubeHpaMaxedOut
KubePodCrashLooping
KubeJobStale
KubePodContainerRestart
KubePodReadyStateLow
KubePodFailedState
KubePodNotReadyByController
KubeStatefulSetGenerationMismatch
KubeJobFailed
KubeContainerAverageCPUHigh
KubeContainerAverageMemoryHigh
KubeletPodStartUpLatencyHigh

لمزيد من المعلومات، راجع إنشاء تنبيهات السجل من نتائج تحليلات الحاويةوسجلات الاستعلام من نتائج تحليلات الحاوية.

يمكن أن تقيس تنبيهات السجل نوعين من المعلومات لمساعدتك في مراقبة السيناريوهات المتنوعة:

  • عدد النتائج: حساب عدد الصفوف التي تم إرجاعها بواسطة الاستعلام. استخدم هذه المعلومات للعمل مع أحداث مثل سجلات أحداث Windows وأحداث syslog واستثناءات التطبيق.
  • حساب قيمة: إجراء عملية حسابية استنادا إلى عمود رقمي. استخدم هذه المعلومات لتضمين موارد متنوعة. مثال على ذلك هو النسبة المئوية لوحدة المعالجة المركزية.

معظم استعلامات السجل تقارن قيمة DateTime مع الوقت الحالي باستخدام المشغل now والعودة إلى الساعة السابقة. لمعرفة كيفية إنشاء تنبيهات تستند إلى السجل، راجع إنشاء تنبيهات السجل من نتائج تحليلات الحاوية.

قواعد تنبيه AKS

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

شرط ‏‏الوصف
النسبة المئوية >95 التنبيهات عندما يتجاوز متوسط استخدام وحدة المعالجة المركزية عبر جميع العقد الحد.
النسبة المئوية> لمجموعة عمل الذاكرة100 التنبيهات عندما يتجاوز متوسط مجموعة العمل عبر جميع العقد الحد.

توصيات Advisor

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

لمزيد من المعلومات حول Azure Advisor، راجع نظرة عامة على Azure Advisor.

إشعار

إذا كنت تقوم بإنشاء أو تشغيل تطبيق يعمل على الخدمة الخاصة بك، فقد توفر رؤى تطبيق Azure Monitor المزيد من أنواع التنبيهات.

مراقبة مقاييس شبكة عقد AKS

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

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

يتم تمكين مقاييس شبكة العقدة التالية افتراضيا ويتم تجميعها لكل عقدة. تتضمن جميع المقاييس نظام مجموعة التسميات والمثيل (اسم العقدة). يمكنك بسهولة عرض هذه المقاييس باستخدام لوحة تحكم Grafana المدارة تحتعناقيد>>>.

مقاييس شبكة عقدة AKS حسب نوع مستوى البيانات

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

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

دعم وقيود نظام التشغيل: بالنسبة لسيناريوهات مستوى بيانات Cilium، توفر ميزة مراقبة شبكة الحاويات مقاييس فقط لتجمعات عقد لينكس. حاليا، Windows غير مدعوم لمقاييس مراقبة شبكة الحاوية. تأكد من أن مجموعة العقد لديك تحتوي على تجمعات عقد لينكس لتوفر مقاييس Cilium الكاملة.

يعرض Cilium العديد من المقاييس التي تستخدمها مراقبة شبكة الحاوية:

اسم قياسي ‏‏الوصف تسميات إضافية Linux بالنسبة لنظام التشغيل
cilium_forward_count_total إجمالي عدد الحزم التي تمت إعادة توجيهها direction مدعم ✅ معتمد ❌
cilium_forward_bytes_total إجمالي عدد البايت الذي تمت إعادة توجيهه direction مدعم ✅ معتمد ❌
cilium_drop_count_total إجمالي عدد الحزم التي تم إسقاطها direction، reason مدعم ✅ معتمد ❌
cilium_drop_bytes_total إجمالي عدد البايت المسقط direction، reason مدعم ✅ معتمد ❌

تعطيل مجموعة مقاييس شبكة عقد AKS

يمكنك تعطيل مجموعة مقاييس الشبكة على عقد معينة عن طريق إضافة التسمية networking.azure.com/node-network-metrics=disabled إلى تلك العقد.

إشعار

الشبكية لديها operator: "Exists"effect: NoSchedule تسامح، لذا تتجاوز NoSchedule التلوث. لذلك، يتم استخدام التسميات بدلا من البقع للتحكم في الجدولة.

إذا كانت المجموعة عقدا autoprovisioning/autoscaling ، تحتاج إلى تفعيل العلم يدويا على كل عقدة.

هام

هذه الميزة غير قابلة للتطبيق إذا كانت خدمات شبكات الحاويات المتقدمة (ACNS) مفعلة على عنقودك.

لإيقاف جمع المقاييس على عقدة:

kubectl label node <node-name> networking.azure.com/node-network-metrics=disabled

للحصول على مقاييس مفصلة على مستوى الجراب وDNS، راجع خدمات شبكات الحاويات المتقدمة.

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

  • Last updated on