فهم أخطاء مركز Azure IoT وحلها

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

إغلاق 400027 الاتصال بقوة على اتصال جديد

قد ترى خطأ 400027 الاتصال ionForcefullyClosedOnNew الاتصال ion إذا كان جهازك يقطع اتصال جهازك Communication_Error ك الاتصال ionStatusChangeReason باستخدام نوع النقل .NET SDK وMQTT. أو، تفشل العملية المزدوجة من جهاز إلى سحابة (مثل خصائص القراءة أو التصحيح المبلغ عنها) أو استدعاء الأسلوب المباشر مع رمز الخطأ 400027.

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

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

401003 IoT Hub غير مصرح به

في السجلات، قد ترى نمطًا من الأجهزة التي يتم قطع اتصالها مع 401003 IoTHubUn المصرح به، متبوعًا 404104 DeviceConnectionClosedRemotely، ثم الاتصال بنجاح بعد وقت قصير.

أو، تفشل الطلبات إلى مركز IoT مع إحدى رسائل الخطأ التالية:

• Authorization header missing
• IotHub '*' لا يحتوي على الجهاز المحدد '*'
• Authorization rule '*' لا يسمح بالوصول إلى '*'
• فشل التخويل لهذا الجهاز، حدّث الرمز المميز أو الشهادة وأعد الاتصال
• البصمة لا توافق التكوين: Thumbprint: SHA1Hash=*, SHA2Hash=*; Configuration: PrimaryThumbprint=*, SecondaryThumbprint=*
• المسؤول user@example.com غير مخول لـGET on /exampleOperation بسبب الأذونات المعينة

يحدث هذا الخطأ لأنه بالنسبة إلى MQTT، تعتمد بعض SDKs على مركز IoT لإصدار قطع الاتصال عند انتهاء صلاحية رمز SAS المميز لمعرفة متى يتم تحديثه. إذن،

1. تنتهي صلاحية رمز SAS
2. يلاحظ مركز IoT انتهاء الصلاحية ويفصل الجهاز بـ 401003 IoTHubUnauthorized
3. يكمل الجهاز قطع الاتصال بـ 404104 DeviceConnectionClosedRemotely
4. تنشئ IoT SDK رمز SAS جديداً
5. أعاد الجهاز الاتصال بـ IoT Hub بنجاح

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

لحل هذا الخطأ، لا يلزم اتخاذ أي إجراء إذا كنت تستخدم IoT SDK للاتصال باستخدام سلسلة اتصال الجهاز. تعيد IoT SDK إنشاء الرمز المميز الجديد لإعادة الاتصال عند انتهاء صلاحية الرمز المميز لـ SAS.

عمر الرمز الافتراضي 60 دقيقة عبر SDKs؛ ومع ذلك، بالنسبة لبعض SDKs، يكون عمر الرمز المميز وحد تجديد الرمز المميز قابلين للتكوين. بالإضافة إلى ذلك، تختلف الأخطاء التي تنشأ عند قطع اتصال الجهاز وإعادة الاتصال عند تجديد الرمز المميز لكل SDK. لمعرفة المزيد، وللحصول على معلومات حول كيفية تحديد SDK الذي يستخدمه جهازك في السجلات، راجع سلوك قطع اتصال جهاز MQTT مع حزم Azure IoT SDK.

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

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

• لم تنته صلاحية SAS أو رمز الأمان الآخر الذي تستخدمه.
• بالنسبة لمصادقة شهادة X.509، لم تنته صلاحية شهادة الجهاز أو شهادة CA المرتبطة بالجهاز. لمعرفة كيفية تسجيل شهادات المرجع المصدق X.509 مع IoT Hub، راجع البرنامج التعليمي: إنشاء الشهادات وتحميلها للاختبار.
• بالنسبة لمصادقة بصمة الإبهام لشهادة X.509، يتم تسجيل بصمة شهادة الجهاز مع مركز IoT.
• تم تشكيل بيانات اعتماد التفويض بشكل جيد للبروتوكول الذي تستخدمه. لمعرفة المزيد، راجع التحكم في الوصول إلى مركز IoT.
• قاعدة التفويض المستخدمة لديها الإذن للعملية المطلوبة.
• بالنسبة إلى رسائل الخطأ الأخيرة التي تبدأ بـ "‎‎...principal"، يمكن حل هذا الخطأ عن طريق تعيين المستوى الصحيح لإذن Azure RBAC للمستخدم. على سبيل المثال، يمكن لمالك في IoT Hub تعيين دور "IoT Hub Data Owner"، والذي يمنح جميع الأذونات. جرب هذا الدور لحل مشكلة عدم وجود إذن.

إشعار

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

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

تجاوز الحصة النسبية 403002 IoT Hub

قد ترى الطلبات إلى مركز IoT تفشل مع ظهور الخطأ 403002 IoTHubQuotaExceeded. وفي مدخل Microsoft Azure، لا يتم تحميل قائمة أجهزة مركز IoT.

يحدث هذا الخطأ عادة عند تجاوز الحصة النسبية للرسالة اليومية لمركز IoT. لحل هذا الخطأ:

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

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

403004 تجاوز الحد الأقصى لعمق قائمة الانتظار للجهاز

عند محاولة إرسال رسالة من السحابة إلى الجهاز، قد ترى أن الطلب يفشل مع الخطأ 403004 أو DeviceMaximumQueueDepthExceeded.

السبب الأساسي لهذا الخطأ هو أن عدد الرسائل المدرجة في قائمة الانتظار للجهاز يتجاوز حد قائمة الانتظار.

السبب الأكثر احتمالاً لوقوعك في هذا الحد هو أنك تستخدم HTTPS لتلقي الرسالة، ما يؤدي إلى استقصاء مستمر باستخدام ReceiveAsync، ما يؤدي إلى تقييد IoT Hub للطلب.

النمط المدعوم للرسائل من السحابة إلى الجهاز باستخدام HTTPS هو أجهزة متصلة بشكل متقطع تتحقق من الرسائل بشكل غير متكرر (أقل من كل 25 دقيقة). لتقليل احتمالية الدخول في حد قائمة الانتظار، قم بالتبديل إلى AMQP أو MQTT للرسائل من السحابة إلى الجهاز.

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

أخيراً، جرب استخدام Purge Queue API لتنظيف الرسائل المعلقة بشكل دوري قبل الوصول إلى الحد الأقصى.

403006 تجاوز الحد الأقصى لتحميل الملفات النشطة للجهاز

قد ترى أن طلب تحميل الملف يفشل مع رمز الخطأ 403006 DeviceMaximumActiveFileUploadLimitExceeded ورسالة "لا يمكن أن يتجاوز عدد طلبات تحميل الملفات النشطة 10".

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

لحل هذا الخطأ، تأكد من أن الجهاز يمكنه إخطار إكمال تحميل ملف مركز IoT على الفور. بعد ذلك، حاول تقليل رمز SAS المميز TTL لتكوين تحميل الملف.

لم يتم العثور على جهاز 404001

أثناء اتصال من سحابة إلى جهاز (C2D)، مثل رسالة C2D أو تحديث مزدوج أو أسلوب مباشر، قد ترى أن العملية تفشل مع الخطأ 404001 DeviceNotFound.

فشلت العملية لأن IoT Hub لا يمكنه العثور على الجهاز. الجهاز إما غير مسجل أو معطل.

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

جهاز 404103 غير متصل

قد ترى أن أسلوبًا مباشرًا إلى جهاز يفشل مع الخطأ 404103 DeviceNotOnline حتى إذا كان الجهاز متصلًا بالإنترنت.

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

لتكوين جهازك بشكل صحيح لرد الاتصال بالأسلوب المباشر، راجع معالجة أسلوب مباشر على جهاز.

404104 اتصال الجهاز مغلقا عن بعد

قد ترى أن الأجهزة قطع الاتصال على فاصل زمني منتظم (كل 65 دقيقة، على سبيل المثال) وترى 404104 DeviceConnectionClosedRemotely في سجلات موارد IoT Hub. في بعض الأحيان، ترى أيضاً 401003 IoTHubUnauthorized وحدث اتصال جهاز ناجح بعد أقل من دقيقة.

أو، يتم قطع اتصال الأجهزة عشوائيا، وتشاهد 404104 DeviceConnectionClosedRemotely في سجلات موارد مركز IoT.

أو، العديد من الأجهزة قطع الاتصال في وقت واحد، ترى تراجعا في مقياس الأجهزة المتصلة (connectedDeviceCount)، وهناك المزيد 404104 DeviceConnectionClosedRemotelyوأخطاء داخلية 500xxx في سجلات Azure Monitor أكثر من المعتاد.

يمكن أن يحدث هذا الخطأ بسبب انتهاء صلاحية رمز SAS المميز المستخدم للاتصال بمركز IoT، مما يؤدي إلى قطع اتصال مركز IoT بالجهاز. تتم إعادة إنشاء الاتصال عندما يتم تحديث الرمز المميز بواسطة الجهاز. على سبيل المثال، تنتهي صلاحية رمز SAS المميز كل ساعة بشكل افتراضي لـ C SDK، مما قد يؤدي إلى قطع اتصال منتظم. لمعرفة المزيد، راجع 401003 IoTHubUnauthorized.

وتشمل بعض الاحتمالات الأخرى ما يلي:

• فقد الجهاز اتصال الشبكة الأساسي لفترة أطول من بقاء تشغيل MQTT، مما أدى إلى انتهاء مهلة الخمول عن بُعد. يمكن أن يكون إعداد بقاء تشغيل MQTT مختلفاً لكل جهاز.
• أرسل الجهاز إعادة تعيين على مستوى TCP/IP ولكنه لم يرسل مستوى التطبيق MQTT DISCONNECT. في الأساس، أغلق الجهاز فجأة اتصال مأخذ التوصيل الأساسي. في بعض الأحيان، تحدث هذه المشكلة بسبب أخطاء في الإصدارات القديمة من Azure IoT SDK.
• تعطل تطبيق جانب الجهاز.

أو، قد يواجه مركز IoT مشكلة عابرة. راجع خطأ خادم IoT Hub الداخلي.

لحل هذا الخطأ:

• راجع إرشادات الخطأ 401003 IoTHubUn المصرح به.
• تأكد من اتصال الجهاز جيداً بمركز IoT عن طريق اختبار الاتصال. إذا كانت الشبكة غير موثوقة أو متقطعة، لا نوصي بزيادة قيمة بقاء واستمرار التشغيل لأنه قد يؤدي إلى الكشف (عبر تنبيهات Azure Monitor، على سبيل المثال) يستغرق وقتاً أطول.
• استخدم أحدث إصدارات من وحدات IoT SDK.
• راجع إرشادات أخطاء خادم مركز IoT الداخلي.

نوصي باستخدام حزم SDK لجهاز Azure IoT لإدارة الاتصالات بشكل موثوق. لمعرفة المزيد، راجع إدارة الاتصال والمراسلة الموثوقة باستخدام حزم SDK لجهاز Azure IoT Hub

409001 الجهاز موجود بالفعل

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

يحدث هذا الخطأ بسبب وجود جهاز بنفس معرف الجهاز في مركز IoT.

لحل هذا الخطأ، استخدم معرف جهاز آخر وحاول مرة أخرى.

تعارض إنشاء ارتباط 409002

قد ترى الخطأ 409002 LinkCreationConflict في السجلات جنبًا إلى جنب مع قطع اتصال الجهاز أو فشل الرسالة من السحابة إلى الجهاز.

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

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

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

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

فقدان تأمين رسالة 412002 Device

عند محاولة إرسال رسالة من السحابة إلى الجهاز، قد ترى أن الطلب يفشل مع الخطأ 412002 DeviceMessageLockLost.

يحدث هذا الخطأ لأنه عندما يتلقى جهاز رسالة من سحابة إلى جهاز من قائمة الانتظار (على سبيل المثال، باستخدام ReceiveAsync()) يتم تأمين الرسالة بواسطة مركز IoT لمدة مهلة تأمين لمدة دقيقة واحدة. إذا حاول الجهاز إكمال الرسالة بعد انتهاء مهلة القفل، فإن مركز IoT يطرح هذا الاستثناء.

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

استثناء 429001 التقييد

قد ترى أن طلباتك إلى مركز IoT تفشل مع الخطأ 429001 ThrottlingException.

يحدث هذا الخطأ عند تجاوز حدود تقييد مركز IoT للعملية المطلوبة.

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

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

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

أخطاء 500xxx داخلية

قد ترى أن طلبك إلى IoT Hub يفشل مع خطأ يبدأ ب 500 و/أو نوع من "خطأ الخادم". بعض الاحتمالات هي:

• 500001 ServerError: واجه مركز IoT مشكلة من جانب الخادم.

• 500008 GenericTimeout: تعذر على مركز IoT إكمال طلب الاتصال قبل انتهاء المهلة.

• ServiceUnavailable (لا يوجد رمز خطأ): واجه مركز IoT خطأ داخليًا.

• InternalServerError (لا يوجد رمز خطأ): صادف مركز IoT خطأ داخليًا.

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

للتخفيف من أخطاء 500xxx، قم بإصدار إعادة محاولة من الجهاز. لإدارة عمليات إعادة المحاولة تلقائيًا، تأكد من استخدام أحدث إصدار من Azure IoT SDKs. للحصول على أفضل الممارسات حول معالجة الأخطاء العابرة وإعادة المحاولة، راجع معالجة الأخطاء العابرة.

إذا استمرت المشكلة، فتحقق من صحة المواردوحالة Azure لمعرفة ما إذا كان لدى مركز IoT مشكلة معروفة. يمكنك أيضًا استخدام ميزة تجاوز الفشل اليدوي.

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

لم يتم العثور على قسم 503003

قد ترى أن الطلبات إلى مركز IoT تفشل مع الخطأ 503003 PartitionNotFound.

هذا الخطأ داخلي لـ IoT Hub ومن المحتمل أن يكون عابراً. راجع أخطاء خادم مركز IoT الداخلي.

لحل هذا الخطأ، راجع أخطاء خادم مركز IoT الداخلي.

مهلة بوابة 504101

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

يحدث هذا الخطأ لأن مركز IoT واجه خطأ ولم يتمكن من تأكيد ما إذا كان الأسلوب المباشر قد اكتمل قبل انتهاء المهلة. أو عند استخدام إصدار سابق من Azure IoT C# SDK (<1.19.0)، يمكن إسقاط ارتباط AMQP بين الجهاز ومركز IoT بصمت بسبب خطأ.

لحل هذا الخطأ، قم بإصدار إعادة المحاولة أو الترقية إلى أحدث إصدار من Azure IOT C# SDK.