مراقبة اتصال جهاز مركز 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: توجيه أحداث اتصال إلى السجلات
يصدر مركز IoT سجلات الموارد بصورة مستمرة لعدة فئات من العمليات. لجمع بيانات السجل هذه، بالرغم من ذلك، تحتاج إلى إنشاء إعداد تشخيص لتوجيهه إلى وجهة حيث يمكن تحليلها أو أرشفتها. إحدى هذه الوجهات هي سجلات Azure Monitor عبر مساحة عمل Log Analytics (راجع التسعير)، حيث يمكن تحليل البيانات باستخدام استعلامات Kusto.
تصدر فئة اتصالات سجلات مواردمركز IoT عمليات وأخطاء تتعلق باتصالات الجهاز. تظهر لقطة الشاشة الآتية إعداد تشخيص لتوجيه هذه السجلات إلى مساحة عمل Log Analytics:
نوصي بإنشاء إعداد تشخيص في أقرب وقت ممكن بعد إنشاء مركز IoT الخاص بك، لأنه على الرغم من أن مركز IoT يصدر دائمًا سجلات الموارد، لا يتم جمعها بواسطة Azure Monitor حتى تقوم بتوجيهها إلى وجهة.
لمعرفة المزيد حول سجلات التوجيه إلى وجهة، يرجى مراجعةالتجميع والتوجيه. للحصول على إرشادات مفصلة لإنشاء إعداد تشخيص، يرجى مراجعةالبرنامج التعليمي لاستخدام المقاييس والسجلات.
Azure Monitor: إعداد تنبيهات قياسية لقطع الاتصال في الجهاز
يمكن إعداد التنبيهات استنادا إلى مقاييس النظام الأساسي المنبعثة من مركز IoT. من خلال التنبيهات القياسية، يمكنك إخطار الأفراد بحدوث شرط اهتمام وتشغيل الإجراءات التي يمكنها الاستجابة لهذا الشرط تلقائيًا.
يخبرك مقياس الأجهزة المتصلة (إصدار أولي) بعدد الأجهزة المتصلة بمركز IoT. يمكن إنشاء تنبيهات لتشغيلها إذا انخفض هذا المقياس عن قيمة الحد:
يمكن استخدام قواعد التنبيه القياسي لمراقبة حالات قطع اتصال الجهاز غير الطبيعية على نطاق واسع. أي، استخدم التنبيهات لتحديد وقت قطع اتصال عدد كبير من الأجهزة بشكل غير متوقع. عند اكتشاف ذلك، يمكن إلقاء نظرة على السجلات للمساعدة في استكشاف المشكلة وإصلاحها. لمراقبة عمليات قطع الاتصال وقطع الاتصال لكل جهاز للأجهزة الهامة في الوقت الفعلي تقريبًا، ومع ذلك، يجب استخدام شبكة الأحداث Event Grid.
لمعرفة المزيد حول التنبيهات باستخدام مركز IoT، يرجى مراجعةالتنبيهات في Monitor IoT Hub. للحصول على إرشادات حول إنشاء تنبيهات في مركز IoT، يرجى مراجعةالبرنامج التعليمي لاستخدام المقاييس والسجلات. للحصول على نظرة عامة أكثر تفصيلاً على التنبيهات، يرجى مراجعةنظرة عامة على التنبيهات في Microsoft Azure في وثائق Azure Monitor.
Azure Monitor: استخدام سجلات لحل أخطاء الاتصال
عند اكتشاف قطع الاتصال في الجهاز باستخدام تنبيهات قياس Azure Monitor أو Event Grid، يمكنك استخدام السجلات للمساعدة في استكشاف السبب وإصلاحه. يصف هذا القسم طريقة البحث عن المشكلات الشائعة في سجلات Azure Monitor. تفترض الخطوات أدناه أنك قمت بالفعل بإنشاء إعداد تشخيص لإرسال سجلات اتصالات مركز IoT إلى مساحة العمل Log Analytics.
بعد إنشاء إعداد تشخيص لتوجيه سجلات موارد مركز IoT إلى سجلات 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 وإدارة عمليات إعادة المحاولة، راجع أنماط إعادة المحاولة.