حلول للمشكلات الشائعة ل Azure IoT Edge

مقالة
07/10/2024

تنبيه

تشير هذه المقالة إلى CentOS، وهو توزيع Linux هو حالة نهاية العمر الافتراضي (EOL). يرجى مراعاة استخدامك والتخطيط وفقا لذلك. لمزيد من المعلومات، راجع إرشادات نهاية العمر الافتراضي CentOS.

ينطبق على: IoT Edge 1.5 IoT Edge 1.4

هام

IoT Edge 1.5 LTS وIoT Edge 1.4 LTS هي إصدارات مدعومة. IoT Edge 1.4 LTS هو نهاية العمر الافتراضي في 12 نوفمبر 2024. إذا كنت تستخدم إصدارا سابقا، فشاهد تحديث IoT Edge.

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

التوفير والنشر

يتم نشر وحدة IoT Edge بنجاح ثم تختفي من الجهاز

العلامات

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

السبب

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

حل

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

لمزيد من المعلومات، راجع فهم عمليات النشر التلقائية ل IoT Edge لأجهزة واحدة أو على نطاق واسع.

وقت تشغيل IoT Edge

يتوقف عامل IoT Edge بعد دقيقة

العلامات

تبدأ الوحدة edgeAgent وتعمل بنجاح لمدة دقيقة تقريبا، ثم تتوقف. تشير السجلات إلى أن عامل IoT Edge يحاول الاتصال ب IoT Hub عبر AMQP، ثم يحاول الاتصال باستخدام AMQP عبر WebSocket. عند فشل ذلك، يتم إنهاء عامل IoT Edge.

مثال على سجلات edgeAgent:

2017-11-28 18:46:19 [INF] - Starting module management agent.
2017-11-28 18:46:19 [INF] - Version - 1.0.7516610 (03c94f85d0833a861a43c669842f0817924911d5)
2017-11-28 18:46:19 [INF] - Edge agent attempting to connect to IoT Hub via AMQP...
2017-11-28 18:46:49 [INF] - Edge agent attempting to connect to IoT Hub via AMQP over WebSocket...

السبب

يمنع تكوين الشبكة على الشبكة المضيفة عامل IoT Edge من الوصول إلى الشبكة. يحاول العامل الاتصال عبر AMQP (المنفذ 5671) أولا. إذا فشل الاتصال، فإنه يحاول WebSockets (المنفذ 443).

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

حل

تأكد من وجود مسار إلى الإنترنت لعناوين IP المعينة إلى شبكة الجسر/NAT هذه. في بعض الأحيان يتجاوز تكوين VPN على المضيف شبكة IoT Edge.

تقارير الوحدة النمطية ل Edge Agent "ملف التكوين الفارغ" ولا تبدأ أي وحدات نمطية على الجهاز

العلامات

يواجه الجهاز مشكلة في بدء تشغيل الوحدات النمطية المحددة في النشر. يتم تشغيل edgeAgent فقط ولكن والإبلاغ عن ملف التكوين الفارغ....
عند التشغيل sudo iotedge check على جهاز، فإنه يبلغ عن عدم تكوين محرك الحاوية مع إعداد خادم DNS، مما قد يؤثر على الاتصال ب IoT Hub. يرجى الاطلاع https://aka.ms/iotedge-prod-checklist-dns على أفضل الممارسات.

السبب

بشكل افتراضي، يبدأ IoT Edge الوحدات النمطية في شبكة الحاويات المعزولة الخاصة بهم. قد يواجه الجهاز مشكلة في تحليل اسم DNS داخل هذه الشبكة الخاصة.
إذا كنت تستخدم تثبيتا انطباقا ل IoT Edge، فإن ملف تكوين Docker هو موقع مختلف. راجع خيار الحل 3.

حل

الخيار 1: تعيين خادم DNS في إعدادات محرك الحاوية

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

{
    "dns": ["1.1.1.1"]
}

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

ضع daemon.json في /etc/docker الدليل على جهازك.

إذا كان الموقع يحتوي بالفعل على daemon.json ملف، أضف مفتاح dns إليه واحفظ الملف.

أعد تشغيل محرك الحاوية حتى تسري التحديثات.

sudo systemctl restart docker

الخيار 2: تعيين خادم DNS في نشر IoT Edge لكل وحدة نمطية

يمكنك تعيين خادم DNS لكل وحدة نمطية createOptions في نشر IoT Edge. على سبيل المثال:

"createOptions": {
  "HostConfig": {
    "Dns": [
      "x.x.x.x"
    ]
  }
}

تحذير

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

تأكد من تعيين هذا التكوين للوحدات النمطية edgeAgent وedgeHub أيضا.

الخيار 3: تمرير موقع ملف تكوين docker للتحقق من الأمر

إذا تم تثبيت IoT Edge كمحاذاة، فاستخدم المعلمة --container-engine-config-file لتحديد موقع ملف تكوين Docker. على سبيل المثال، إذا كان ملف تكوين Docker موجودا في /var/snap/docker/current/config/daemon.json، فقم بتشغيل الأمر التالي: iotedge check --container-engine-config-file '/var/snap/docker/current/config/daemon.json'.

حاليا، تستمر رسالة التحذير في الظهور في إخراج التحقق من iotedge حتى بعد تعيين موقع ملف التكوين. تحقق من الإبلاغ عن الخطأ لأن محاذاة IoT Edge ليس لديها حق الوصول للقراءة إلى محاذاة Docker. إذا كنت تستخدم إيداع iotedge في عملية الإصدار، يمكنك منع رسالة التحذير باستخدام المعلمة --ignore container-engine-dns container-engine-logrotate .

الوحدة النمطية لعامل Edge مع اتصال LTE تبلغ عن "تكوين عامل حافة فارغ" وتتسبب في "خطأ عابر في الشبكة"

العلامات

يوجد جهاز تم تكوينه باتصال LTE به مشكلات في بدء الوحدات النمطية المحددة في النشر. لا يتمكن edgeAgent من الاتصال ب IoT Hub ويبلغ عن حدوث تكوين عامل حافة فارغ وخطأ عابر في الشبكة.

السبب

تحتوي بعض الشبكات على حمل حزمة، ما يجعل شبكة docker الافتراضية MTU (1500) عالية جدا وتتسبب في تجزئة الحزمة التي تمنع الوصول إلى الموارد الخارجية.

حل

تحقق من إعداد MTU لشبكة docker.

docker network inspect <network name>
تحقق من إعداد MTU لمحول الشبكة الفعلي على جهازك.

ip addr show eth0

إشعار

لا يمكن أن يكون MTU لشبكة docker أعلى من MTU لجهازك. اتصل بم ISP للحصول على مزيد من المعلومات.

إذا رأيت حجم MTU مختلفا لشبكة docker والجهاز، فجرب الحل البديل التالي:

إنشاء شبكة جديدة. على سبيل المثال،

docker network create --opt com.docker.network.driver.mtu=1430 test-mtu

في المثال، إعداد MTU للجهاز هو 1430. ومن ثم، تم تعيين MTU لشبكة Docker إلى 1430.
إيقاف شبكة Azure وإزالتها.

docker network rm azure-iot-edge
إعادة إنشاء شبكة Azure.

docker network create --opt com.docker.network.driver.mtu=1430 azure-iot-edge
قم بإزالة جميع الحاويات وإعادة تشغيل خدمة aziot-edged .

sudo iotedge system stop && sudo docker rm -f $(docker ps -aq -f "label=net.azure-devices.edge.owner=Microsoft.Azure.Devices.Edge.Agent") && sudo iotedge config apply

لا يمكن لعامل IoT Edge الوصول إلى صورة الوحدة النمطية (403)

العلامات

فشل تشغيل الحاوية، والإبلاغ عن سجلات edgeAgent خطأ 403.

السبب

لا تملك وحدة عامل IoT Edge أذونات للوصول إلى صورة الوحدة النمطية.

حل

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

يقوم عامل IoT Edge بإجراء مكالمات هوية زائدة

العلامات

يقوم عامل IoT Edge بإجراء مكالمات هوية زائدة إلى Azure IoT Hub.

السبب

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

حل

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

فشل بدء تشغيل مركز IoT Edge

العلامات

فشلت الوحدة النمطية edgeHub في البدء. قد ترى رسالة مثل أحد الأخطاء التالية في السجلات:

One or more errors occurred.
(Docker API responded with status code=InternalServerError, response=
{\"message\":\"driver failed programming external connectivity on endpoint edgeHub (6a82e5e994bab5187939049684fb64efe07606d2bb8a4cc5655b2a9bad5f8c80):
Error starting userland proxy: Bind for 0.0.0.0:443 failed: port is already allocated\"}\n)

أو

info: edgelet_docker::runtime -- Starting module edgeHub...
warn: edgelet_utils::logging -- Could not start module edgeHub
warn: edgelet_utils::logging --     caused by: failed to create endpoint edgeHub on network nat: hnsCall failed in Win32:
        The process cannot access the file because it is being used by another process. (0x20)

السبب

قامت بعض العمليات الأخرى على الجهاز المضيف بربط منفذ تحاول وحدة edgeHub ربطه. يعين مركز IoT Edge المنافذ 443 و5671 و8883 للاستخدام في سيناريوهات البوابة. تفشل الوحدة في البدء إذا كانت عملية أخرى قد ربطت بالفعل أحد هذه المنافذ.

حل

يمكنك حل هذه المشكلة بطريقتين:

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

إذا لم تكن بحاجة إلى استخدام جهاز IoT Edge كبوابة، فيمكنك إزالة روابط المنفذ من خيارات إنشاء الوحدة النمطية ل edgeHub. يمكنك تغيير خيارات الإنشاء في مدخل Microsoft Azure أو مباشرة في ملف deployment.json.

في مدخل Microsoft Azure:

انتقل إلى مركز IoT وحدد الأجهزة ضمن قائمة إدارة الأجهزة.
حدد جهاز IoT Edge الذي تريد تحديثه.
حدد Set modules.
حدد إعدادات وقت التشغيل.
في إعدادات الوحدة النمطية Edge Hub ، احذف كل شيء من مربع النص Container Create Options .
حدد تطبيق لحفظ التغييرات وإنشاء النشر.

في ملف deployment.json:

افتح ملف deployment.json الذي قمت بتطبيقه على جهاز IoT Edge.

ابحث عن edgeHub الإعدادات في قسم الخصائص المطلوبة edgeAgent:

  "edgeHub": {
      "restartPolicy": "always",
      "settings": {
         "image": "mcr.microsoft.com/azureiotedge-hub:1.5",
         "createOptions": "{\"HostConfig\":{\"PortBindings\":{\"443/tcp\":[{\"HostPort\":\"443\"}],\"5671/tcp\":[{\"HostPort\":\"5671\"}],\"8883/tcp\":[{\"HostPort\":\"8883\"}]}}}"
      },
      "status": "running",
      "type": "docker"
   }

قم بإزالة createOptions السطر، والفاسقة اللاحقة في نهاية image السطر قبله:

  "edgeHub": {
      "restartPolicy": "always",
      "settings": {
      "image": "mcr.microsoft.com/azureiotedge-hub:1.5",
      "status": "running",
      "type": "docker"
}

حدد إنشاء لتطبيقه على جهاز IoT Edge مرة أخرى.

فشل وحدة IoT Edge في إرسال رسالة إلى edgeHub مع خطأ 404

العلامات

فشلت وحدة IoT Edge المخصصة في إرسال رسالة إلى مركز IoT Edge مع خطأ 404 Module not found . يطبع وقت تشغيل IoT Edge الرسالة التالية إلى السجلات:

Error: Time:Thu Jun  4 19:44:58 2018 File:/usr/sdk/src/c/provisioning_client/adapters/hsm_client_http_edge.c Func:on_edge_hsm_http_recv Line:364 executing HTTP request fails, status=404, response_buffer={"message":"Module not found"}u, 04 )

السبب

يفرض وقت تشغيل IoT Edge تعريف العملية لجميع الوحدات النمطية المتصلة ب edgeHub لأسباب أمنية. يتحقق من أن جميع الرسائل التي يتم إرسالها بواسطة وحدة نمطية تأتي من معرف العملية الرئيسي للوحدة النمطية. إذا تم إرسال رسالة بواسطة وحدة نمطية من معرف عملية مختلف عن الذي تم إنشاؤه في البداية، فإنها ترفض الرسالة مع رسالة خطأ 404.

حل

اعتبارا من الإصدار 1.0.7، يتم تفويض جميع عمليات الوحدة النمطية للاتصال. لمزيد من المعلومات، راجع سجل تغيير الإصدار 1.0.7.

إذا لم تكن الترقية إلى 1.0.7 ممكنة، فأكمل الخطوات التالية. تأكد من استخدام نفس معرف العملية دائما من قبل وحدة IoT Edge المخصصة لإرسال رسائل إلى edgeHub. على سبيل المثال، تأكد من ENTRYPOINT بدلا من CMD الأمر في ملف Docker. CMD يؤدي الأمر إلى معرف عملية واحد للوحدة النمطية ومعرف عملية آخر لأمر bash الذي يقوم بتشغيل البرنامج الرئيسي، ولكنه ENTRYPOINT يؤدي إلى معرف عملية واحد.

مشكلات الاستقرار على الأجهزة الأصغر حجما

العلامات

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

السبب

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

حل

بالنسبة لمركز IoT Edge، قم بتعيين متغير بيئة OptimizeForPerformance إلى false. هناك طريقتان لتعيين متغيرات البيئة:

في مدخل Microsoft Azure:

في مركز IoT، حدد جهاز IoT Edge ومن صفحة تفاصيل الجهاز وحدد تعيين إعدادات وقت تشغيل الوحدات النمطية>.
إنشاء متغير بيئة لوحدة مركز IoT Edge تسمى OptimizeForPerformance مع النوع True/False الذي تم تعيينه إلى False.

حدد تطبيق لحفظ التغييرات، ثم حدد مراجعة + إنشاء.

متغير البيئة الآن في edgeHub خاصية بيان التوزيع:

   "edgeHub": {
      "env": {
            "OptimizeForPerformance": {
               "value": false
            }
      },
      "restartPolicy": "always",
      "settings": {
            "image": "mcr.microsoft.com/azureiotedge-hub:1.5",
            "createOptions": "{\"HostConfig\":{\"PortBindings\":{\"443/tcp\":[{\"HostPort\":\"443\"}],\"5671/tcp\":[{\"HostPort\":\"5671\"}],\"8883/tcp\":[{\"HostPort\":\"8883\"}]}}}"
      },
      "status": "running",
      "type": "docker"
   }

حدد إنشاء لحفظ التغييرات ونشر الوحدة النمطية.

تعذر بدء تشغيل البرنامج الخفي للأمان بنجاح

العلامات

فشل البرنامج الخفي للأمان في البدء ولا يتم إنشاء حاويات الوحدة النمطية. edgeAgentلا يتم بدء تشغيل الوحدات edgeHub النمطية المخصصة الأخرى و بواسطة خدمة IoT Edge. في aziot-edged السجلات، سترى هذا الخطأ:

تعذر بدء تشغيل البرنامج الخفي بنجاح: تعذر بدء تشغيل خدمة الإدارة

بسبب: حدث خطأ للمسار /var/run/iotedge/mgmt.sock

بسبب: تم رفض الإذن (خطأ نظام التشغيل 13)

السبب

بالنسبة لجميع توزيعات Linux باستثناء CentOS 7، فإن التكوين الافتراضي ل IoT Edge هو استخدام systemd تنشيط مأخذ التوصيل. يحدث خطأ في الإذن إذا قمت بتغيير ملف التكوين لعدم استخدام تنشيط مأخذ التوصيل ولكن اترك عناوين URL ك /var/run/iotedge/*.sock، حيث iotedge لا يمكن للمستخدم الكتابة بمعنى /var/run/iotedge أنه لا يمكنه إلغاء تأمين المقابس نفسها وتركيبها.

حل

لا تحتاج إلى تعطيل تنشيط مأخذ التوصيل على توزيع حيث يتم دعم تنشيط مأخذ التوصيل. ومع ذلك، إذا كنت تفضل عدم استخدام تنشيط مأخذ التوصيل على الإطلاق، فضع المقابس في /var/lib/iotedge/.

قم بتشغيل systemctl disable iotedge.socket iotedge.mgmt.socket لتعطيل وحدات مأخذ التوصيل بحيث لا يبدأ النظام بها دون داع
تغيير تكوين iotedge لاستخدامه /var/lib/iotedge/*.sock في كل من connect المقطعين و listen
إذا كان لديك بالفعل وحدات نمطية، لديهم التركيبات القديمة /var/run/iotedge/*.sock ، لذلك docker rm -f لهم.

تنظيف قائمة انتظار الرسائل بطيء

العلامات

لا يتم تنظيف قائمة انتظار الرسائل بعد معالجة الرسائل. تزداد قائمة انتظار الرسائل بمرور الوقت وتؤدي في النهاية إلى نفاد ذاكرة وقت تشغيل IoT Edge.

السبب

يتم التحكم في الفاصل الزمني لتنظيف الرسالة بواسطة رسالة العميل TTL (وقت البقاء) ومتغير البيئة EdgeHub MessageCleanupIntervalSecs . قيمة TTL للرسالة الافتراضية هي ساعتين وقيمة MessageCleanupIntervalSecs الافتراضية هي 30 دقيقة. إذا كان تطبيقك يستخدم قيمة TTL أقصر من القيمة الافتراضية ولم تقم بضبط قيمة MessageCleanupIntervalSecs ، فلن يتم تنظيف الرسائل منتهية الصلاحية حتى الفاصل الزمني التالي للتنظيف.

حل

إذا قمت بتغيير قيمة TTL للتطبيق الخاص بك أقصر من الافتراضي، فقم أيضا بضبط قيمة MessageCleanupIntervalSecs . يجب أن تكون قيمة MessageCleanupIntervalSecs أصغر بكثير من أصغر قيمة TTL التي يستخدمها العميل. على سبيل المثال، إذا كان تطبيق العميل يعرف TTL لمدة خمس دقائق في رأس الرسالة، فقم بتعيين قيمة MessageCleanupIntervalSecs إلى دقيقة واحدة. تضمن هذه الإعدادات تنظيف الرسائل في غضون ست دقائق (5 + 1).

لتكوين قيمة MessageCleanupIntervalSecs ، قم بتعيين متغير البيئة في بيان النشر لوحدة مركز IoT Edge. لمزيد من المعلومات حول تعيين متغيرات بيئة وقت التشغيل، راجع متغيرات بيئة Edge Agent وEdge Hub.

الشبكات

فشل برنامج أمان IoT Edge الخفي مع اسم مضيف غير صالح

العلامات

فشلت محاولة التحقق من سجلات إدارة أمان IoT Edge وطباعة الرسالة التالية:

Error parsing user input data: invalid hostname. Hostname cannot be empty or greater than 64 characters

السبب

يمكن أن يدعم وقت تشغيل IoT Edge أسماء المضيفين الأقصر من 64 حرفا فقط. عادة ما لا تحتوي الأجهزة الفعلية على أسماء مضيفين طويلة، ولكن المشكلة أكثر شيوعا على الجهاز الظاهري. تميل أسماء المضيف التي تم إنشاؤها تلقائيا لأجهزة Windows الظاهرية المستضافة في Azure، على وجه الخصوص، إلى أن تكون طويلة.

حل

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

في مدخل Microsoft Azure، انتقل إلى صفحة نظرة عامة على جهازك الظاهري.
افتح لوحة التكوين عن طريق تحديد الارتباط غير المكون (إذا كان الجهاز الظاهري جديدا) أو حدد اسم DNS الموجود ضمن اسم DNS الأساسي>. إذا كان جهازك الظاهري يحتوي بالفعل على اسم DNS تم تكوينه، فلن تحتاج إلى تكوين اسم جديد.
قم بتوفير قيمة لتسمية اسم DNS إذا لم يكن لديك اسم بالفعل وحدد حفظ.
انسخ اسم DNS الجديد، والذي يجب أن يكون بالتنسيق:
<DNSnamelabel>.<vmlocation.cloudapp.azure.com>.
على جهاز IoT Edge، افتح ملف التكوين.
```
sudo nano /etc/aziot/config.toml
```
استبدل قيمة hostname باسم DNS الخاص بك.
احفظ الملف وأغلقه، ثم طبق التغييرات على IoT Edge.
```
sudo iotedge config apply
```

تقارير وحدة IoT Edge عن أخطاء الاتصال

العلامات

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

السبب

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

حل

استخدم الخطوات التالية لتمكين إعادة توجيه حزمة IP.

افتح ملف sysctl.conf .
```
sudo nano /etc/sysctl.conf
```
أضف السطر التالي إلى الملف.
```
net.ipv4.ip_forward=1
```
احفظ الملف وأغلقه.
أعد تشغيل خدمة الشبكة وخدمة docker لتطبيق التغييرات.

لا يمكن ل IoT Edge خلف البوابة تنفيذ طلبات HTTP وبدء وحدة edgeAgent

العلامات

وقت تشغيل IoT Edge نشط مع ملف تكوين صالح، ولكن لا يمكنه بدء تشغيل الوحدة النمطية edgeAgent . يقوم الأمر iotedge list بإرجاع قائمة فارغة. تقارير Could not perform HTTP request وقت تشغيل IoT Edge في السجلات.

السبب

تحصل أجهزة IoT Edge خلف البوابة على صور الوحدة النمطية الخاصة بها من جهاز IoT Edge الأصل المحدد في parent_hostname حقل ملف التكوين. Could not perform HTTP request يعني الخطأ أن جهاز انتقال البيانات من الخادم غير قادر على الوصول إلى جهازه الأصل عبر HTTP.

حل

تأكد من أن جهاز IoT Edge الأصل يمكنه تلقي الطلبات الواردة من جهاز IoT Edge المتلقي للمعلومات. افتح حركة مرور الشبكة على المنفذين 443 و6617 للطلبات الواردة من جهاز انتقال البيانات من الخادم.

لا يمكن ل IoT Edge خلف البوابة تنفيذ طلبات HTTP وبدء وحدة edgeAgent

العلامات

البرنامج الخفي ل IoT Edge نشط مع ملف تكوين صالح، ولكن لا يمكنه بدء تشغيل الوحدة النمطية edgeAgent. يقوم الأمر iotedge list بإرجاع قائمة فارغة. تقرير Could not perform HTTP requestسجلات برنامج IoT Edge الخفي .

السبب

حل

يتعذر على IoT Edge خلف البوابة الاتصال عند الترحيل من مركز IoT إلى آخر

العلامات

عند محاولة ترحيل تسلسل هرمي لأجهزة IoT Edge من مركز IoT إلى آخر، يمكن لجهاز IoT Edge الأصل عالي المستوى الاتصال ب IoT Hub، ولكن لا يمكن لأجهزة IoT Edge المتلقية للمعلومات. تقرير Unable to authenticate client downstream-device/$edgeAgent with module credentialsالسجلات .

السبب

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

حل

عند الترحيل إلى مركز IoT الجديد (بافتراض عدم استخدام DPS)، اتبع الخطوات التالية بالترتيب:

اتبع هذا الدليل لتصدير هويات الجهاز ثم استيرادها من مركز IoT القديم إلى المركز الجديد
إعادة تكوين جميع عمليات نشر وتكوينات IoT Edge في مركز IoT الجديد
إعادة تكوين كافة علاقات الجهاز الأصل والتابع في مركز IoT الجديد
تحديث كل جهاز للإشارة إلى اسم مضيف مركز IoT الجديد (iothub_hostname ضمن [provisioning] في config.toml)
إذا اخترت استبعاد مفاتيح المصادقة أثناء تصدير الجهاز، أعد تكوين كل جهاز بالمفاتيح الجديدة التي يقدمها مركز IoT الجديد (device_id_pk ضمن [provisioning.authentication] في config.toml)
أعد تشغيل جهاز Edge الأصل من المستوى الأعلى أولا، وتأكد من أنه قيد التشغيل
إعادة تشغيل كل جهاز في مستوى التسلسل الهرمي حسب المستوى من أعلى إلى أسفل

يحتوي IoT Edge على معدل نقل منخفض للرسائل عندما يكون بعيدا جغرافيا عن IoT Hub

العلامات

تحتوي أجهزة Azure IoT Edge البعيدة جغرافيا عن Azure IoT Hub على معدل نقل رسائل أقل من المتوقع.

السبب

يمكن أن يتسبب زمن الانتقال العالي بين الجهاز وIoT Hub في انخفاض معدل نقل الرسائل عن المتوقع. يستخدم IoT Edge حجم دفعة رسائل افتراضيا يبلغ 10. وهذا يحد من عدد الرسائل التي يتم إرسالها في دفعة واحدة، ما يزيد من عدد الرحلات ذهابا وابا بين الجهاز ومركز IoT.

حل

حاول زيادة متغير البيئة ل IoT Edge Hub MaxUpstreamBatchSize . يسمح هذا بإرسال المزيد من الرسائل في دفعة واحدة، ما يقلل من عدد الرحلات ذهابا و إيابا بين الجهاز وIoT Hub.

لتعيين متغيرات بيئة Azure Edge Hub في مدخل Microsoft Azure:

انتقل إلى مركز IoT وحدد الأجهزة ضمن قائمة إدارة الأجهزة.
حدد جهاز IoT Edge الذي تريد تحديثه.
حدد Set modules.
حدد إعدادات وقت التشغيل.
في علامة التبويب إعدادات وحدة Edge Hub، أضف متغير البيئة MaxUpstreamBatchSize كنوع رقم بقيمة 20.
حدد تطبيق.

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

هل تعتقد أنك عثرت على خطأ في النظام الأساسي ل IoT Edge؟ أرسل مشكلة حتى نتمكن من الاستمرار في التحسين.

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

مشاركة عبر

حلول للمشكلات الشائعة ل Azure IoT Edge

التوفير والنشر

يتم نشر وحدة IoT Edge بنجاح ثم تختفي من الجهاز

العلامات

السبب

حل

وقت تشغيل IoT Edge

يتوقف عامل IoT Edge بعد دقيقة

العلامات

السبب

حل

تقارير الوحدة النمطية ل Edge Agent "ملف التكوين الفارغ" ولا تبدأ أي وحدات نمطية على الجهاز

العلامات

السبب

حل

الوحدة النمطية لعامل Edge مع اتصال LTE تبلغ عن "تكوين عامل حافة فارغ" وتتسبب في "خطأ عابر في الشبكة"

العلامات

السبب

حل

لا يمكن لعامل IoT Edge الوصول إلى صورة الوحدة النمطية (403)

العلامات

السبب

حل

يقوم عامل IoT Edge بإجراء مكالمات هوية زائدة

العلامات

السبب

حل

فشل بدء تشغيل مركز IoT Edge

العلامات

السبب

حل

فشل وحدة IoT Edge في إرسال رسالة إلى edgeHub مع خطأ 404

العلامات

السبب

حل

مشكلات الاستقرار على الأجهزة الأصغر حجما

العلامات

السبب

حل

تعذر بدء تشغيل البرنامج الخفي للأمان بنجاح

العلامات

السبب

حل

تنظيف قائمة انتظار الرسائل بطيء

العلامات

السبب

حل

الشبكات

فشل برنامج أمان IoT Edge الخفي مع اسم مضيف غير صالح

العلامات

السبب

حل

تقارير وحدة IoT Edge عن أخطاء الاتصال

العلامات

السبب

حل

لا يمكن ل IoT Edge خلف البوابة تنفيذ طلبات HTTP وبدء وحدة edgeAgent

العلامات

السبب

حل

لا يمكن ل IoT Edge خلف البوابة تنفيذ طلبات HTTP وبدء وحدة edgeAgent

العلامات

السبب

حل

يتعذر على IoT Edge خلف البوابة الاتصال عند الترحيل من مركز IoT إلى آخر

العلامات

السبب

حل

يحتوي IoT Edge على معدل نقل منخفض للرسائل عندما يكون بعيدا جغرافيا عن IoT Hub

العلامات

السبب

حل

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

الملاحظات

الموارد الإضافية