استكشاف أخطاء نتائج تحليلات الحاوية وإصلاحها

  • مقالة

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

رسائل الخطأ الشائعة

يلخص الجدول التالي الأخطاء المعروفة التي قد تواجهها عند استخدام نتائج تحليلات الحاوية.

رسائل خطأ الإجراء
رسالة الخطأ "لا توجد بيانات لعوامل التصفية المحددة" وقد يستغرق الأمر بعض الوقت لإنشاء تدفق بيانات المراقبة للمجموعات المنشأة حديثًا. انتظر 10 إلى 15 دقيقة على الأقل حتى تظهر البيانات لنظام المجموعة لديك.

إذا لم تظهر البيانات مع ذلك، فتحقق مما إذا تم تكوين مساحة عمل Log Analytics ل disableLocalAuth = true. إذا كانت الإجابة بنعم، فقم بتحديث مرة أخرى إلى disableLocalAuth = false.

az resource show --ids "/subscriptions/[Your subscription ID]/resourcegroups/[Your resource group]/providers/microsoft.operationalinsights/workspaces/[Your workspace name]"

az resource update --ids "/subscriptions/[Your subscription ID]/resourcegroups/[Your resource group]/providers/microsoft.operationalinsights/workspaces/[Your workspace name]" --api-version "2021-06-01" --set properties.features.disableLocalAuth=False
رسالة الخطأ "خطأ في استرداد البيانات" أثناء إعداد مجموعة AKS لمراقبة الصحة والأداء، يتم إنشاء اتصال بين نظام المجموعة ومساحة عمل Log Analytics. تُستخدم مساحة عمل Log Analytics لتخزين جميع بيانات المراقبة الخاصة بنظام المجموعة لديك. قد يحدث هذا الخطأ عند حذف مساحة عمل Log Analytics. تحقق مما إذا تم حذف مساحة العمل. إذا كان الأمر كذلك، يمكن إعادة تمكين مراقبة نظام المجموعة الخاص بك باستخدام نتائج تحليلات الحاوية. ثم حدد مساحة عمل موجودة أو أنشئ مساحة عمل جديدة. لإعادة التمكين، قم بتعطيل المراقبة لنظام المجموعة وتمكين نتائج تحليلات الحاوية مرة أخرى.
"خطأ في استرداد البيانات" بعد إضافة نتائج تحليلات الحاوية من خلال az aks cli عند تمكين المراقبة باستخدام az aks cli، قد لا يتم نشر نتائج تحليلات الحاوية بشكل صحيح. تحقق ما إذا كان يتم نشر الحل. للتحقق، انتقل إلى مساحة عمل Log Analytics الخاصة بك وتحقق مما إذا كان الحل متوفرا عن طريق تحديد الحلول القديمة من الجزء على الجانب الأيسر. لحل هذه المشكلة، أعد نشر الحل. اتبع الإرشادات الموجودة في تمكين نتائج تحليلات الحاوية.
رسالة الخطأ "تسجيل الاشتراك مفقود" إذا تلقيت الخطأ "تسجيل الاشتراك مفقود ل Microsoft.OperationsManagement"، يمكنك حله عن طريق تسجيل موفر الموارد Microsoft.OperationsManagement في الاشتراك حيث يتم تعريف مساحة العمل. للحصول على الخطوات، راجع حل الأخطاء لتسجيل موفر الموارد.
رسالة الخطأ "عنوان URL للرد المحدد في الطلب لا يتطابق مع عناوين URL للرد المكونة للتطبيق: "<معرف> التطبيق". قد ترى رسالة الخطأ هذه عند تمكين السجلات المباشرة. للحصول على الحل، راجع عرض بيانات الحاوية في الوقت الفعلي باستخدام نتائج تحليلات الحاوية.

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

خطأ في التخويل في أثناء عملية الإعداد أو التحديث

عند تمكين نتائج تحليلات الحاوية أو تحديث نظام مجموعة لدعم تجميع المقاييس، قد تتلقى خطأ مثل "العميل <user's Identity> الذي لديه معرف <user's objectId> الكائن ليس لديه تخويل لتنفيذ إجراء Microsoft.Authorization/roleAssignments/write عبر النطاق."

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

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

تم تمكين نتائج تحليلات الحاوية ولكن لا يتم الإبلاغ عن أي معلومات

لتشخيص المشكلة إذا تعذر عليك عرض معلومات الحالة أو لم يتم إرجاع أي نتائج من استعلام سجل:

  1. تحقق من حالة العامل عن طريق تشغيل الأمر التالي:

    kubectl get ds ama-logs --namespace=kube-system

    يجب أن يكون عدد pods مساويا لعدد عقد Linux على نظام المجموعة. يجب أن يكون الإخراج مشابهًا للمثال التالي، ما يشير إلى أنه تم نشره بشكل صحيح:

    User@aksuser:~$ kubectl get ds ama-logs --namespace=kube-system
NAME       DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR    AGE
ama-logs   2         2         2         2            2           <none>           1d

  2. إذا كان لديك عقد Windows Server، فتحقق من حالة العامل عن طريق تشغيل الأمر التالي:

    kubectl get ds ama-logs-windows --namespace=kube-system

    يجب أن يكون عدد pods مساويا لعدد عقد Windows على نظام المجموعة. يجب أن يكون الإخراج مشابهًا للمثال التالي، ما يشير إلى أنه تم نشره بشكل صحيح:

    User@aksuser:~$ kubectl get ds ama-logs-windows --namespace=kube-system
NAME                   DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR    AGE
ama-logs-windows           2         2         2         2            2           <none>       1d

  3. تحقق من حالة النشر باستخدام الأمر التالي:

    kubectl get deployment ama-logs-rs --namespace=kube-system

    يجب أن يكون الإخراج مشابهًا للمثال التالي، ما يشير إلى أنه تم نشره بشكل صحيح:

    User@aksuser:~$ kubectl get deployment ama-logs-rs --namespace=kube-system
NAME          READY   UP-TO-DATE   AVAILABLE   AGE
ama-logs-rs   1/1     1            1           24d

  4. تحقق من حالة الجراب للتحقق من أنه قيد التشغيل باستخدام الأمر kubectl get pods --namespace=kube-system.

    يجب أن يشبه الإخراج المثال التالي بحالة Running ل ama-logs:

    User@aksuser:~$ kubectl get pods --namespace=kube-system
NAME                                READY     STATUS    RESTARTS   AGE
aks-ssh-139866255-5n7k5             1/1       Running   0          8d
azure-vote-back-4149398501-7skz0    1/1       Running   0          22d
azure-vote-front-3826909965-30n62   1/1       Running   0          22d
ama-logs-484hw                      1/1       Running   0          1d
ama-logs-fkq7g                      1/1       Running   0          1d
ama-logs-windows-6drwq              1/1       Running   0          1d

  5. إذا كانت القرون في حالة تشغيل، ولكن لا توجد بيانات في Log Analytics أو يبدو أن البيانات ترسل فقط خلال جزء معين من اليوم، فقد يكون ذلك مؤشرا على أنه تم استيفاء الحد الأقصى اليومي. عند استيفاء هذا الحد كل يوم، تتوقف البيانات عن استيعابها في مساحة عمل Log Analytics وتعيد التعيين في وقت إعادة الضبط. لمزيد من المعلومات، راجع Log Analytics Daily Cap.

لم تتم جدولة ReplicaSet Pods لعامل نتائج تحليلات الحاوية على نظام مجموعة غير AKS

تعتمد ReplicaSet Pods لعامل نتائج تحليلات الحاوية على محددات العقد التالية على عقد العامل (أو العامل) للجدولة:

nodeSelector:
  beta.kubernetes.io/os: Linux
  kubernetes.io/role: agent

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

لا تعرض مخططات الأداء وحدة المعالجة المركزية أو ذاكرة العقد والحاويات الموجودة على نظام مجموعة غير تابع لـ Azure

تستخدم حاويات عامل نتائج تحليلات الحاوية نقطة نهاية cAdvisor على عامل العقدة لجمع مقاييس الأداء. تحقق من تكوين العامل الحاوي على العقدة للسماح cAdvisor secure port: 10250 أو cAdvisor unsecure port: 10255 ليتم فتحه على جميع العقد في نظام المجموعة لجمع مقاييس الأداء. راجع المتطلبات الأساسية لمجموعات Kubernetes المختلطة لمزيد من المعلومات.

لا تظهر أنظمة المجموعات غير التابعة ل AKS في نتائج تحليلات الحاوية

لعرض نظام المجموعة غير AKS في نتائج تحليلات الحاوية، يلزم الوصول للقراءة على مساحة عمل Log Analytics التي تدعم هذه الرؤى وعلى مورد Container insights solution ContainerInsights (مساحة العمل).

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

  1. تحقق من وجود تعيين دور Monitoring Metrics Publisher باستخدام أمر CLI التالي:

    az role assignment list --assignee "SP/UserassignedMSI for Azure Monitor Agent" --scope "/subscriptions/<subid>/resourcegroups/<RG>/providers/Microsoft.ContainerService/managedClusters/<clustername>" --role "Monitoring Metrics Publisher"

    بالنسبة للمجموعات التي تحتوي على MSI، يتغير معرف العميل المعين من قبل المستخدم لعامل Azure Monitor في كل مرة يتم فيها تمكين المراقبة وتعطيلها، لذلك يجب أن يكون تعيين الدور موجودا على معرف عميل MSI الحالي.

  2. بالنسبة للمجموعات التي تم تمكين هوية Microsoft Entra pod واستخدام MSI:

    • تحقق من أن التسمية المطلوبة kubernetes.azure.com/managedby: aks موجودة على جرابات عامل Azure Monitor باستخدام الأمر التالي:

      kubectl get pods --show-labels -n kube-system | grep ama-logs

    • تحقق من تمكين الاستثناءات عند تمكين هوية الجراب باستخدام إحدى الطرق المدعومة في https://github.com/Azure/aad-pod-identity#1-deploy-aad-pod-identity.

      قم بتشغيل الأمر التالي للتحقق من:

      kubectl get AzurePodIdentityException -A -o yaml

      يجب أن تتلقى إخراجا مشابها للمثال التالي:

      apiVersion: "aadpodidentity.k8s.io/v1"
kind: AzurePodIdentityException
metadata:
name: mic-exception
namespace: default
spec:
podLabels:
app: mic
component: mic
---
apiVersion: "aadpodidentity.k8s.io/v1"
kind: AzurePodIdentityException
metadata:
name: aks-addon-exception
namespace: kube-system
spec:
podLabels:
kubernetes.azure.com/managedby: aks

فشل تثبيت ملحق حاويات Azure Monitor على مجموعة Kubernetes الممكنة في Azure Arc

يشير الخطأ "البيانات تحتوي على مورد موجود بالفعل" إلى أن موارد عامل نتائج تحليلات الحاوية موجودة بالفعل على مجموعة Kubernetes الممكنة في Azure Arc. يشير هذا الخطأ إلى أن عامل نتائج تحليلات الحاوية مثبت بالفعل. يتم تثبيته إما من خلال مخطط Helm azuremonitor-containers أو الوظيفة الإضافية للمراقبة إذا كانت مجموعة AKS متصلة عبر Azure Arc.

الحل لهذه المشكلة هو تنظيف الموارد الموجودة من عامل نتائج تحليلات الحاوية إذا كان موجودا. ثم قم بتمكين ملحق حاويات Azure Monitor.

بالنسبة إلى نظم المجموعات غير التابع لـ AKS

  1. مقابل مجموعة K8s المتصلة ب Azure Arc، قم بتشغيل الأمر التالي للتحقق مما إذا كان azmon-containers-release-1 إصدار مخطط Helm موجودا أم لا:

    helm list -A

  2. إذا كان إخراج الأمر السابق يشير إلى وجود azmon-containers-release-1 ، فاحذف إصدار مخطط Helm:

    helm del azmon-containers-release-1

بالنسبة إلى نظم لمجموعات AKS

  1. قم بتشغيل الأوامر التالية وابحث عن ملف تعريف الوظيفة الإضافية لعامل مراقبة Azure للتحقق مما إذا كان قد تم تمكين الوظيفة الإضافية لمراقبة AKS:

    az  account set -s <clusterSubscriptionId>
az aks show -g <clusterResourceGroup> -n <clusterName>

  2. إذا كان الإخراج يتضمن تكوين ملف تعريف الوظيفة الإضافية لعامل مراقبة Azure مع معرف مورد مساحة عمل Log Analytics، تشير هذه المعلومات إلى تمكين الوظيفة الإضافية لمراقبة AKS ويجب تعطيلها:

    az aks disable-addons -a monitoring -g <clusterResourceGroup> -n <clusterName>

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

التنبيهات المكررة التي يتم تلقيها

ربما قمت بتمكين قواعد تنبيه Prometheus دون تعطيل التنبيهات الموصى بها ل Container insights. راجع الترحيل من تنبيهات Container insights الموصى بها إلى قواعد التنبيه الموصى بها Prometheus (معاينة).

أرى شعار المعلومات "ليس لديك أذونات نظام المجموعة الصحيحة التي ستقيد وصولك إلى ميزات Container Insights. يرجى التواصل مع مسؤول نظام المجموعة للحصول على الإذن الصحيح"

سمحت Container Insights للمستخدمين تاريخيا بالوصول إلى تجربة مدخل Azure استنادا إلى إذن الوصول لمساحة عمل Log Analytics. يتحقق الآن من الإذن على مستوى نظام المجموعة لتوفير الوصول إلى تجربة مدخل Azure. قد تحتاج إلى مسؤول نظام المجموعة لتعيين هذا الإذن.

للوصول الأساسي على مستوى نظام المجموعة للقراءة فقط، قم بتعيين دور قارئ المراقبة للأنوع التالية من المجموعات.

  • تمكين تخويل التحكم في الوصول المستند إلى الدور (RBAC) من AKS دون Kubernetes
  • تمكين AKS باستخدام تسجيل الدخول الأحادي المستند إلى Microsoft Entra SAML
  • تمكين AKS مع تخويل من التحكم في الوصول استناداً إلى الدور لدى Kubernetes
  • تكوين AKS مع ربط دور نظام مجموعة clusterMonitoringUser
  • مجموعات Kubernetes الممكنة في Azure Arc

راجع تعيين أذونات الدور لمستخدم أو مجموعة للحصول على تفاصيل حول كيفية تعيين هذه الأدوار ل AKS وخيارات الوصول والهوية لخدمة Azure Kubernetes (AKS) لمعرفة المزيد حول تعيينات الأدوار.

لا أرى قيم خصائص الصورة والاسم مملوءة عند الاستعلام عن جدول ContainerLog

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

خيار 1

الانضمام إلى جداول أخرى لتضمين قيم الخاصية هذه في النتائج.

قم بتعديل الاستعلامات لتضمين Image وخصائص ImageTag من ContainerInventory الجدول عن طريق الانضمام إلى الخاصية ContainerID . يمكنك تضمين الخاصية Name (كما ظهرت سابقا في ContainerLog الجدول) من KubepodInventory حقل الجدول ContainerName عن طريق الانضمام إلى الخاصية ContainerID . ننصح بهذا الخيار.

المثال التالي هو عينة استعلام مفصل يشرح كيفية الحصول على قيم الحقول هذه مع الصلات.

//Let's say we're querying an hour's worth of logs
let startTime = ago(1h);
let endTime = now();
//Below gets the latest Image & ImageTag for every containerID, during the time window
let ContainerInv = ContainerInventory | where TimeGenerated >= startTime and TimeGenerated < endTime | summarize arg_max(TimeGenerated, *)  by ContainerID, Image, ImageTag | project-away TimeGenerated | project ContainerID1=ContainerID, Image1=Image ,ImageTag1=ImageTag;
//Below gets the latest Name for every containerID, during the time window
let KubePodInv  = KubePodInventory | where ContainerID != "" | where TimeGenerated >= startTime | where TimeGenerated < endTime | summarize arg_max(TimeGenerated, *)  by ContainerID2 = ContainerID, Name1=ContainerName | project ContainerID2 , Name1;
//Now join the above 2 to get a 'jointed table' that has name, image & imagetag. Outer left is safer in case there are no kubepod records or if they're latent
let ContainerData = ContainerInv | join kind=leftouter (KubePodInv) on $left.ContainerID1 == $right.ContainerID2;
//Now join ContainerLog table with the 'jointed table' above and project-away redundant fields/columns and rename columns that were rewritten
//Outer left is safer so you don't lose logs even if we can't find container metadata for loglines (due to latency, time skew between data types, etc.)
ContainerLog
| where TimeGenerated >= startTime and TimeGenerated < endTime
| join kind= leftouter (
  ContainerData
) on $left.ContainerID == $right.ContainerID2 | project-away ContainerID1, ContainerID2, Name, Image, ImageTag | project-rename Name = Name1, Image=Image1, ImageTag=ImageTag1

خيار 2

مجموعة قابلة لإعادةenable لهذه الخصائص لكل سطر سجل حاوية.

إذا لم يكن الخيار الأول مناسبا بسبب تغييرات الاستعلام المتضمنة، يمكنك إعادة تمكين تجميع هذه الحقول. تمكين الإعداد log_collection_settings.enrich_container_logs في خريطة تكوين العامل كما هو موضح في إعدادات تكوين تجميع البيانات.

إشعار

لا نوصي بالخيار الثاني للمجموعات الكبيرة التي تحتوي على أكثر من 50 عقدة. يقوم بإنشاء استدعاءات خادم API من كل عقدة في نظام المجموعة لإجراء هذا الإثراء. كما أن هذا الخيار يزيد حجم البيانات لكل سطر سجل تم تجميعه.

لا يمكنني ترقية نظام مجموعة بعد الإلحاق

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

عدم تجميع السجلات على نظام مجموعة Azure Stack HCI

إذا قمت بتسجيل نظام المجموعة و/أو تكوين HCI Insights قبل نوفمبر 2023، فقد لا تجمع الميزات التي تستخدم عامل Azure Monitor على HCI، مثل Arc for Servers Insights أو VM Insights أو Container Insights أو Defender for Cloud أو Microsoft Sentinel السجلات وبيانات الأحداث بشكل صحيح. راجع إصلاح عامل AMA ل HCI للحصول على خطوات لإعادة تكوين العامل وHCI Insights.

الخطوات التالية

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