Lösungen für häufige Probleme für Azure IoT Edge

Gilt für: IoT Edge 1,5

Verwenden Sie diesen Artikel, um häufige Probleme bei der Verwendung von IoT Edge Lösungen zu identifizieren und zu beheben. Informationen zum Auffinden von Protokollen und Fehlern auf Ihrem IoT Edge Gerät finden Sie unter Fehlerbehebung für Ihr IoT Edge Gerät.

Bereitstellung und Implementierung

Das IoT-Edge-Modul wird erfolgreich bereitgestellt und verschwindet dann vom Gerät.

Symptome

Nach dem Festlegen von Modulen für ein IoT Edge-Gerät werden die Module erfolgreich bereitgestellt, aber nach ein paar Minuten verschwinden sie vom Gerät und aus den Gerätedetails im Azure-Portal. Auch andere als die definierten Module können auf dem Gerät auftauchen.

Ursache

Wenn eine automatische Bereitstellung ein Gerät zum Ziel hat, hat sie Vorrang vor der manuellen Festlegung der Module für ein einzelnes Gerät. Die Set-Module-Funktionalität im Azure-Portal oder die Funktion Bereitstellung für ein einzelnes Gerät erstellen in Visual Studio Code tritt für einen Moment in Kraft. Sie sehen, dass die von Ihnen definierten Module auf dem Gerät gestartet werden. Dann greift die Priorität der automatischen Bereitstellung und überschreibt die gewünschten Eigenschaften des Geräts.

Lösung

Verwenden Sie pro Gerät nur einen Bereitstellungsmechanismus, entweder eine automatische Bereitstellung oder einzelne Gerätebereitstellungen. Bei mehreren automatischen Bereitstellungen, die ein Gerät zum Ziel haben, können Sie die Priorität oder Zielbeschreibungen ändern, um sicherzustellen, dass die richtige Beschreibung für ein bestimmtes Gerät zutrifft. Sie können auch den Gerätezwilling aktualisieren, sodass er nicht mehr der Zielbeschreibung der automatischen Bereitstellung entspricht.

Weitere Informationen finden Sie unter Verstehen von automatischen IoT Edge-Bereitstellungen für einzelne Geräte oder in größerem Maßstab.

IoT Edge Laufzeit

IoT Edge Agent stoppt nach einer Minute.

Symptome

Das edgeAgent-Modul startet und wird ungefähr eine Minute lang erfolgreich ausgeführt, dann wird es beendet. Die Protokolle zeigen, dass der IoT Edge-Agent versucht, eine Verbindung mit IoT Hub über AMQP herzustellen, und dann versucht, mithilfe von AMQP über WebSocket eine Verbindung herzustellen. Wenn diese Verbindung fehlschlägt, wird der IoT Edge Agent beendet.

Beispielprotokolle von „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...

Ursache

Eine Netzwerkkonfiguration im Hostnetzwerk verhindert, dass der IoT Edge Agent das Netzwerk erreicht. Der Agent versucht zuerst, eine Verbindung über AMQP (Port 5671) herzustellen. Wenn ein Verbindungsfehler auftritt, verwendet er WebSockets (Port 443).

Die IoT Edge Laufzeit richtet ein Netzwerk für jedes der Module ein, über das kommuniziert werden soll. Unter Linux ist dieses Netzwerk ein Bridgenetzwerk. Auf Windows wird NAT verwendet. Dieses Problem tritt häufiger auf Windows Geräten mit Windows Containern auf, die das NAT-Netzwerk verwenden.

Lösung

Stellen Sie sicher, dass eine Route zum Internet für die IP-Adressen vorhanden ist, die dieser Brücke oder diesem NAT-Netzwerk zugewiesen sind. Manchmal überschreibt eine VPN-Konfiguration auf dem Host das IoT Edge Netzwerk.

Das Edge-Agent-Modul meldet „empty config file“, und auf dem Gerät werden keine Module gestartet

Symptome

• Auf dem Gerät treten Probleme beim Starten von in der Bereitstellung definierten Modulen auf. Nur der edgeAgent wird ausgeführt, meldet jedoch leere Konfigurationsdatei....

• Wenn Sie sudo iotedge check auf einem Gerät ausführen, meldet es, dass die Container-Engine nicht mit der DNS-Servereinstellung konfiguriert ist, was sich auf die Konnektivität zu IoT Hub auswirken kann. Weitere Informationen zu Best Practices finden Sie unter https://aka.ms/iotedge-prod-checklist-dns.

Ursache

• Standardmäßig startet IoT Edge Module in ihrem eigenen isolierten Containernetzwerk. Das Gerät hat möglicherweise Probleme mit der DNS-Namensauflösung in diesem privaten Netzwerk.
• Wenn Sie eine Snap-Installation von IoT Edge verwenden, befindet sich die Docker-Konfigurationsdatei an einem anderen Speicherort. Weitere Informationen finden Sie unter der Lösungsoption 3.

Lösung

Option 1: Festlegen des DNS-Servers in Containermoduleinstellungen

Geben Sie den DNS-Server für Ihre Umgebung in den Einstellungen der Container-Engine an. Diese Einstellungen gelten für alle Containermodule, die die Engine startet. Erstellen Sie eine Datei mit dem Namen daemon.json, und geben Sie den zu verwendenden DNS-Server an. Beispiel:

{
    "dns": ["1.1.1.1"]
}

Dieser DNS-Server wird auf einen öffentlich zugänglichen DNS-Dienst festgelegt. Einige Netzwerke, z. B. Unternehmensnetzwerke, verfügen jedoch über eigene DNS-Server und erlauben keinen Zugriff auf öffentliche DNS-Server. Wenn Ihr Edgegerät auf einen öffentlichen DNS-Server nicht zugreifen kann, ersetzen Sie ihn deshalb durch eine erreichbare DNS-Serveradresse.

Speichern Sie daemon.json im Verzeichnis /etc/docker auf Ihrem Gerät.

Wenn die Datei daemon.json im Pfad bereits vorhanden ist, fügen Sie ihr den Schlüssel dns hinzu, und speichern Sie die Datei.

Starten Sie die Containerengine neu, damit die Änderungen wirksam werden.

sudo systemctl restart docker

Option 2: Festlegen des DNS-Servers in IoT Edge Bereitstellung pro Modul

Sie können den DNS-Server für den Abschnitt createOptions jedes Moduls in der IoT Edge-Bereitstellung festlegen. Beispiel:

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

Achten Sie darauf, diese Konfiguration auch für die Module edgeAgent und edgeHub festzulegen.

Option 3: Übergeben des Speicherorts der Docker-Konfigurationsdatei, um den Befehl zu überprüfen

Wenn Sie IoT Edge als Snap installieren, verwenden Sie den Parameter --container-engine-config-file, um den Speicherort der Docker-Konfigurationsdatei anzugeben. Wenn sich beispielsweise die Docker-Konfigurationsdatei unter /var/snap/docker/current/config/daemon.json befindet, führen Sie den folgenden Befehl aus: iotedge check --container-engine-config-file '/var/snap/docker/current/config/daemon.json'.

Derzeit wird die Warnmeldung weiterhin in der Ausgabe der Iotedge-Überprüfung angezeigt, auch nachdem Sie den Speicherort der Konfigurationsdatei festgelegt haben. Der Check meldet den Fehler, weil der IoT Edge Snap keinen Lesezugriff auf den Docker Snap hat. Wenn Sie iotedge check in Ihrem Releaseprozess verwenden, können Sie die Warnmeldung mithilfe des Parameters --ignore container-engine-dns container-engine-logrotate unterdrücken.

Edge-Agent-Modul mit LTE-Verbindung meldet „leere Edge-Agent-Konfiguration festgestellt“, was einen „vorübergehenden Netzwerkfehler“ verursacht.

Symptome

Ein gerät, das mit einer LTE-Verbindung konfiguriert ist, hat Probleme beim Starten von Modulen, die in der Bereitstellung definiert sind. Der edgeAgent kann keine Verbindung mit dem IoT Hub herstellen und meldet "leere Edge-Agent-Konfiguration" und "vorübergehender Netzwerkfehler".

Ursache

Einige Netzwerke haben Paketaufwand, wodurch die Standardmäßige Docker-Netzwerk-MTU (1500) zu hoch ist und die Paketfragmentierung verursacht. Diese Fragmentierung verhindert den Zugriff auf externe Ressourcen.

Lösung

1. Überprüfen Sie die MTU-Einstellung für Ihr Docker-Netzwerk.

   docker network inspect <network name>

2. Überprüfen Sie die MTU-Einstellung für den physischen Netzwerkadapter auf Ihrem Gerät.

   ip addr show eth0

Wenn für Ihr Docker-Netzwerk und das Gerät eine andere MTU-Größe angezeigt wird, probieren Sie die folgende Problemumgehung aus:

1. Erstellen Sie ein neues Netzwerk. Zum Beispiel,

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

   Im Beispiel ist die MTU-Einstellung für das Gerät 1430. Legen Sie die MTU für das Docker-Netzwerk auf 1430 fest.

2. Beenden sie das Azure Netzwerk, und entfernen Sie es.

   docker network rm azure-iot-edge

3. Erstellen Sie das Azure Netzwerk neu.

   docker network create --opt com.docker.network.driver.mtu=1430 azure-iot-edge

4. Entfernen Sie alle Container und starten Sie den aziot-edged-Dienst neu.

   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 Agent kann nicht auf das Image eines Moduls zugreifen (403)

Symptome

Ein Container kann nicht ausgeführt werden, und die edgeAgent-Protokolle melden Fehler 403.

Ursache

Das IoT Edge Agentmodul verfügt nicht über Berechtigungen für den Zugriff auf das Bild eines Moduls.

Lösung

Stellen Sie sicher, dass Ihre Anmeldeinformationen für die Containerregistrierung im Bereitstellungsmanifest des Geräts richtig sind.

IoT Edge Agent führt übermäßige Identitätsaufrufe aus

Symptome

IoT Edge Agent führt übermäßige Identitätsaufrufe an Azure IoT Hub aus.

Ursache

Die Fehlkonfiguration des Gerätebereitstellungsmanifests führt zu einer erfolglosen Bereitstellung auf dem Gerät. Die Wiederholungslogik des IoT Edge Agent setzt die Wiederholungsversuche der Bereitstellung fort. Jeder Wiederholungsversuche führt Identitätsaufrufe aus, bis die Bereitstellung erfolgreich ist. Wenn das Bereitstellungsmanifest z. B. einen Modul-URI angibt, der nicht in der Containerregistrierung vorhanden ist oder falsch eingegeben ist, wird die bereitstellung durch den IoT Edge-Agent erneut ausgeführt, bis das Bereitstellungsmanifest korrigiert wird.

Lösung

Überprüfen Sie das Bereitstellungsmanifest im Azure-Portal. Korrigieren Sie alle Fehler, und stellen Sie das Manifest erneut auf dem Gerät bereit.

IoT Edge Hub kann nicht gestartet werden.

Symptome

Das Modul edgeHub kann nicht gestartet werden. In den Protokollen wird möglicherweise eine Nachricht wie eine der folgenden Fehlermeldungen angezeigt:

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)

Oder

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)

Ursache

Ein anderer Prozess auf dem Hostcomputer hat einen Port gebunden, den das EdgeHub-Modul zu binden versucht. Der IoT Edge Hub ordnet ports 443, 5671 und 8883 für die Verwendung in Gatewayszenarien zu. Das Modul kann nicht gestartet werden, wenn ein anderer Prozess bereits einen dieser Ports gebunden hat.

Lösung

Beheben Sie dieses Problem auf eine von zwei Arten:

Wenn das IoT Edge Gerät als Gatewaygerät fungiert, suchen und beenden Sie den Prozess, der Port 443, 5671 oder 8883 verwendet. Ein Fehler für Port 443 bedeutet in der Regel, dass der andere Prozess ein Webserver ist.

Wenn Sie das IoT Edge Gerät nicht als Gateway verwenden müssen, entfernen Sie die Portbindungen aus dem EdgeHub-Modul zum Erstellen von Optionen. Sie können die Erstellungsoptionen im Azure Portal oder direkt in der deployment.json Datei ändern.

Im Azure-Portal:

1. Wechseln Sie zu Ihrem IoT-Hub, und wählen Sie " Geräte" im Menü "Geräteverwaltung " aus.

2. Wählen Sie das IoT Edge Gerät aus, das Sie aktualisieren möchten.

3. Wählen Sie Module festlegen aus.

4. Wählen Sie Runtimeeinstellungen aus.

5. Löschen Sie in den Einstellungen des Moduls Edge Hub alles aus dem Textfeld Containererstellungsoptionen.

6. Wählen Sie Übernehmen aus, um Ihre Änderungen zu speichern und die Bereitstellung zu erstellen.

Gehen Sie in der Datei „deployment.json“ so vor:

1. Öffnen Sie die deployment.json Datei, die Sie auf Ihr IoT Edge Gerät angewendet haben.

2. Suchen Sie die edgeHub Einstellungen im Abschnitt für die gewünschten Eigenschaften von 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"
      }
   

3. Entfernen Sie die Zeile createOptions und das abschließende Komma am Ende der Zeile image davor:

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

4. Wählen Sie Create aus, um es erneut auf Ihr IoT Edge Gerät anzuwenden.

IoT Edge Modul kann keine Nachricht an EdgeHub senden und gibt den Fehler 404 zurück.

Symptome

Ein benutzerdefiniertes IoT Edge-Modul kann keine Nachricht an den IoT Edge Hub senden und gibt einen Fehler vom Typ 404 Module not found zurück. Die IoT Edge Runtime druckt die folgende Meldung in die Logs.

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 )

Ursache

Aus Sicherheitsgründen erzwingt die IoT Edge Laufzeit die Prozessidentifikation für alle Module, die mit edgeHub verbunden sind. Es wird überprüft, ob alle Nachrichten, die ein Modul sendet, aus der Hauptprozess-ID des Moduls stammen. Wenn ein Modul versucht, eine Nachricht aus einer anderen Prozess-ID zu senden, lehnt die Laufzeit die Nachricht ab und gibt eine Fehlermeldung von 404 zurück.

Lösung

Ab Version 1.0.7 können alle Modulprozesse eine Verbindung herstellen. Weitere Informationen finden Sie im Änderungsprotokoll 1.0.7.

Wenn Sie kein Upgrade auf Version 1.0.7 durchführen können, führen Sie die folgenden Schritte aus. Stellen Sie sicher, dass das benutzerdefinierte IoT Edge-Modul immer dieselbe Prozess-ID zum Senden von Nachrichten an edgeHub verwendet. Verwenden Sie beispielsweise den ENTRYPOINT Befehl anstelle des CMD Befehls in Ihrer Docker-Datei. Der CMD Befehl führt zu einer Prozess-ID für das Modul und einer anderen Prozess-ID für den Bash-Befehl, der das Hauptprogramm ausführt. Der ENTRYPOINT Befehl führt zu einer einzelnen Prozess-ID.

Stabilitätsprobleme auf kleineren Geräten

Symptome

Es können Stabilitätsprobleme auf ressourcenbeschränkten Geräten wie dem Raspberry Pi auftreten, insbesondere bei Verwendung als Gateway. Zu den Symptomen gehören Arbeitsspeicherausnahmen im IoT Edge-Hub-Modul. Nachgeschaltete Geräte können sich nicht verbinden, oder das Gerät sendet nach einigen Stunden keine Telemetrienachrichten mehr.

Ursache

Der IoT Edge Hub, der Teil der IoT Edge Laufzeit ist, ist standardmäßig für die Leistung optimiert und versucht, große Speicherblöcke zuzuweisen. Diese Optimierung ist für eingeschränkte Edge-Geräte nicht ideal und kann zu Stabilitätsproblemen führen.

Lösung

Legen Sie für den IoT Edge Hub eine Umgebungsvariable OptimizeForPerformance auf false fest. Sie können Umgebungsvariablen auf eine von zwei Arten festlegen:

Im Azure-Portal:

1. Wählen Sie in Ihrem IoT Hub Ihr IoT Edge Gerät aus. Wählen Sie auf der Seite "Gerätedetails" die Option "Module-Laufzeiteinstellungen" aus.

2. Erstellen Sie eine Umgebungsvariable für das IoT Edge Hubmodul mit dem Namen OptimizeForPerformance mit typ True/False und legen Sie sie auf False fest.

3. Wählen Sie Anwenden, um Ihre Änderungen zu speichern, und wählen Sie dann Überprüfen + Erstellen.

   Die Umgebungsvariable befindet sich jetzt in der edgeHub-Eigenschaft des Bereitstellungsmanifests:

      "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"
      }
   

4. Wählen Sie Erstellen aus, um Ihre Änderungen zu speichern und das Modul bereitzustellen.

Der Sicherheitsdaemon kann nicht gestartet werden.

Symptome

Der Sicherheitsdaemon kann nicht gestartet werden, und Modulcontainer werden nicht erstellt. Der IoT Edge-Dienst startet nicht edgeAgent, edgeHub oder andere benutzerdefinierte Module. In den aziot-edged Protokollen wird diese Fehlermeldung angezeigt:

• Der Daemon konnte nicht gestartet werden: Der Verwaltungsdienst konnte nicht gestartet werden.
• Ursache: Fehler im Pfad „/var/run/iotedge/mgmt.sock“
• Verursacht durch: Berechtigung verweigert (Betriebssystemfehler 13)

Ursache

Für alle Linux-Distributionen mit Ausnahme von CentOS 7 verwendet IoT Edge standardmäßig systemd Socketaktivierung. Wenn Sie die Konfigurationsdatei so ändern, dass die Socketaktivierung deaktiviert wird, die URLs jedoch beibehalten werden /var/run/iotedge/*.sock, erhalten Sie einen Berechtigungsfehler. Der Benutzer iotedge kann nicht auf /var/run/iotedge schreiben, also kann er die Sockets nicht entsperren und mounten. CentOS hat das Ende des Lebenszyklus erreicht (EOL). Weitere Informationen finden Sie im CentOS End-of-Life-Leitfaden.

Lösung

Deaktivieren Sie die Socketaktivierung nicht bei einer Distribution, die die Socketaktivierung unterstützt. Wenn Sie die Socketaktivierung jedoch nicht verwenden möchten, setzen Sie die Sockets in /var/lib/iotedge/.

1. Führen Sie die Ausführung systemctl disable iotedge.socket iotedge.mgmt.socket aus, um die Socketeinheiten zu deaktivieren, sodass sie von systemd nicht gestartet werden.
2. Ändern der IoT Edge-Konfiguration zur Verwendung von /var/lib/iotedge/*.sock in den Abschnitten connect und listen
3. Wenn Sie bereits Module haben, haben diese die alten /var/run/iotedge/*.sock mounts, also führen Sie docker rm -f aus, um sie zu entfernen.

Die Bereinigung der Nachrichtenwarteschlange erfolgt langsam.

Symptome

Die Nachrichtenwarteschlange wird nicht bereinigt, nachdem Nachrichten verarbeitet wurden. Die Nachrichtenwarteschlange wächst im Laufe der Zeit und führt schließlich dazu, dass die IoT Edge Laufzeit nicht mehr genügend Arbeitsspeicher hat.

Ursache

Die TTL der Clientnachrichten (Lebensdauer) und die Umgebungsvariable EdgeHubMessageCleanupIntervalSecs bestimmen das Intervall für die Nachrichtenbereinigung. Der TTL-Standardwert der Standardmeldung beträgt zwei Stunden, und der Standardwert MessageCleanupIntervalSecs beträgt 30 Minuten. Wenn Ihre Anwendung einen TTL-Wert verwendet, der kürzer als der Standardwert ist und Sie den MessageCleanupIntervalSecs Wert nicht anpassen, werden abgelaufene Nachrichten erst nach dem nächsten Bereinigungsintervall bereinigt.

Lösung

Wenn Sie den TTL-Wert für Ihre Anwendung auf einen Wert ändern, der kürzer als der Standardwert ist, passen Sie auch den Wert an MessageCleanupIntervalSecs . Der MessageCleanupIntervalSecs Wert sollte wesentlich kleiner sein als der kleinste TTL-Wert, den der Client verwendet. Wenn die Clientanwendung beispielsweise eine TTL von fünf Minuten im Nachrichtenkopf definiert, legen Sie den MessageCleanupIntervalSecs Wert auf eine Minute fest. Diese Einstellungen stellen sicher, dass Nachrichten innerhalb von sechs (5 + 1) Minuten bereinigt werden.

Um den Wert MessageCleanupIntervalSecs zu konfigurieren, legen Sie die Umgebungsvariable im Bereitstellungsmanifest für das IoT Edge Hubmodul fest. Weitere Informationen zum Festlegen von Laufzeitumgebungsvariablen finden Sie unter Edge Agent- und Edge Hub-Umgebungsvariablen.

IoT Edge Hub meldet System.FormatException-Fehler bei Verwendung des AMQP-Protokolls

Symptome

Wenn Sie Nachrichten von einem IoT Edge Gerät mithilfe des AMQP-Protokolls an eine IoT Hub weiterleiten und die Eigenschaft iothub-creation-time-utc für ausgehende Gerätenachrichten festlegen meldet der IoT Edge Hub einen Fehler System.FormatException. Die Fehlermeldung lautet ungefähr folgendermaßen:

System.FormatException: String '2024-12-01T00:00:0.000Z' was not recognized as a valid DateTime.

Ursache

Der Wert iot-hub-creation-time-utc erfüllt keine strengen Formatkriterien. Das Format, das Edge Hub benötigt, ist eine Untermenge von ISO 8601.

Lösung

Dieses Problem ist ein bekanntes Problem in IoT Edge Hub für das AMQP-Protokoll. Derzeit untersucht das Produktteam eine Lösung. Das MQTT-Protokoll hat dieses Problem nicht.

Netzwerk

IoT Edge Sicherheitsdaemon schlägt mit einem ungültigen Hostnamen fehl.

Symptome

Beim Versuch, die Protokolle des IoT Edge Sicherheits-Managers zu überprüfen schlägt fehl und gibt die folgende Meldung aus:

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

Ursache

Die IoT Edge Laufzeit unterstützt Hostnamen, die kürzer als 64 Zeichen sind. Physische Computer weisen in der Regel keine langen Hostnamen auf, das Problem ist eher bei virtuellen Computern üblich. Die automatisch generierten Hostnamen für Windows-VMs, die in Azure gehostet werden, sind insbesondere lang.

Lösung

Wenn dieser Fehler angezeigt wird, beheben Sie ihn, indem Sie den DNS-Namen Ihres virtuellen Computers konfigurieren und dann den DNS-Namen als Hostname im Setupbefehl festlegen.

1. Wechseln Sie im Azure-Portal zur Übersichtsseite Ihres virtuellen Computers.

2. Öffnen Sie den Konfigurationsbereich, indem Sie unter DNS-Namen den Link Nicht konfiguriert auswählen (wenn Ihre VM neu ist), oder wählen Sie Ihren vorhandenen DNS-Namen unter Essentials>DNS-Name aus. Wenn für Ihren virtuellen Computer bereits ein DNS-Name konfiguriert wurde, müssen Sie keinen neuen konfigurieren.

3. Geben Sie einen Wert für die DNS-Namensbezeichnung ein, wenn Sie noch keines haben, und wählen Sie "Speichern" aus.

4. Kopieren Sie den neuen DNS-Namen, der im Format vorliegen soll:
   <DNSnamelabel>.<vmlocation.cloudapp.azure.com>.

5. Öffnen Sie auf dem IoT Edge Gerät die Konfigurationsdatei.

   sudo nano /etc/aziot/config.toml
   

6. Ersetzen Sie den Wert von hostname durch Ihren DNS-Namen.

7. Speichern und schließen Sie die Datei, und wenden Sie dann die Änderungen auf IoT Edge an.

   sudo iotedge config apply
   

IoT Edge Modul meldet Konnektivitätsfehler

Symptome

IoT Edge Module, die sich direkt mit Clouddiensten verbinden, einschließlich der Laufzeitmodule, funktionieren nicht mehr wie erwartet und geben Fehler im Zusammenhang mit Verbindungs- oder Netzwerkfehlern zurück.

Ursache

Container basieren auf der IP-Paketweiterleitung, um eine Verbindung mit dem Internet herzustellen, damit sie mit Clouddiensten kommunizieren können. Docker aktiviert standardmäßig die IP-Paketweiterleitung, aber wenn Sie sie deaktivieren, funktionieren alle Module, die eine Verbindung mit Clouddiensten herstellen, nicht wie erwartet. Weitere Informationen finden Sie in der Docker-Dokumentation unter Understand container communication (Informationen zur Containerkommunikation).

Lösung

Gehen Sie nach folgenden Schritte vor, um die IP-Paketweiterleitung zu aktivieren.

1. Öffnen Sie die Datei sysctl.conf.

   sudo nano /etc/sysctl.conf
   

2. Fügen Sie der Datei die folgende Zeile hinzu:

   net.ipv4.ip_forward=1
   

3. Speichern und schließen Sie die Datei.

4. Starten Sie den Netzwerkdienst und den Docker-Dienst neu, um die Änderungen anzuwenden.

IoT Edge Gerät hinter einem Gateway kann keine HTTP-Anforderungen ausführen oder edgeAgent-Modul starten

Symptome

Die IoT Edge Laufzeit ist mit einer gültigen Konfigurationsdatei aktiv, kann jedoch das Modul edgeAgent nicht starten. Der Befehl iotedge list gibt eine leere Liste zurück. Die IoT Edge-Runtime meldet Could not perform HTTP request in den Protokollen.

Ursache

IoT Edge Geräte hinter einem Gateway erhalten ihre Modulimages vom übergeordneten IoT Edge Gerät, das im Feld parent_hostname der Konfigurationsdatei angegeben ist. Der Could not perform HTTP request Fehler bedeutet, dass das nachgeschaltete Gerät sein übergeordnetes Gerät nicht über HTTP erreichen kann.

Lösung

Stellen Sie sicher, dass das übergeordnete IoT-Edge-Gerät eingehende Anforderungen vom nachgeschalteten IoT-Edge-Gerät empfangen kann. Lassen Sie den Netzwerkdatenverkehr auf den Ports 443 und 6617 für Anforderungen vom nachgeschalteten Gerät zu.

IoT Edge hinter einem Gateway kann beim Migrieren von einem IoT-Hub zu einem anderen keine Verbindung herstellen.

Symptome

Wenn Sie eine Hierarchie von IoT Edge Geräten von einem IoT hub zu einem anderen migrieren, stellt das übergeordnete IoT Edge Gerät auf oberster Ebene eine Verbindung mit IoT Hub her, aber nachgelagerte IoT Edge Geräte können dies nicht. Die Protokolle enthalten Folgendes: Unable to authenticate client downstream-device/$edgeAgent with module credentials.

Ursache

Die Migration hat die Anmeldeinformationen für die nachgeschalteten Geräte nicht ordnungsgemäß aktualisiert. Aufgrund dieses Problems weisen die Module edgeAgent und edgeHub einen Authentifizierungstyp none auf (der Standardwert, wenn Sie ihn nicht explizit festlegen). Bei der Verbindungsherstellung werden von den Modulen der nachgeschalteten Geräte alte Anmeldeinformationen verwendet, wodurch die Authentifizierung nicht erfolgreich ist.

Lösung

Wenn Sie zum neuen IoT-Hub migrieren (vorausgesetzt, Sie verwenden DPS nicht), führen Sie die folgenden Schritte aus:

1. Gehen Sie wie in dieser Anleitung beschrieben vor, um Geräteidentitäten aus dem alten IoT-Hub zu exportieren und dann in den neuen IoT-Hub zu importieren.
2. Neukonfigurieren aller IoT Edge Bereitstellungen und Konfigurationen im neuen IoT-Hub
3. Konfigurieren Sie alle Beziehungen zwischen über- und untergeordneten Geräten im neuen IoT-Hub neu.
4. Aktualisieren Sie jedes Gerät so, dass es auf den neuen IoT-Hub-Hostnamen verweist (iothub_hostname unter [provisioning] in config.toml).
5. Falls Sie Authentifizierungsschlüssel beim Geräteexport ausgeschlossen haben, konfigurieren Sie jedes Gerät mit den neuen Schlüsseln, die vom neuen IoT-Hub ausgegeben wurden (device_id_pk unter [provisioning.authentication] in config.toml).
6. Starten Sie zuerst das übergeordnete Edgegerät der obersten Ebene neu, und vergewissern Sie sich, dass es betriebsbereit ist.
7. Starten Sie jedes Gerät der Hierarchieebenen einzeln neu, indem Sie dabei Ebene für Ebene von oben nach unten vorgehen.

IoT Edge hat einen niedrigen Nachrichtendurchsatz, wenn er geografisch von IoT Hub entfernt ist

Symptome

Azure IoT Edge Geräte, die geografisch von Azure IoT Hub entfernt sind, weisen einen niedrigeren Nachrichtendurchsatz auf.

Ursache

Die hohe Latenz zwischen dem Gerät und IoT Hub führt zu einem niedrigeren Nachrichtendurchsatz. IoT Edge verwendet eine Standardmäßige Nachrichtenbatchgröße von 10. Diese Batchgröße beschränkt die Anzahl der Nachrichten, die in einem einzelnen Batch gesendet werden, wodurch die Anzahl der Roundtrips zwischen dem Gerät und IoT Hub erhöht wird.

Lösung

Versuchen Sie, die Umgebungsvariable IoT Edge Hub MaxUpstreamBatchSize zu erhöhen. Diese Änderung sendet mehr Nachrichten in einem einzelnen Batch, wodurch die Anzahl der Roundtrips zwischen dem Gerät und IoT Hub reduziert wird.

So legen Sie Azure Edge Hub-Umgebungsvariablen im Azure Portal fest:

1. Navigieren Sie zu Ihrem IoT Hub, und wählen Sie Devices unter dem Menü Device management aus.
2. Wählen Sie das IoT Edge Gerät aus, das Sie aktualisieren möchten.
3. Wählen Sie Module festlegen aus.
4. Wählen Sie Runtimeeinstellungen aus.
5. Fügen Sie auf der Registerkarte Edge Hub-Moduleinstellungen die MaxUpstreamBatchSize-Umgebungsvariable als Typ Nummer mit dem Wert 20 hinzu.
6. Wählen Sie Apply aus.

Nächste Schritte

Glauben Sie, dass Sie einen Fehler in der IoT Edge-Plattform gefunden haben? Reichen Sie ein Problem ein, damit das Produktteam die Plattform weiterhin verbessern kann.

Wenn Sie weitere Fragen haben, erstellen Sie eine Supportanfrage, um Hilfe zu erhalten.