مشاركة عبر

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

  • مقالة

ينطبق على:ملحق ML Azure CLI v2 (الحالي)Python SDK azure-ai-ml v2 (الحالي)

تعرف على كيفية حل المشكلات الشائعة في النشر والتسجيل في نقاط النهاية بـ Azure Machine Learning.

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

  1. استخدم النشر المحلي لاختبار نماذجك وتتبع أخطائها محليًا قبل نشرها على السحابة.
  2. استخدم سجلات الحاوية لتصحيح المشكلات.
  3. أفهم أخطاء النشر الشائعة التي قد تنشأ وكيفية إصلاحها.

يوضح القسم التعليمات البرمجية لحالة HTTP كيفية تعيين أخطاء الاستدعاء والتنبؤ إلى التعليمات البرمجية لحالة HTTP عند تسجيل نقاط النهاية بطلبات REST.

المتطلبات الأساسية

النشر المحلي

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

تلميح

يمكنك أيضا استخدام حزمة Python لخادم Azure التعلم الآلي الاستدلال HTTP لتصحيح أخطاء البرنامج النصي لتسجيل النقاط محليا. يساعدك تصحيح الأخطاء باستخدام خادم الاستدلال على تصحيح أخطاء البرنامج النصي لتسجيل النقاط قبل النشر إلى نقاط النهاية المحلية بحيث يمكنك تصحيح الأخطاء دون التأثر بتكوينات حاوية التوزيع.

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

لاستخدام النشر المحلي، قم بإضافة --local إلى أمر CLI المناسب:

az ml online-deployment create --endpoint-name <endpoint-name> -n <deployment-name> -f <spec_file.yaml> --local

وضمن النشر المحلي، يتم اتباع الخطوات التالية:

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

للحصول على المزيد، راجع التوزيع محليا في نشر نموذج التعلم الآلي وتسجيله.

تلميح

استخدم Visual Studio Code لاختبار نقاط النهاية وتصحيحها محليًا. لمزيدٍ من المعلومات، راجع تتبع أخطاء نقاط النهاية عبر الإنترنت محلياً في Visual Studio Code.

تثبيت Conda

بشكل عام، تنشأ المشكلات المتعلقة بنشر MLflow من المشكلات المتعلقة بتثبيت بيئة المستخدم المحددة في conda.yaml الملف.

لتصحيح مشكلات تثبيت conda، جرب الخطوات التالية:

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

  2. قم بتثبيت ملف mlflow conda محليًا باستخدام الأمر conda env create -n userenv -f <CONDA_ENV_FILENAME>.

  3. إذا وجدت أخطاء محليًا، فحاول إصلاح بيئة conda وإنشاء بيئة وظيفية قبل إعادة النشر.

  4. إذا تعطل الحاوية حتى إذا تم حلها محليا، فقد يكون حجم SKU المستخدم للنشر صغيرا جدا.

    1. يحدث تثبيت حزمة Conda في وقت التشغيل، لذلك إذا كان حجم SKU صغيرا جدا لاستيعاب جميع الحزم المفصلة conda.yaml في ملف البيئة، فقد تتعطل الحاوية.
    2. الجهاز الظاهري Standard_F4s_v2 هو حجم SKU بداية جيد، ولكن قد تكون هناك حاجة إلى أجهزة أكبر اعتمادا على التبعيات المحددة في ملف conda.
    3. بالنسبة لنقطة نهاية Kubernetes عبر الإنترنت، يجب أن تحتوي مجموعة Kubernetes على 4 ذاكرات أساسية لوحدة المعالجة المركزية الظاهرية كحد أدنى وذاكرة 8 غيغابايت.

الحصول على سجلات الحاوية

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

هناك نوعان من الحاويات التي يمكنك الحصول على السجلات منها:

  • خادم الاستدلال: تتضمن السجلات سجل وحدة التحكم (من خادم الاستدلال) الذي يحتوي على إخراج وظائف الطباعة/التسجيل من البرنامج النصي لتسجيل النقاط (score.py التعليمات البرمجية).
  • تهيئة التخزين: تحتوي السجلات على معلومات حول ما إذا كان قد تم تنزيل التعليمات البرمجية وبيانات النموذج بنجاح إلى الحاوية. يتم تشغيل الحاوية قبل بدء تشغيل حاوية خادم الاستدلال.

لمشاهدة إخراج السجل من حاوية، استخدم أمر CLI التالي:

az ml online-deployment get-logs -e <endpoint-name> -n <deployment-name> -l 100

أو

az ml online-deployment get-logs --endpoint-name <endpoint-name> --name <deployment-name> --lines 100

أضف --resource-group وإلى --workspace-name هذه الأوامر إذا لم تقم بالفعل بتعيين هذه المعلمات عبر az configure.

للاطلاع على معلومات حول كيفية تعيين هذه المعلمات، وإذا قمت حاليا بتعيين القيم، فقم بتشغيل:

az ml online-deployment get-logs -h

يتم سحب السجلات بشكل افتراضي من خادم الاستنتاج.

إشعار

إذا كنت تستخدم تسجيل Python، فتأكد من استخدام الترتيب الصحيح لمستوى التسجيل في الرسائل التي سيتم نشرها في السجلات. على سبيل المثال، INFO.

يمكنك أيضًا الحصول على السجلات من حاوية مُهيئ التخزين عن طريق تمرير –-container storage-initializer.

أضف --help و/أو --debug إلى الأوامر للاطلاع على مزيدٍ من المعلومات.

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

kubectl -n <compute-namespace> logs <container-name>

تتبع الطلب

هناك عنوانان للتتبع مدعومان:

  • x-request-id محجوز لتتبع الخادم. نمنع هذا العنوان للتأكد من أنه GUID صالح.

    إشعار

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

  • x-ms-client-request-id متاحة لسيناريوهات تتبع العميل. يتم تعقيم هذا العنوان لقبول الأحرف الأبجدية الرقمية والواصلات والتسطير السفلي فقط، ويتم اقتطاعه إلى 40 حرفا كحد أقصى.

أخطاء التوزيع الشائعة

القائمة التالية هي أخطاء التوزيع الشائعة التي يتم الإبلاغ عنها كجزء من حالة عملية التوزيع:

إذا كنت تقوم بإنشاء أو تحديث نشر Kubernetes عبر الإنترنت، يمكنك مشاهدة الأخطاء الشائعة الخاصة بنشر Kubernetes.

«خطأ»: ImageBuildFailure

يتم إرجاع ذلك الخطأ عند إنشاء البيئة (صورة docker). يمكنك التحقق من سجل البناء للحصول على مزيد من المعلومات حول الفشل (حالات الفشل). يقع سجل البناء في التخزين الافتراضي لمساحة عمل Azure Machine Learning. قد يتم إرجاع الموقع الدقيق كجزء من الخطأ. على سبيل المثال، "the build log under the storage account '[storage-account-name]' in the container '[container-name]' at the path '[path-to-the-log]'"

تحتوي القائمة التالية على سيناريوهات فشل بناء الصور الشائعة:

نوصي أيضا بمراجعة إعدادات الفحص الافتراضية إذا كان لديك مهلات ImageBuild.

فشل تخويل سجل الحاوية

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

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

لم يتم تعيين حساب بناء الصورة في مساحة عمل خاصة باستخدام VNet

إذا كانت رسالة الخطأ تشير إلى "failed to communicate with the workspace's container registry" وكنت تستخدم الشبكات الظاهرية وكان Azure Container Registry الخاص بمساحة العمل وتكوينه بنقطة نهاية خاصة، فأنت بحاجة إلى تمكين Azure Container Registry للسماح بإنشاء الصور في الشبكة الظاهرية.

فشل إنشاء صورة عامة

كما ذكر سابقا، يمكنك التحقق من سجل البناء لمزيد من المعلومات حول الفشل. إذا لم يتم العثور على خطأ واضح في سجل البناء وكان السطر الأخير هو Installing pip dependencies: ...working...، فقد تتسبب التبعية في حدوث الخطأ. يمكن أن يؤدي تثبيت تبعيات الإصدار في ملف conda إلى إصلاح هذه المشكلة.

نوصي أيضا بالنشر محليا لاختبار نماذجك وتصحيحها محليا قبل النشر إلى السحابة.

«خطأ»: OutOfQuota

القائمة التالية هي من الموارد الشائعة التي قد تنفد الحصة النسبية عند استخدام خدمات Azure:

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

الحصة النسبية لـ CPU

قبل نشر النموذج، تحتاج إلى حصة حساب كافية. تُحدّد هذه الحصة مقدار الذاكرات الأساسية الظاهرية المتوفرة لكل اشتراك، ولكل مساحة عمل، ولكل SKU، ولكل منطقة. يطرح كل نشر من قيمة الحصة النسبية المتوفرة ويضيفها مرة أخرى بعد الحذف، استنادًا إلى نوع الـ SKU.

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

الحصة النسبية لنظام المجموعة

تحدث هذه المشكلة عندما لا يكون لديك ما يكفي من حصة نظام مجموعة Azure التعلم الآلي الحساب. تحدد هذه الحصة إجمالي عدد المجموعات التي قد تكون قيد الاستخدام في وقت واحد لكل اشتراك لنشر عقد وحدة المعالجة المركزية أو GPU في Azure Cloud.

يتمثل التخفيف المحتمل في التحقق مما إذا كانت هناك عمليات نشر غير مستخدمة يمكنك حذفها. أو يمكنك إرسال طلب لزيادة الحصة النسبية. تأكد من تحديد Machine Learning Service: Cluster Quota كنوع الحصة النسبية لطلب زيادة الحصة النسبية هذا.

الحصة النسبية للقرص

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

الحصة النسبية للذاكرة

تحدث هذه المشكلة عندما تكون بصمة الذاكرة في النموذج أكبر من الذاكرة المتوفرة. جرب SKU بمزيد من الذاكرة.

حصة تعيين الدور

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

حصة نقطة النهاية

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

حصة Kubernetes

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

تشير رسالة الخطأ عادة إلى أن المورد غير كاف في نظام المجموعة، على سبيل المثال، OutOfQuota: Kubernetes unschedulable. Details:0/1 nodes are available: 1 Too many pods...، ما يعني أن هناك عددا كبيرا جدا من القرون في نظام المجموعة وليس هناك موارد كافية لنشر النموذج الجديد بناء على طلبك.

يمكنك تجربة التخفيف التالي لمعالجة هذه المشكلة:

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

سعة الجهاز الظاهري على مستوى المنطقة

بسبب نقص سعة Azure التعلم الآلي في المنطقة، فشلت الخدمة في توفير حجم الجهاز الظاهري المحدد. أعد المحاولة لاحقًا أو حاول القيام بالنشر في منطقة مختلفة.

حصة أخرى

لتشغيل score.py المقدم ضمن النشر، ينشئ Azure حاوية تتضمن جميع الموارد التي يحتاجها score.py، ويشغل البرنامج النصي لتسجيل النقاط في تلك الحاوية.

إذا تعذر بدء تشغيل الحاوية، فهذا يعني أنه لا يمكن تسجيل النقاط. قد تطلب الحاوية موارد أكثر مما instance_type يمكن أن تدعمه. إذا كان الأمر كذلك، ففكّر في تحديث instance_type للنشر عبر الإنترنت.

لمعرفة السبب المحدّد للخطأ، قم بتشغيل:

az ml online-deployment get-logs -e <endpoint-name> -n <deployment-name> -l 100

«خطأ»: BadArgument

القائمة التالية هي أسباب قد تواجه هذا الخطأ عند استخدام نقطة نهاية مدارة عبر الإنترنت أو نقطة نهاية Kubernetes عبر الإنترنت:

القائمة التالية هي أسباب قد تواجه هذا الخطأ فقط عند استخدام نقطة نهاية Kubernetes عبر الإنترنت:

الاشتراك غير موجود

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

لمزيد من المعلومات حول اشتراكات Azure، يمكنك مشاهدة قسم المتطلبات الأساسية.

أخطاء التخويل

بعد توفير مورد الحساب (أثناء إنشاء عملية نشر)، يحاول Azure سحب صورة حاوية المستخدم من مساحة العمل Azure Container Registry (ACR). يحاول تحميل نموذج المستخدم والبيانات الاصطناعية للتعليمات البرمجية في حاوية المستخدم من حساب تخزين مساحة العمل.

لتنفيذ هذه الإجراءات، يستخدم Azure الهويات المدارة للوصول إلى حساب التخزين وسجل الحاوية.

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

  • إذا قمت بإنشاء نقطة النهاية المقترنة بهوية المستخدم المعينة، يجب أن يكون لدى الهوية المدارة للمستخدم إذن قارئ بيانات كائن ثنائي كبير الحجم للتخزين على حساب التخزين لمساحة العمل، وإذن AcrPull على سجل حاويات Azure (ACR) لمساحة العمل. تأكد من أن الهوية المعينة من قبل المستخدم لديك لديها الإذن الصحيح.

لمزيد من المعلومات، يرجى الاطلاع على خطأ تخويل سجل الحاوية.

مواصفات دالة القالب غير صحيحة

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

تعذّر تنزيل صورة حاوية المستخدم

من المحتمل أنه تعذر العثور على حاوية المستخدم. تحقق من سجلات الحاوية لمعرفة المزيد من التفاصيل.

تأكد من توافر صورة الحاوية في مساحة العمل ACR.

على سبيل المثال، إذا كانت الصورة testacr.azurecr.io/azureml/azureml_92a029f831ce58d2ed011c3c42d35acb:latest تتحقق من المستودع باستخدام az acr repository show-tags -n testacr --repository azureml/azureml_92a029f831ce58d2ed011c3c42d35acb --orderby time_desc --output table.

تعذر تنزيل نموذج المستخدم

من الممكن عدم العثور على نموذج المستخدم. تحقق من سجلات الحاوية لمعرفة المزيد من التفاصيل.

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

az ml model show --name <model-name> --version <version>

تحذير

يجب تحديد إما الإصدار أو التسمية للحصول على معلومات النموذج.

يمكنك أيضًا التحقق مما إذا كانت blobs موجودة في حساب تخزين مساحة العمل.

  • على سبيل المثال، إذا كان الـ blobs هو https://foobar.blob.core.windows.net/210212154504-1517266419/WebUpload/210212154504-1517266419/GaussianNB.pkl، يمكنك استخدام هذا الأمر للتحقق مما إذا كان موجودًا:

    az storage blob exists --account-name foobar --container-name 210212154504-1517266419 --name WebUpload/210212154504-1517266419/GaussianNB.pkl --subscription <sub-name>`

  • إذا كان الكائن الثنائي كبير الحجم موجودًا، يمكنك استخدام هذا الأمر للحصول على السجلات من مُهيئ التخزين:

    az ml online-deployment get-logs --endpoint-name <endpoint-name> --name <deployment-name> –-container storage-initializer`

تنسيق نموذج MLFlow مع شبكة خاصة غير مدعوم

يحدث هذا الخطأ عند محاولة نشر نموذج MLflow مع نهج نشر بدون تعليمات برمجية بالتزامن مع أسلوب عزل الشبكة القديم لنقاط النهاية المدارة عبر الإنترنت. لا يمكن استخدام ميزة الشبكة الخاصة هذه بالاقتران مع تنسيق نموذج MLFlow إذا كنت تستخدم أسلوب عزل الشبكة القديمة . إذا كنت بحاجة إلى نشر نموذج MLflow باستخدام نهج نشر بدون تعليمات برمجية، فحاول استخدام VNet المدارة لمساحة العمل.

طلب المورد أكثر من الحدود

يجب أن تقل عدد طلبات الموارد من الحدود أو تساويها. إذا لم تقم بتعيين الحدود، فإننا نضبط القيم الافتراضية عند إرفاق الحوسبة بمساحة عمل «التعليم الآلي» من Azure. يمكنك التحقق من الحدود في مدخل Azure أو باستخدام الأمر az ml compute show.

azureml-fe غيـر جاهز

يتوسع مكون الواجهة الأمامية (azureml-fe) الذي يوجه طلبات الاستدلال الواردة إلى الخدمات المنشورة تلقائياً حسب الحاجة. يتم تثبيته أثناء تثبيت مُلحق k8s.

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

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

«خطأ»: ResourceNotReady

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

  • يوجد خطأ في score.py. يستخدم get-logs لتشخيص المشاكل الشائعة:
    • لا يتم تضمين الحزمة التي score.py تحاول الاستيراد في بيئة conda.
    • خطأ في بناء الجملة.
    • فشل في الأسلوب init().
  • إذا لم ينتج get-logs أي سجلات، فذلك يعني عادةً أن الحاوية قد فشلت في بدء تشغيلها. لتصحيح هذه المشكلة، حاول النشر محليًا بدلا من ذلك.
  • لم تُعد فحوصات الجاهزية أو الحياة بشكل صحيح.
  • تستغرق تهيئة الحاوية وقتا طويلا بحيث يفشل فحص الجاهزية أو الحياة بما يتجاوز حد الفشل. في هذه الحالة، اضبط إعدادات الفحص للسماح بوقت أطول لتهيئة الحاوية. أو جرب وحدة SKU جهاز ظاهري أكبر بين وحدات SKU للجهاز الظاهري المدعومة، ما يسرع التهيئة.
  • يوجد خطأ في البيئة التي تم إعدادها للحاوية، مثل التبعية المفقودة.
  • عند تلقي TypeError: register() takes 3 positional arguments but 4 were given الخطأ، تحقق من التبعية بين flask v2 و azureml-inference-server-http. لمزيد من المعلومات، راجع الأسئلة المتداولة لخادم HTTP الاستدلال.

«خطأ»: ResourceNotFound

القائمة التالية هي أسباب قد تواجه هذا الخطأ فقط عند استخدام إما نقطة نهاية مدارة عبر الإنترنت أو نقطة نهاية Kubernetes عبر الإنترنت:

يتعذر على Resource Manager العثور على مورد

يحدث هذا الخطأ عند تعذر Azure Resource Manager في العثور على المورد المطلوب. على سبيل المثال، يمكنك تلقي هذا الخطأ إذا تمت الإشارة إلى حساب تخزين ولكن لا يمكن العثور عليه في المسار الذي تم تحديده عليه. تأكد من التحقق مرة أخرى من الموارد التي قد تم توفيرها بواسطة المسار المحدد أو التدقيق الإملائي لأسمائها.

لمزيد من المعلومات، راجع حل أخطاء عدم العثور على المورد.

خطأ في تخويل سجل الحاوية

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

للتخفيف من هذا الخطأ، تأكد من أن سجل الحاوية ليس خاصًا أو اتبع الخطوات التالية:

  1. امنح دور acrPull للسجل الخاص بك إلى هوية النظام لنقطة النهاية عبر الإنترنت.
  2. في تعريف البيئة الخاصة بك، حدد عنوان صورتك الخاصة وتعليمات عدم تعديل (إنشاء) الصورة.

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

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

خطأ: WorkspaceManagedNetworkNotReady

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

ERROR: OperationCanceled

القائمة التالية هي أسباب قد تواجه هذا الخطأ عند استخدام نقطة نهاية مدارة عبر الإنترنت أو نقطة نهاية Kubernetes عبر الإنترنت:

تم إلغاء العملية بواسطة عملية أخرى ذات أولوية أعلى

تتمتع عمليات Azure بمستوى أولوية معين ويتم تنفيذها من الأعلى إلى الأسفل. يحدث هذا الخطأ عند تجاوز العملية بواسطة عملية أخرى لها أولوية أعلى.

قد تسمح إعادة محاولة تنفيذ العملية دون إلغائها.

تم إلغاء العملية في انتظار تأكيد التأمين

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

قد تسمح إعادة محاولة العملية بعد الانتظار عدة ثوان حتى دقيقة بتنفيذها دون إلغاء.

خطأ: SecretsInjectionError

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

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

لمزيد من المعلومات، راجع إدخال البيانات السرية في نقاط النهاية عبر الإنترنت (معاينة) وبيانات Access السرية من النشر عبر الإنترنت باستخدام حقن البيانات السرية (معاينة).

«خطأ»: InternalServerError

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

الأخطاء الشائعة الخاصة بنشر Kubernetes

الأخطاء المتعلقة بالهوية والمصادقة:

الأخطاء المتعلقة ب crashloopbackoff:

أخطاء تتعلق بتسجيل البرنامج النصي:

الاخرين:

خطأ: ACRSecretError

القائمة التالية هي أسباب قد تواجه هذا الخطأ عند إنشاء/تحديث عمليات توزيع Kubernetes عبر الإنترنت:

  • لم يتم إكمال تعيين الدور. في هذه الحالة، انتظر لبضع ثوان وحاول مرة أخرى لاحقا.
  • لم يتم تثبيت أو تكوين ملحق Azure ARC (لنظام مجموعة Azure Arc Kubernetes) أو ملحق Azure التعلم الآلي (ل AKS) بشكل صحيح. حاول التحقق من تكوين ملحق Azure ARC أو Azure التعلم الآلي وحالته.
  • يحتوي نظام مجموعة Kubernetes على تكوين شبكة غير صحيح، تحقق من الوكيل أو نهج الشبكة أو الشهادة.
    • إذا كنت تستخدم مجموعة AKS خاصة، فمن الضروري إعداد نقاط نهاية خاصة ل ACR وحساب التخزين ومساحة العمل في شبكة AKS الظاهرية.
  • تأكد من أن إصدار ملحق Azure التعلم الآلي أكبر من الإصدار 1.1.25.

ERROR: TokenRefreshFailed

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

خطأ: GetAADTokenFailed

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

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

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

  • يمكنك التحقق مما إذا كان الوصول إلى مساحة العمل يسمح بالوصول العام، بغض النظر عما إذا كان نظام مجموعة AKS نفسه عاما أو خاصا، فإنه لا يمكنه الوصول إلى مساحة العمل الخاصة.
  • مزيد من المعلومات يمكنك الرجوع إلى بيئة استدلال خدمة Azure Kubernetes الآمنة

خطأ: ACRAuthenticationChallengeFailed

يرجع هذا الخطأ إلى أن مجموعة Kubernetes لا يمكنها الوصول إلى خدمة ACR لمساحة العمل للقيام بتحدي المصادقة. تحقق من شبكتك، خاصة الوصول إلى الشبكة العامة ACR، ثم حاول مرة أخرى.

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

خطأ: ACRTokenExchangeFailed

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

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

خطأ: KubernetesUnaccessible

قد تحصل على الخطأ التالي أثناء عمليات نشر نموذج Kubernetes:

{"code":"BadRequest","statusCode":400,"message":"The request is invalid.","details":[{"code":"KubernetesUnaccessible","message":"Kubernetes error: AuthenticationException. Reason: InvalidCertificate"}],...}

للتخفيف من هذا الخطأ، يمكنك:

  • قم بتدوير شهادة AKS لنظام المجموعة. لمزيد من المعلومات، راجع دوران الشهادة في خدمة Azure Kubernetes (AKS).
  • يجب تحديث الشهادة الجديدة إلى بعد 5 ساعات، بحيث يمكنك الانتظار لمدة 5 ساعات وإعادة نشرها.

خطأ: ImagePullLoopBackOff

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

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

خطأ: DeploymentCrashLoopBackOff

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

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

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

خطأ: KubernetesCrashLoopBackOff

القائمة التالية هي الأسباب التي قد تواجهك في هذا الخطأ عند إنشاء/تحديث نقاط نهاية/توزيع Kubernetes عبر الإنترنت:

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

خطأ: NamespaceNotFound

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

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

خطأ: UserScriptInitFailed

السبب في أنك قد تواجه هذا الخطأ عند إنشاء/تحديث عمليات نشر Kubernetes عبر الإنترنت هو أن الدالة init في الملف الذي تم تحميله score.py أثارت استثناء.

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

خطأ: UserScriptImportError

السبب في أنك قد تواجه هذا الخطأ عند إنشاء/تحديث عمليات نشر Kubernetes عبر الإنترنت هو أن الملف الذي score.py قمت بتحميله قد استورد حزما غير متوفرة.

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

خطأ: UserScriptFunctionNotFound

السبب في أنك قد تواجه هذا الخطأ عند إنشاء/تحديث عمليات نشر Kubernetes عبر الإنترنت هو أن الملف الذي score.py قمت بتحميله لا يحتوي على دالة تسمى init() أو run(). يمكنك التحقق من التعليمات البرمجية وإضافة الدالة.

خطأ: EndpointNotFound

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

خطأ: EndpointAlreadyExists

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

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

ERROR: ScoringFeUnhealthy

السبب في أنك قد تواجه هذا الخطأ عند إنشاء/تحديث نقطة نهاية/نشر Kubernetes عبر الإنترنت هو أن Azureml-fe هي خدمة النظام التي تعمل في نظام المجموعة غير موجود أو غير سليم.

لحل هذه المشكلة، يمكنك إعادة تثبيت ملحق Azure التعلم الآلي أو تحديثه في مجموعتك.

خطأ: ValidateScoringFailed

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

في هذه الحالة، يمكنك أولا التحقق من عنوان URL لنقطة النهاية ثم محاولة إعادة نشر النشر.

خطأ: InvalidDeploymentSpec

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

في هذه الحالة، يمكنك التحقق من رسالة الخطأ.

  • تأكد من instance count أن صالح.
  • إذا قمت بتمكين التحجيم التلقائي، فتأكد من minimum instance count أن و maximum instance count صالحان.

خطأ: PodUnschulable

القائمة التالية هي الأسباب التي قد تواجهك في هذا الخطأ عند إنشاء/تحديث نقاط نهاية/توزيع Kubernetes عبر الإنترنت:

  • غير قادر على جدولة pod إلى العقد، بسبب عدم كفاية الموارد في نظام المجموعة.
  • لا توجد عقدة تطابق العقدة/ محدد.

للتخفيف من هذا الخطأ، يمكنك اتباع الخطوات التالية:

  • node selector تحقق من تعريف الذي استخدمته instance type وتكوين node label عقد نظام المجموعة.
  • تحقق من instance type حجم عقدة SKU لنظام مجموعة AKS أو مورد العقدة لمجموعة Arc-Kubernetes.
    • إذا كان نظام المجموعة أقل من الموارد، يمكنك تقليل متطلبات مورد نوع المثيل أو استخدام نوع مثيل آخر مع مورد أصغر مطلوب.
  • إذا لم يكن لدى نظام المجموعة مورد إضافي لتلبية متطلبات النشر، فاحذف بعض النشر لتحرير الموارد.

خطأ: PodOutOfMemory

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

خطأ: الاستدلالClientCallFailed

السبب في أنك قد تواجه هذا الخطأ عند إنشاء/تحديث نقاط نهاية/توزيع Kubernetes عبر الإنترنت هو أن ملحق k8s لمجموعة Kubernetes غير قابل للاتصال.

في هذه الحالة، يمكنك فصل الحساب ثم إعادة إرفاقه .

إشعار

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

إذا كان لا يزال لا يعمل، يمكنك أن تطلب من المسؤول الذي يمكنه الوصول إلى نظام المجموعة لاستخدامه kubectl get po -n azureml للتحقق مما إذا كانت جرابات خادم الترحيل قيد التشغيل.

مشكلات التحجيم التلقائي

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

بالنسبة لنقطة نهاية Kubernetes عبر الإنترنت، هناك موجه استدلال Azure التعلم الآلي وهو مكون واجهة أمامية للتعامل مع التحجيم التلقائي لجميع عمليات نشر النموذج على مجموعة Kubernetes، يمكنك العثور على مزيد من المعلومات في التحجيم التلقائي لتوجيه استدلال Kubernetes

أخطاء استهلاك النموذج الشائعة

القائمة التالية هي من أخطاء استهلاك النموذج الشائعة الناتجة عن حالة عملية نقطة invoke النهاية.

مشكلات في حد النطاق الترددي

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

  • استخدم مقياس "وحدات بايت الشبكة" لفهم استخدام النطاق الترددي الحالي. لمزيد من المعلومات، راجع نقاط النهاية المُدارة عبر الإنترنت.
  • هناك مقطورتان للاستجابة يتم إرجاعهما إذا تم فرض حد النطاق الترددي:
    • ms-azureml-bandwidth-request-delay-ms: وقت التأخير بالمللي ثانية المستغرق لنقل دفق الطلب.
    • ms-azureml-bandwidth-response-delay-ms: وقت التأخير بالمللي ثانية المستغرق لنقل دفق الاستجابة.

تعليمة برمجية حالة HTTP

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

رموز الخطأ الشائعة لنقاط النهاية المدارة عبر الإنترنت

يحتوي الجدول التالي على رموز الخطأ الشائعة عند استهلاك نقاط النهاية المدارة عبر الإنترنت مع طلبات REST:

كود الحالة عبارة السبب لماذا قد يتم إرجاع هذه التعليمة البرمجية
200 موافق تم تنفيذ النموذج الخاص بك بنجاح، في غضون حد زمن الانتقال.
401 غير مصرح به ليس لديك الإذن للقيام بالإجراء المطلوب، مثل النتيجة، أو انتهت صلاحية الرمز المميز الخاص بك أو بتنسيق خاطئ. لمزيد من المعلومات، راجع مفهوممصادقة نقطة النهاية وكيفية المصادقة لنقطة النهاية.
404 غير موجود لا تحتوي نقطة النهاية على أي توزيع صالح مع وزن موجب.
408 انتهي وقت الطلب استغرق تنفيذ النموذج وقتًا أطول من المهلة الموجودة في request_timeout_ms ضمن request_settings من تكوين نشر النموذج الخاص بك.
424 خطأ بالنموذج إذا كانت حاوية النموذج تُرجع رمز استجابة غير 200، فإن Azure تُرجع رمز استجابة 424. تحقق من Model Status Code البعد ضِمن المقياس Requests Per Minute على Azure Monitor Metric Explorer الخاص بنقطة النهاية. تحقّق من عناوين الاستجابة ms-azureml-model-error-statuscode و ms-azureml-model-error-reason للحصول على مزيد من المَعلومات. إذا كان 424 يأتي مع فشل فحص فعالية أو جاهزية، ففكر في ضبط إعدادات الفحص للسماح بوقت أطول لفحص فعالية الحاوية أو استعدادها.
429 عدد كبير للغاية من الطلبات المعلقة يحصل النموذج الخاص بك حاليا على طلبات أكثر مما يمكنه التعامل معه. نفذت Azure التعلم الآلي نظاما يسمح بمعالجة الحد الأقصى 2 * max_concurrent_requests_per_instance * instance_count requests بالتوازي في أي لحظة لضمان التشغيل السلس. يتم رفض الطلبات الأخرى التي تتجاوز هذا الحد الأقصى. يمكنك مراجعة تكوين توزيع النموذج الخاص بك ضمن قسمي request_settings scale_settings للتحقق من هذه الإعدادات وضبطها. بالإضافة إلى ذلك، كما هو موضح في تعريف YAML ل RequestSettings، من المهم التأكد من تمرير متغير WORKER_COUNT البيئة بشكل صحيح.

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

رموز الخطأ الشائعة لنقاط نهاية kubernetes عبر الإنترنت

يحتوي الجدول التالي على رموز الخطأ الشائعة عند استهلاك نقاط نهاية Kubernetes عبر الإنترنت مع طلبات REST:

كود الحالة عبارة السبب لماذا قد يتم إرجاع هذه التعليمة البرمجية
409 خطأ في التعارض عندما تكون عملية قيد التقدم بالفعل، تستجيب أي عملية جديدة على نفس نقطة النهاية عبر الإنترنت بخطأ تعارض 409. على سبيل المثال، إذا كانت عملية إنشاء نقطة النهاية عبر الإنترنت أو تحديثها قيد التقدم وإذا قمت بتشغيل عملية حذف جديدة، فإنها تطرح خطأ.
502 طرح استثناء أو تعطل في run() أسلوب ملف score.py عند وجود خطأ في score.py، على سبيل المثال، لا توجد حزمة مستوردة في بيئة conda أو خطأ في بناء الجملة أو فشل في init() الأسلوب. يمكنك المتابعة هنا لتصحيح أخطاء الملف.
503 تلقي ارتفاعات كبيرة في الطلبات في الثانية تم تصميم التحجيم التلقائي للتعامل مع التغييرات التدريجية في التحميل. إذا تلقيت طفرات كبيرة في الطلبات في الثانية، فقد يتلقى العملاء رمز حالة HTTP 503. على الرغم من أن التحجيم التلقائي يتفاعل بسرعة، إلا أن AKS يستغرق قدرًا كبيرًا من الوقت لإنشاء حاويات إضافية. يمكنك المتابعة هنا لمنع 503 رمز حالة.
504 انتهت مهلة الطلب يشير رمز الحالة 504 إلى انتهاء مهلة الطلب. إعداد المهلة الافتراضي هو 5 ثوان. يمكنك زيادة المهلة أو محاولة تسريع نقطة النهاية عن طريق تعديل score.py لإزالة المكالمات غير الضرورية. إذا لم تصحح هذه الإجراءات المشكلة، يمكنك المتابعة هنا لتصحيح score.py الملف. قد تكون التعليمات البرمجية في حالة غير مستجيبة أو حلقة لا نهائية.
500 خطأ في الخادم الداخلي فشل البنية الأساسية التي توفرها Azure التعلم الآلي.

كيفية منع رموز الحالة 503

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

هناك أمران يمكن أن يساعدا في منع رموز الحالة 503:

تلميح

يمكن استخدام هذين النهجين بشكل فردي أو معا.

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

    هام

    لا يؤدي هذا التغيير إلى إنشاء النسخ المتماثلة بشكل أسرع. بدلا من ذلك، يتم إنشاؤها عند حد استخدام أقل. بدلا من الانتظار حتى يتم استخدام الخدمة بنسبة 70٪، يؤدي تغيير القيمة إلى 30٪ إلى إنشاء النسخ المتماثلة عند حدوث استخدام 30٪.

    إذا كانت نقطة نهاية Kubernetes عبر الإنترنت تستخدم بالفعل النسخ المتماثلة القصوى الحالية وما زلت ترى 503 رمز حالة، فقم بزيادة autoscale_max_replicas القيمة لزيادة الحد الأقصى لعدد النسخ المتماثلة.

  • تغيير الحد الأدنى لعدد النسخ المتماثلة. توفر زيادة الحد الأدنى من النسخ المتماثلة تجمعا أكبر للتعامل مع الارتفاعات الواردة.

    لزيادة عدد المثيلات، يمكنك حساب النسخ المتماثلة المطلوبة باتباع هذه الرموز.

    from math import ceil
# target requests per second
target_rps = 20
# time to process the request (in seconds, choose appropriate percentile)
request_process_time = 10
# Maximum concurrent requests per instance
max_concurrent_requests_per_instance = 1
# The target CPU usage of the model container. 70% in this example
target_utilization = .7

concurrent_requests = target_rps * request_process_time / target_utilization

# Number of instance count
instance_count = ceil(concurrent_requests / max_concurrent_requests_per_instance)

    إشعار

    إذا تلقيت طفرات في الطلب أكبر من الحد الأدنى الجديد للنسخ المتماثلة التي يمكن معالجتها، فقد تتلقى 503 مرة أخرى. على سبيل المثال، مع زيادة نسبة استخدام الشبكة إلى نقطة النهاية، قد تحتاج إلى زيادة الحد الأدنى من النسخ المتماثلة.

كيفية حساب عدد المثيلات

لزيادة عدد المثيلات، يمكنك حساب النسخ المتماثلة المطلوبة باستخدام التعليمات البرمجية التالية:

from math import ceil
# target requests per second
target_rps = 20
# time to process the request (in seconds, choose appropriate percentile)
request_process_time = 10
# Maximum concurrent requests per instance
max_concurrent_requests_per_instance = 1
# The target CPU usage of the model container. 70% in this example
target_utilization = .7

concurrent_requests = target_rps * request_process_time / target_utilization

# Number of instance count
instance_count = ceil(concurrent_requests / max_concurrent_requests_per_instance)

محظور بواسطة نهج CORS

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

Access to fetch at 'https://{your-endpoint-name}.{your-region}.inference.ml.azure.com/score' from origin http://{your-url} has been blocked by CORS policy: Response to preflight request doesn't pass access control check. No 'Access-control-allow-origin' header is present on the request resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with the CORS disabled.

نوصي باستخدام Azure Functions أو Azure Application Gateway أو أي خدمة كطبقة مؤقتة لمعالجة طلبات الاختبار المبدئي ل CORS.

مشاكل عزل الشبكة الشائعة

فشل إنشاء نقطة النهاية عبر الإنترنت مع رسالة V1LegacyMode == true

يمكن تكوين مساحة عمل التعلم الآلي من Azure v1_legacy_mode، والتي تعطل واجهات برمجة التطبيقات v2. نقاط النهاية المدارة عبر الإنترنت هي ميزة من ميزات النظام الأساسي لواجهة برمجة التطبيقات v2، ولن تعمل إذا تم تمكين v1_legacy_mode لمساحة العمل.

هام

تحقق مع فريق أمان الشبكة قبل تعطيل v1_legacy_mode. ربما تم تمكينه من قبل فريق أمان الشبكة لسبب ما.

للحصول على معلومات حول كيفية تعطيل v1_legacy_mode، راجع عزل الشبكة باستخدام v2.

فشل إنشاء نقطة النهاية عبر الإنترنت باستخدام المصادقة المستندة إلى المفتاح

استخدم الأمر التالي لسرد قواعد الشبكة الخاصة بـAzure Key Vault لمساحة العمل الخاصة بك. استبدل <keyvault-name> باسم مخزن المفاتيح الخاصة بك:

az keyvault network-rule list -n <keyvault-name>

تشبه استجابة هذا الأمر مستند JSON التالي:

{
    "bypass": "AzureServices",
    "defaultAction": "Deny",
    "ipRules": [],
    "virtualNetworkRules": []
}

إذا كانت قيمة bypass ليست AzureServices، فاستخدم الإرشادات الواردة في تكوين إعدادات شبكة مخزن المفاتيح لتعيينها إلى AzureServices.

فشل عمليات النشر عبر الإنترنت بحدوث خطأ في تنزيل الصورة

إشعار

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

  1. تحقق مما إذا كانت egress-public-network-access العلامة معطلة للنشر. إذا تم تمكين هذه العلامة، وكانت رؤية سجل الحاوية خاصة، فمن المتوقع حدوث ذلك الفشل.

  2. استخدم الأمر التالي للتحقق من حالة اتصال نقطة النهاية الخاصة. استبدل <registry-name> باسم Azure Container Registry لمساحة العمل الخاصة بك:

    az acr private-endpoint-connection list -r <registry-name> --query "[?privateLinkServiceConnectionState.description=='Egress for Microsoft.MachineLearningServices/workspaces/onlineEndpoints'].{Name:name, status:privateLinkServiceConnectionState.status}"

    في مستند الاستجابة، تحقق من تعيين الحقل status إلى Approved. إذا لم تتم الموافقة عليه، فاستخدم الأمر التالي للموافقة عليه. استبدل <private-endpoint-name> بالاسم الذي تم إرجاعه من الأمر السابق:

    az network private-endpoint-connection approve -n <private-endpoint-name>

لا يمكن حل نقطة نهاية التسجيل

  1. تحقق من أن العميل الذي أصدر طلب التسجيل عبارة عن شبكة ظاهرية يمكنها الوصول إلى مساحة عمل «التعلم الآلي» من Azure.

  2. استخدم الأمر nslookup في اسم مضيف نقطة النهاية لاسترداد معلومات عنوان IP:

    nslookup endpointname.westcentralus.inference.ml.azure.com

    تحتوي الاستجابة على عنوان. يجب أن يكون هذا العنوان في النطاق الذي توفره الشبكة الظاهرية

    إشعار

    بالنسبة لنقطة نهاية Kubernetes عبر الإنترنت، يجب أن يكون اسم مضيف نقطة النهاية CName (اسم المجال) الذي تم تحديده في مجموعة Kubernetes. إذا كانت نقطة نهاية HTTP، تضمين عنوان IP في URI نقطة النهاية التي يمكنك الحصول عليها مباشرة في واجهة مستخدم Studio. يمكن العثور على مزيد من الطرق للحصول على عنوان IP لنقطة النهاية في نقطة نهاية Secure Kubernetes عبر الإنترنت.

  3. إذا لم يتم حل اسم المضيف بواسطة nslookup الأمر:

    بالنسبة لنقطة النهاية المدارة عبر الإنترنت،

    1. تحقق مما إذا كان هناك سجل A في منطقة DNS الخاصة للشبكة الظاهرية.

      للتحقق من السجلات، استخدم الأمر التالي:

      az network private-dns record-set list -z privatelink.api.azureml.ms -o tsv --query [].name

      يجب أن تحتوي النتائج على إدخال مشابه لـ *.<GUID>.inference.<region>.

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

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

      dig endpointname.westcentralus.inference.ml.azure.com

    بالنسبة لنقطة نهاية Kubernetes عبر الإنترنت،

    1. تحقق من تكوين DNS في مجموعة Kubernetes.

    2. بالإضافة إلى ذلك، يمكنك التحقق مما إذا كان azureml-fe يعمل كما هو متوقع، استخدم الأمر التالي:

      kubectl exec -it deploy/azureml-fe -- /bin/bash
(Run in azureml-fe pod)

curl -vi -k https://localhost:<port>/api/v1/endpoint/<endpoint-name>/swagger.json
"Swagger not found"

      بالنسبة إلى HTTP، استخدم

      curl https://localhost:<port>/api/v1/endpoint/<endpoint-name>/swagger.json
"Swagger not found"

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

    إذا فشل حل هذا إلى سجل A، فتحقق مما إذا كانت الدقة تعمل من Azure DNS(168.63.129.16).

    dig @168.63.129.16 endpointname.westcentralus.inference.ml.azure.com

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

لا يمكن تسجيل عمليات النشر عبر الإنترنت

  1. استخدم الأمر التالي لمعرفة ما إذا تم توزيع النشر بنجاح:

    az ml online-deployment show -e <endpointname> -n <deploymentname> --query '{name:name,state:provisioning_state}'

    إذا اكتمل النشر بنجاح، فإن قيمة state ستكون Succeeded.

  2. إذا كان النشر ناجحاً، فاستخدم الأمر التالي للتحقق من تخصيص نسبة استخدام الشبكة للنشر. قم باستبدال <endpointname> باسم نقطة النهاية الخاصة بك:

    az ml online-endpoint show -n <endpointname>  --query traffic

    تلميح

    هذه الخطوة غير ضرورية إذا كنت تستخدم العنوان azureml-model-deployment في طلبك لاستهداف هذا النشر.

    يجب أن تسرد الاستجابة من هذا الأمر النسبة المئوية لنسبة استخدام الشبكة المخصصة لعمليات النشر.

  3. إذا تم تعيين تعيينات نسبة استخدام الشبكة (أو عنوان النشر) بشكل صحيح، فاستخدم الأمر التالي للحصول على السجلات لنقطة النهاية. استبدل <endpointname> باسم نقطة النهاية و<deploymentname> بالنشر:

    az ml online-deployment get-logs  -e <endpointname> -n <deploymentname>

    ابحث في السجلات لمعرفة ما إذا كانت هناك مشكلة في تشغيل رمز التسجيل عند إرسال طلب إلى النشر.

استكشاف أخطاء خادم الاستدلال وإصلاحها

في هذا القسم، نقدم تلميحات أساسية لاستكشاف الأخطاء وإصلاحها لخادم HTTP للاستدلال على Azure التعلم الآلي.

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

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

  1. جمع معلومات الإصدار لبيئة Python الخاصة بك.
  2. تأكد من أن إصدار حزمة azureml-inference-server-http python المحدد في ملف البيئة يطابق إصدار خادم HTTP للاستدلال على AzureML الذي يتم عرضه في سجل بدء التشغيل. في بعض الأحيان يؤدي محلل تبعية pip إلى إصدارات غير متوقعة من الحزم المثبتة.
  3. إذا قمت بتحديد Flask (وتبعياتها) في بيئتك، فقم بإزالتها. تتضمن Flaskالتبعيات و Jinja2itsdangerousو WerkzeugMarkupSafeو.click يتم سرد Flask كتبعية في حزمة الخادم ومن الأفضل السماح لخادمنا بتثبيتها. بهذه الطريقة عندما يدعم الخادم إصدارات جديدة من Flask، ستحصل عليها تلقائيا.

إصدار الخادم

يتم نشر حزمة azureml-inference-server-http الخادم إلى PyPI. يمكنك العثور على سجل التغيير وجميع الإصدارات السابقة على صفحة PyPI الخاصة بنا. قم بتحديث إلى أحدث إصدار إذا كنت تستخدم إصدارا سابقا.

  • 0.4.x: الإصدار المجمع في صور التدريب ≤ 20220601 وفي azureml-defaults>=1.34,<=1.43. 0.4.13 هو آخر إصدار مستقر. إذا كنت تستخدم الخادم قبل الإصدار 0.4.11، فقد ترى مشكلات تبعية Flask مثل تعذر استيراد الاسم Markup من jinja2. يوصى بالترقية إلى 0.4.13 أو 0.8.x (أحدث إصدار)، إن أمكن.
  • 0.6.x: الإصدار المثبت مسبقا في استنتاج الصور ≤ 20220516. أحدث إصدار مستقر هو 0.6.1.
  • 0.7.x: الإصدار الأول الذي يدعم Flask 2. أحدث إصدار مستقر هو 0.7.7.
  • 0.8.x: تم تغيير تنسيق السجل وتراجع دعم Python 3.6.

تبعيات الحزمة

الحزم الأكثر صلة بالخادم azureml-inference-server-http هي الحزم التالية:

  • قارورة
  • opencensus-ext-azure
  • مخطط الاستدلال

إذا حددت azureml-defaults في بيئة Python الخاصة بك، فإن الحزمة azureml-inference-server-http تعتمد على، وسيتم تثبيتها تلقائيا.

تلميح

إذا كنت تستخدم Python SDK v1 ولم تحدد azureml-defaults بشكل صريح في بيئة Python الخاصة بك، فقد تضيف SDK الحزمة لك. ومع ذلك، فإنه سيتم تأمينه على الإصدار الذي تعمل عليه SDK. على سبيل المثال، إذا كان إصدار SDK هو 1.38.0، فإنه سيضيف azureml-defaults==1.38.0 إلى متطلبات النقطة للبيئة.

الأسئلة الشائعة

1. واجهت الخطأ التالي أثناء بدء تشغيل الخادم:


TypeError: register() takes 3 positional arguments but 4 were given

  File "/var/azureml-server/aml_blueprint.py", line 251, in register

    super(AMLBlueprint, self).register(app, options, first_registration)

TypeError: register() takes 3 positional arguments but 4 were given

لقد قمت بتثبيت Flask 2 في بيئة Python الخاصة بك ولكنك تقوم بتشغيل إصدار azureml-inference-server-http لا يدعم Flask 2. تتم إضافة دعم Flask 2 في azureml-inference-server-http>=0.7.0، وهو أيضًا في azureml-defaults>=1.44.

  • إذا كنت لا تستخدم هذه الحزمة في صورة AzureML docker، فاستخدم أحدث إصدار من azureml-inference-server-http أو azureml-defaults.

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

    2022-08-22T17:05:02,147738763+00:00 | gunicorn/run | AzureML Container Runtime Information
2022-08-22T17:05:02,161963207+00:00 | gunicorn/run | ###############################################
2022-08-22T17:05:02,168970479+00:00 | gunicorn/run | 
2022-08-22T17:05:02,174364834+00:00 | gunicorn/run | 
2022-08-22T17:05:02,187280665+00:00 | gunicorn/run | AzureML image information: openmpi4.1.0-ubuntu20.04, Materializaton Build:20220708.v2
2022-08-22T17:05:02,188930082+00:00 | gunicorn/run | 
2022-08-22T17:05:02,190557998+00:00 | gunicorn/run |

    يظهر تاريخ إنشاء الصورة بعد "بناء التجسيد"، والذي في المثال أعلاه هو 20220708، أو 8 يوليو 2022. هذه الصورة متوافقة مع Flask 2. إذا لم تشاهد شعارًا مثل هذا في سجل الحاوية، فإن صورتك قديمة ويجب تحديثها. إذا كنت تستخدم صورة CUDA، ولم تتمكن من العثور على صورة أحدث، فتحقق مما إذا كانت صورتك مهملة في AzureML-Containers. إذا كان الأمر كذلك، يجب أن تكون قادرا على العثور على بدائل.

  • إذا كنت تستخدم الخادم مع نقطة نهاية عبر الإنترنت، يمكنك أيضا العثور على السجلات ضمن "سجلات النشر" في صفحة نقطة النهاية عبر الإنترنت في Azure التعلم الآلي studio. إذا قمت بالنشر باستخدام SDK v1 ولم تحدد صورة بشكل صريح في تكوين التوزيع الخاص بك، فسيكون استخدام إصدار من openmpi4.1.0-ubuntu20.04 ذلك يطابق مجموعة أدوات SDK المحلية، والتي قد لا تكون أحدث إصدار من الصورة. على سبيل المثال، سيستخدم SDK 1.43 openmpi4.1.0-ubuntu20.04:20220616 افتراضيًا، وهو غير متوافق. تأكد من استخدام أحدث SDK للتوزيع.

  • إذا كنت غير قادر على تحديث الصورة لسبب ما، يمكنك تجنب المشكلة مؤقتا عن طريق تثبيت azureml-defaults==1.43 أو azureml-inference-server-http~=0.4.13، والذي سيقوم بتثبيت خادم الإصدار الأقدم باستخدام Flask 1.0.x.

2. واجهت ImportError أو ModuleNotFoundError على الوحدات النمطية opencensus أو jinja2 أو MarkupSafe أو click في أثناء بدء التشغيل كما يلي:

ImportError: cannot import name 'Markup' from 'jinja2'

لم تقم الإصدارات القديمة (<= 0.4.10) من الخادم بتثبيت تبعية Flask على الإصدارات المتوافقة. تم إصلاح هذه المشكلة في أحدث إصدار من الخادم.

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