مراقبة اتصال جهاز مركز Azure IoT وتشخيصه واستكشاف الأخطاء وإصلاحها
قد يصعب استكشاف مشكلات الاتصال لأجهزة IoT وإصلاحها لأن هناك العديد من نقاط الفشل المحتملة. يمكن أن تتسبب القواعد المنطقية للبرنامج والشبكات الفعلية والبروتوكولات والأجهزة ومركز IoT والخدمات السحابية الأخرى مشاكل. وتعد القدرة على اكتشاف مصدر المشكلة وتحديده أمرا بالغ الأهمية. ومع ذلك، يمكن أن يحتوي حل IoT على نطاق واسع على آلاف الأجهزة، لذلك ليس من العملي التحقق من الأجهزة الفردية بصورة يدوية. يتكامل مركز IoT مع اثنين من خدمات Azure لمساعدتك:
Azure Monitor يمَكِّنك Azure Monitor من جمع بيانات تتبع الاستخدام وتحليلها والعمل عليها من مركز IoT. لمساعدتك في اكتشاف هذه المشكلات وتشخيصها واستكشاف الأخطاء وإصلاحها على نطاق واسع، استخدم قدرات المراقبة التي يوفرها مركز IoT من خلال Azure Monitor. يتضمن هذا الأسلوب إعداد التنبيهات لتشغيل الإعلامات والإجراءات عند حدوث قطع الاتصال وتكوين السجلات التي يمكنك استخدامها لاكتشاف الحالات التي تسببت في قطع الاتصال.
Azure Event Grid بالنسبة للبنية الأساسية الهامة وقطع الاتصال لكل جهاز، استخدم Azure Event Grid للاشتراك في أحداث توصيل الجهاز وقطع الاتصال الصادرة عن مركز IoT. يمكنك Azure Event Grid من استخدام أي من معالجات الأحداث الآتية:
- دالات Azure
- Logic Apps
- التنفيذ التلقائي في Azure
- خطافات الويب
- مخزن قائمة الانتظار
- اتصالات مختلطة
- مراكز الأحداث
Event Grid مقابل Azure Monitor
توفر Event Grid حل مراقبة بزمن انتقال منخفض لكل جهاز يمكنك استخدامه لتتبع اتصالات الجهاز للأجهزة والبنية الأساسية الهامة. يوفر Azure Monitor مقياسا يسمى الأجهزة المتصلة التي يمكنك استخدامها لمراقبة عدد الأجهزة المتصلة ب IoT Hub وتشغيل تنبيه عندما ينخفض هذا الرقم إلى أقل من حد ثابت.
ضع في اعتبارك المشكلات التالية عند تحديد ما إذا كنت تريد استخدام Event Grid أو Azure Monitor لسيناريو معين:
زمن انتقال التنبيه: يتم تسليم أحداث اتصال مركز IoT بسرعة أكبر بكثير من خلال Event Grid. هذه الحقيقة تجعل Event Grid خيارا أفضل للسيناريوهات التي يكون فيها الإعلام السريع مرغوبا فيه.
الإخطارات لكل جهاز: توفر Event Grid القدرة على تعقب عمليات الاتصال وقطع الاتصال للأجهزة الفردية. هذه الحقيقة تجعل Event Grid خيارا أفضل للسيناريوهات التي تحتاج فيها إلى مراقبة الاتصالات للأجهزة الهامة.
إعداد خفيف الوزن: توفر تنبيهات قياس Azure Monitor تجربة إعداد خفيفة الوزن لا تتطلب التكامل مع الخدمات الأخرى لتقديم الإخطارات من خلال البريد الإلكتروني والرسائل النصية والصوت والإخطارات الأخرى. مع Event Grid، تحتاج إلى التكامل مع خدمات Azure الأخرى لتقديم الإخطارات. يمكن أن تتكامل الخدمتين مع خدمات أخرى لتشغيل إجراءات أكثر تعقيدًا.
Event Grid: مراقبة أحداث الاتصال وقطع الاتصال
لمراقبة الأحداث المتصلة بالجهاز والأحداث غير المتصلة بالجهاز في الإنتاج، نوصي بالاشتراك في أحداث DeviceConnected وDeviceDisconnectedعلى Event Grid لتشغيل تنبيهات حالة اتصال الجهاز ومراقبته. توفر شبكة الأحداث زمن انتقال أقل من Azure Monitor، ويمكنك المراقبة على أساس كل جهاز. تجعل هذه العوامل من Event Grid الطريقة المفضلة لمراقبة الاتصالات للأجهزة والبنية الأساسية الهامة.
عند استخدام Event Grid لمراقبة أو تشغيل التنبيهات حول قطع اتصال الجهاز، تأكد من إنشاء طريقة لتصفية عمليات قطع الاتصال الدورية بسبب تجديد رمز SAS المميز على الأجهزة التي تستخدم Azure IoT SDKs. لمعرفة المزيد، يرجى مراجعةسلوك قطع اتصال جهاز MQTT باستخدام Azure IoT SDKs.
استكشف المقالات التالية لمعرفة المزيد حول مراقبة أحداث اتصال الجهاز باستخدام Event Grid:
للحصول على نظرة عامة حول استخدام Event Grid مع مركز IoT، يرجى مراجعةالتفاعل مع أحداث IoT المركز باستخدام Event Grid. انتبه بشكل خاص إلى قسم القيود الخاصة بأحداث حالة اتصال الجهاز.
للحصول على برنامج تعليمي حول طلب أحداث اتصال الجهاز، يرجى مراجعةترتيب أحداث اتصال الجهاز من مركز Azure IoT باستخدام قاعدة بيانات Azure Cosmos .
للحصول على برنامج تعليمي حول إرسال إخطارات البريد الإلكتروني، يرجى مراجعةإرسال إخطارات البريد الإلكتروني حول أحداث مركز Azure IoT باستخدام Event Grid وLogic Apps في وثائق Event Grid.
Azure Monitor: استخدام سجلات لحل أخطاء الاتصال
عند اكتشاف قطع الاتصال في الجهاز باستخدام تنبيهات قياس Azure Monitor أو Event Grid، يمكنك استخدام السجلات للمساعدة في استكشاف السبب وإصلاحه. يصف هذا القسم طريقة البحث عن المشكلات الشائعة في سجلات Azure Monitor. تفترض الخطوات هنا أنك قمت بالفعل بإنشاء إعداد تشخيص لإرسال سجلات اتصالات مركز IoT إلى مساحة عمل Log Analytics.
بعد إنشاء إعداد تشخيص لتوجيه سجلات موارد IoT Hub إلى سجلات Azure Monitor، اتبع هذه الخطوات لعرض السجلات في مدخل Microsoft Azure.
في مدخل Microsoft Azure، انتقل إلى مركز IoT.
ضمن المراقبة على الجزء الأيسر من مركز IoT، حددLogs.
لعزل سجلات أخطاء الاتصال لمركز IoT، أدخل الاستعلام التالي في محرر الاستعلام ثم حدد Run:
AzureDiagnostics | where ( ResourceType == "IOTHUBS" and Category == "Connections" and Level == "Error")إن كانت هناك نتائج، فابحث عن
OperationNameوResultType(رمز الخطأ) وResultDescription(رسالة الخطأ) للحصول على مزيد من التفاصيل.
استخدم أدلة حل المشكلة الآتية للمساعدة في الأخطاء الأكثر شيوعًا:
Azure Monitor: استخدام السجلات لمراقبةِ الاتصال لجهاز محدد
قد تكون هناك مواقف عندما تريد استخدام Azure Monitor لمشاهدة أخطاء الاتصال ومعلومات لجهاز معين. لعزل أحداث الاتصال لجهاز، يمكن اتباع نفس الخطوات كما في القسم السابق، ولكن أدخل الاستعلام التالي. استبدل جهاز الاختبار باسم الجهاز الخاص بك.
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.DEVICES" and ResourceType == "IOTHUBS"
| where Category == "Connections"
| extend DeviceId = tostring(parse_json(properties_s).deviceId)
| where DeviceId == "test-device"
يقوم الاستعلام بإرجاع كل من أحداث الخطأ والأحداث الإعلامية للجهاز الهدف. يظهر إخراج المثال التالي حدث اتصال جهاز المعلوماتي:
سلوك قطع اتصال جهاز MQTT باستخدام Azure IoT SDKs
قطع اتصال SDKs لجهاز Azure IoT من مركز IoT ثم إعادة الاتصال عند تجديد رموز SAS المميزة عبر بروتوكول MQTT (وMQTT عبر WebSockets). في السجلات، يظهر ذلك كأحداث قطع اتصال وتوصيل جهاز إعلامية أحيانًا مصحوبة بأحداث خطأ.
بشكل افتراضي، عمر الرمز المميز هو 60 دقيقة لجميع SDKs؛ ومع ذلك، يمكن للمطورين تغييره في بعض SDKs. ويلخص الجدول التالي عمر الرمز المميز وتجديد الرمز المميز وسلوك تجديد الرمز المميز لكل من SDKs:
| SDK | العمر الافتراضي للرمز المميز | تجديد الرمز المميز | سلوك التجديد |
|---|---|---|---|
| .NET | 60 دقيقة، وقابل للتكوين | 85% من العمر الافتراضي، قابل للتكوين | تقوم SDK بقطع الاتصال وإعادة الاتصال خلال عمر الرمز المميز بالإضافة إلى فترة سماح مدتها 10 دقائق. الأحداث والأخطاء المعلوماتية المنشئة في السجلات. |
| Java | 60 دقيقة، وقابل للتكوين | 85% من العمر الافتراضي، وغير قابل للتكوين | تقوم SDK بقطع الاتصال وإعادة الاتصال خلال عمر الرمز المميز بالإضافة إلى فترة سماح مدتها 10 دقائق. الأحداث والأخطاء المعلوماتية المنشئة في السجلات. |
| Node.js | 60 دقيقة، وقابل للتكوين | قابل للتكوين | تقوم SDK بقطع الاتصال وإعادة الاتصال عند تجديد رمز مميز. يتم إنشاء الأحداث الإعلامية فقط في سجلات. |
| Python | 60 دقيقة، وقابل للتكوين | 120 ثانية قبل انتهاء الصلاحية | تقوم SDK بقطع الاتصال وإعادة الاتصال عند تجديد الرمز المميز. |
توضح لقطات الشاشة التالية سلوك تجديد الرمز المميز في سجلات Azure Monitor لـ SDKs المختلفة. تم تغيير العمر الافتراضي للرمز المميز وحد التجديد من الإعدادات الافتراضية الخاصة بهم كما هو ملاحظ.
.NET device SDK مع 1200 ثانية (20 دقيقة) عمر الرمز المميز والتجديد تعيين أن يحدث في 90٪ من العمر الافتراضي. يقع قطع الاتصال كل 30 دقيقة:
Java SDK مع عمر رمز مميز لمدة 300 ثانية (5 دقائق) و85٪ من تجديد العمر الافتراضي. يحدث قطع الاتصال كل 15 دقيقة:
عقدة SDK مع 300 ثانية (5 دقائق) عمر الرمز المميز وتعيين تجديد الرمز المميز أن يحدث في 3 دقائق. يقع قطع الاتصال عند تجديد الرمز المميز. أيضا، لا توجد أخطاء. يتم إصدار أحداث الاتصال/قطع الاتصال المعلوماتية فقط:
تم استخدام الاستعلام الآتي لجمع النتائج. يستخرج الاستعلام اسم SDK وإصداره من حقيبة خصائص. لمعرفة المزيد، يرجى مراجعةإصدار SDK في سجلات مركز IoT.
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.DEVICES" and ResourceType == "IOTHUBS"
| where Category == "Connections"
| extend parsed_json = parse_json(properties_s)
| extend SDKVersion = tostring(parsed_json.sdkVersion) , DeviceId = tostring(parsed_json.deviceId) , Protocol = tostring(parsed_json.protocol)
| distinct TimeGenerated, OperationName, Level, ResultType, ResultDescription, DeviceId, Protocol, SDKVersion
بصفتك مطور حلول IoT أو عامل التشغيل، تحتاج إلى أن تكون على دراية بهذا السلوك من أجل تفسير أحداث الاتصال/قطع الاتصال والأخطاء ذات الصلة في السجلات. إذا كنت ترغب في تغيير عمر الرمز المميز أو سلوك التجديد للأجهزة، فتحقق لمعرفة ما إذا كان الجهاز ينفذ إعدادا مزدوجا للجهاز أو أسلوب جهاز يجعل هذا التغيير ممكنا.
إن كنت تراقب اتصالات الجهاز مع Event Hubs فتأكد من إنشاء طريقة لفلترة حالات قطع الاتصال الدورية الناتجة من تجديد رمز SAS المميز. على سبيل المثال، لا تقم بتشغيل الإجراءات استنادا إلى قطع الاتصال طالما أن حدث قطع الاتصال متبوعا بحدث اتصال خلال فترة زمنية معينة.
إشعار
يدعم مركز IoT اتصال MQTT نشطا واحدا فقط لكل جهاز. يؤدي أي اتصال MQTT جديد نيابة عن نفس معرف الجهاز إلى إسقاط مركز IoT للاتصال الموجود.
تسجيل 400027 ConnectionForcefullyClosedOnNewConnection في سجلات مركز IoT
لقد جربت الخطوات، إلا أنها لم تعمل
إن لم تساعدك الخطوات السابقة، فجرب:
إن كان لديك حق الوصول إلى الأجهزة المسببة للمشاكل، إما فعليًا أو عن بعد (مثل SSH)، فاتبع دليل استكشاف الأخطاء وإصلاحها من جانب الجهاز لمتابعة استكشاف الأخطاء وإصلاحها.
تحقق من تمكين أجهزتك في مدخل > Microsoft Azure على أجهزة مركز IoT >.
إن كان جهازك يستخدم بروتوكول MQTT، فتحقق من أن المنفذ 8883 مفتوح. للمزيد من المعلومات، راجع الاتصال بـمركز IoT (MQTT).
احصل على تعليمات من صفحة سؤال Microsoft Q&A ل Azure IoT Hub أو Stack Overflow أو دعم Azure.
الخطوات التالية
لمعرفة المزيد حول حل المشكلات العابرة، يرجى مراجعةمعالجة الأخطاء العابرة.
لمعرفة المزيد حول SDKs لجهاز Azure IoT وإدارة عمليات إعادة المحاولة، راجع أنماط إعادة المحاولة.